The guide Exception Handling in ASP.NET Web API describes using the StringContent class to supply a string to HttpResponseMessage.
However I am using WebApi 1 on .net 4.0, which does not have the StringContent class.
In this context is the purpose of this class to encode the string? If so what is a worthy replacement for this?
Weirdly even though when searching for the StringContent class it gets to the msdn page saying it's in .net 4.5
I thought that it was in my intellisense due to the project being previously targetting .net 4.5.
However following the references it appears to be in an assemly pulled in my nuget and the path suggests that it's ok in .net 4.0.
Assembly System.Net.Http.dll, v2.0.0.0
\packages\Microsoft.Net.Http.2.0.20710.0\lib\net40\System.Net.Http.dll
Related
.Net 4.8 web app has the method to get the controller type by identifying AssemblyName and then GetType on the assembly
I think I can use Assembly.GetExecutingAssembly().FullName for asmblyType and from it I can use split to get name.
Any suggestions how to get it with .net core
Also if there is an alternative for System.Web.HttpContext.Current in .net core?
I'm converting all of our shared class libraries from .NET Framework to .NET Standard so that they're consumable by both our older .NET Framework and our new .NET Core applications. The goal is to get all of our applications to .NET Core, but it's a large system so will take time so we need the two worlds to coexist for a year or so in the meantime.
One of the pain points is that the shared class library code leverages HttpContext extensively. I understand that the new .NET Core way to access it from within class libraries is to use AddHttpContextAccessor. However, we still have old ASP.NET web forms applications AND new ASP.NET Core web applications that both need to call this common code. If I switch to using HttpContextAccessor with DI then it won't work from the old ASP.NET Web Forms app, as it has no concept of what HttpContextAccessor is.
I'm wondering what my options are here... Is there a way to set up access of HttpContext such that it can be consumable both in ASP.NET Web Forms and ASP.NET Core?
You have to have some common interface between both the old and new applications I would think.
Create a new IMyHttpContext and inject that type into both the old and the new. Use your DI infrastructure to instantiate a new MyClassForOld: IMyHttpContext that accesses an underlying reference HttpContext for the old apps and use your DI to instantiate another new MyClassForNew: IMyHttpContent that accesses an underlying reference to HttpContextAccessor
I thought I would try out .Net Core (v1.1.2) and one of the things I wondered about was if it was possible to call a WCF service written in .Net Framework 4.5.2. I am using Visual Studio 2017 and installed the Microsoft WCF Web Service Reference Provider (version 0.5.10428.1201). When I ran it, it found the service, but I got this error message when trying to generate the code:
Scaffolding Code ...
Error:Warning: Unsupported message encoding value: 'Mtom'. It must be 'Text'.
Warning: Unsupported message encoding element type: 'System.ServiceModel.Channels.MtomMessageEncodingBindingElement'. It must be one of the following types: 'System.ServiceModel.Channels.BinaryMessageEncodingBindingElement', 'System.ServiceModel.Channels.TextMessageEncodingBindingElement.'
Warning: Endpoint 'WSHttpBinding_IDocumentSignService' at address 'http://xxxxxxxxxxxxx.svc' contains one or more bindings not compatible with .Net Core apps, skipping...
Error: No endpoints compatible with .Net Core apps were found.
Failed to generate service reference.
(I edited the url to http://xxxxxxxxxxxx.svc)
Does this mean that .Net Core apps can't call all WCF services yet? Will it only support a certain subset? So that if I am stuck in a world of WCF services I will have to stay away from .Net Core? Or is it simply a problem with the tooling?
I realize this has probably been asked before, but I could find no clear answer.
As explained by panagiotis's comment, you're consuming a SOAP service with MTOM encoding (what is not supported by .net Core)
Nevertheless, consuming WCF services works fine in .Net core, as long as it is not relaying on WS* bindings.
extra info here
I was also having trouble by consuming MTOM encoded SOAP services.
I explain how I fixed it here
Is there an MVC6 compatible version of WebTelemetryInitializerBase that would work with ASP.NET Core (on the full .NET Framework)?
See my question here where I asked how to get HttpContext in my temeletry initializers. Unfortunately I didn't specify that I was using MVC 6 and thus no System.Web.HttpContext.
Yes, there is a version of this for aspnetcore. Check out the Microsoft Application Insights for ASP.NET Core applications repo.
There is an implementation of getting the WebUser found in /src/Microsoft.ApplicationInsights.AspNetCore/TelemetryInitializers/WebUserTelemetryInitializer.cs which you can use as a guide.
The TelemetryInitializerBase class is the one that consumes the IHttpContextAccessor which is used to get the HttpContext.
From there you can get the Microsoft.AspNetCore.Http.HttpContext.User which is they type of System.Security.Claims.ClaimsPrincipal
Looking over the web, I am finding no answer to this question. I see it being asked and a lot of people being referred to .Net 3.5; however, I am not seeing anything resembling an answer with in the restricted environment of WCF 3.0 (VS2005).
Is it possible for me to do an AJAX/JSON call to a WCF 3.0 Web Service or is the only option to use ASMX if you aren't able to use .Net 3.5?
Microsoft's ASP.NET 2.0 AJAX Extensions 1.0 contains classes to serialize and deserialize JSON for .NET 2.0 and newer.
The class that does it is System.Web.Script.Serialization.JavaScriptSerializer.
Note that even though the documentation linked above is for the 3.5 version, the 3.5 version is identical to the 2.0 version, because it was deprecated and replaced in 3.5 by the classes in System.Runtime.Serialization.Json.
I'm not really sure how to use this with WCF, though... the only time I used it was as an ashx handler.
There are no out of the box bindings in .NET 3.0 that will allow you to send JSON responses. You will need to implement it yourself. There's an article showing how to do REST with POX. It could be easily adapted to JSON but as you will see there's not negligible amount of work.