I'm having issues with a SignalR project I'm currently working on. I'm trying to build a server using .Net Core, and a client using traditional .Net (framework 4.6.1). However the server and client don't seem to be compatible.
The last issue I've run into is a StatusCode: 405, ReasonPhrase: 'Method Not Allowed'. I found an answer on GitHub that states that there are many breaking changes between versions.
Looking at the NuGet package versions available, I get even more confused. for the .Net Core server I'm using 1.0.0-preview1-final. There's also a 1.0.0-alpha2-final available, but I have no clue if 'alpha' is newer or older than 'preview'.
On the client side I was using version 2.2.2, and there's a whole range of versions to choose from, I tried the oldest and latest, but both versions give me the same "method not allowed" error.
The error is on the client side, on the server side, my breakpoints are not even hit, so it could be an Owin/iis issue as well.
Is there any chart out there that can map SignalR clients and server version compatability? I guess that would be a great step moving forward.
You can't mix the .NET Core 1.x with the older client (1.x or 2.x). You will need to decide which is the best option for you but you need to implement the same compatible version across CLIENT and SERVER.
Check the link for more details but essentially:
What’s Changed?
We added a number of new features to SignalR for ASP.NET Core but we
also decided to remove support for some of the existing features or
change how they work. One of the consequences of this is that SignalR
for ASP.NET Core is not compatible with previous versions of SignalR.
This means that you cannot use the old server with the new clients or the old clients with the new server.
Check the services are injected, possible some is not yet injected in the service container.
When add the signalR service you can enable detailed errors to know what is happening.
builder.Services.AddSignalR(o=>
{
o.EnableDetailedErrors = true;
});
Related
I was recently handed over the support of an already built logic app that accepts some json and performs some validations and send it to some endpoint. There's nothing wrong with the Logic app functionality, it works completely fine.
The problem is, penetration testing was done on the app and it presented us with security concern of X-aspnet-Version:4.0.30319.
I found this post here and it says:
That is not the actual .NET framework version. It is the version of
the CLR
My questions are, can the above quote be considered as the valid reference to address the issue? If not, can the logic app be somehow upgraded to use aspnet version 4.5 or higher?
And if I can change the version, can this have impacts on my current logic app's behavior?
Note: The app was made entirely through logic app designer and not a
single chunk of coding was implemented
No, the problem is with the test tool, not Logic Apps.
Just because it infers a problem doesn't mean there is a problem.
Explain to you 'security' testers that this is an Azure Logic App, not Windows/IIS. If you tell us the exact 'security concern' we can explain why it's irrelevant.
X-AspNet-Version: specifies the version of ASP.NET being used. Note that this value returns the core framework version. Typical examples include 1.1.4322, 2.0.50727 and 4.0.30319.
ASP.NET web sites send the ASP.NET version information in the web server HTTP Response Header as X-AspNet-Version value automatically to the client. So, you could not change it in logic app.
I have an existing application running .NET Framework 4.6.1, that uses SignalR version 2.3. The client version I'm using is 2.0, this has a jQuery dependency. This current setup uses SignalR cors as my web front end is on a different domain to my backend services which is where my hubs lie. To be honest it's all working fine and I'm happy with it, even though you could say it's old tech.
This application has been rewritten relatively recently, but at the time the project was started, SignalR on .Net Core didn't exist, or it might have been in alpha so it wasn't considered an option.
I now have the need to add a new project to the solution, a front end dashboard. Where I work, for new development we use angular, and .Net Core. I thought this would be a good opportunity to try to introduce these new techs into the solution. The plan is to have an angular project and use the #aspnet/signalr npm package, I'll be using Typescript.
Now, the problem (if you haven't guessed already). I can't seem to get my new shiny SignalR client to work with my old Framework SignalR server. The error message is very specific when the call to SignalR is made:
Error: Detected a connection attempt to an ASP.NET SignalR Server. This client only supports connecting to an ASP.NET Core SignalR Server.
What are my options here? Am I going to have to upgrade the SignalR project and the projects that interact with SignalR to Core? Or is there something else that I can do I the meantime to give me more time to upgrade?
You have to use the Asp.Net Core Server with Asp.Net Core Client or use Asp.Net SignalR Server with Asp.Net SignalR Client. You cannot mix them, they won't work together.
Not sure of any work around for that. Checking the differences page it does say you can run CORE on .NET Framework 4.6.1 or later .NET Core 2.1 or later. You should still be able run Asp.Net SignalR on a server running .NET Framework 4.6.1 if that is available to you (yes, I know you said you are a angular/core shop).
Short of that... yes, you would need to rewrite your app for SignalR Core (server and client).
We are using the code below to send the custom message from server side to client side in HTTP request. It is working properly in .NET Core 2.0
Response.HttpContext.Features.Get<IHttpResponseFeature>().ReasonPhrase
While using the same code in .NET Core 2.1 it does not work. It doesn't throw any script errors but we couldn't get message in client side success.
How to resolve this problem?
I hope it answers your question:
This is not caused by any code changes in the framework, it's caused
by a project configuration change.
The 2.0 project templates did not have HTTPS enabled by default, the
2.1 templates do. When using HTTP the browser uses HTTP/1.1 and ReasonPhrase works as expected. When using HTTPS the browser uses
HTTP/2 and ReasonPhrase no longer works.
Full answer by Chris Ross here.
I'm using Linkedin SSO on my website for more than a year now it has always performed as ask, until today. My website is an ASP.NET MVC5 website (C#). I use the classic Oauth2 integration and everything was working fine until yesterday when I changed the domain of my website. I changed in the developer interface the redirect urls (or should I say I added new url redirects) by it always sends access_denied to my callback url and I don't understand why. Has anyone the same issue these days or tips on how I can correct that issue.
Thanks a lot for your help
We had the same issue and after a bit of digging it appears that LinkedIn is now forcing tls1.2 - if you are on an old framework - you may have to upgrade - 4.6+ has tls1.2 as default and should work with no extra setup (although depending on the server you're running on you may still need to set up support for TLS 1.2 - follow the instructions in the top answer on this post : .Net Framework 4.6.1 not defaulting to TLS 1.2) .
If you are on 4.5+ you can just tell your code to use Tls1.2 by adding the following command somewhere global (for example when you initialize linkedin auth):
ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;
Some further info about Tls1.2 and support in .net can be found here : https://blogs.perficient.com/2016/04/28/tsl-1-2-and-net-support/
Hope this all helps!
We are planning on replacing a legacy "server" app (a Windows form app with, although it does not really need it, a GUI representation (showing status messages)) with a simplified service of some sort. The server/service responds to requests for data and sends said data. Will a legacy (.NET CF 1.0) app, which cannot be updated to a newer technology (because the handheld devices on which they run don't have room for the more recent/larger .NET Compact Framework runtime) be able to access "newfangled" services such as an asp.net RESTful web service? If not, what are some other options? Or, if there are better options even with that being feasible, what might y'all suggest?
No, the older .Net "Service references" don't understand newer formats/protocols.
But, at the end of the day, it's all just a bunch of auto-generated code mapping "objects" to XML.
SUGGESTION:
Just parse the XML directly.
If in doubt, play with your target service using SoapUI
Unless you've got a really complicated schema, that's probably the easiest to program - and most memory efficient - solution.
IMHO...