.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?
Related
BufferingHelper.EnableRewind();
Above is an extension method for HttpRequest object in ASP.NET Core 2.2. It is no more there in ASP.NET Core 3.0 (atleast with this name). I want to know it's alternate in ASP.NET Core 3.0. I am not sure if
HttpRequestRewindExtensions.EnableBuffering();
is the alternate.
The alternate is HttpRequestRewindExtensions.EnableBuffering(), indeed. You can see here that internally it just calls EnableRewind().
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 know that for some reason VB.NET was not supported in the first release of Core, but this is meant to be fixed in 2.0...
Can someone tell me where they hide the ASP.NET Core Web Application template? It's there for C# but is missing for VB.NET
VS version 15.3.4
.NET Core 2.0 SDK has been installed
Thank you
As far as I know, Asp.Net Core doesn't support VB.Net in .Net Core. you can see detailed information from the following a link https://github.com/dotnet/cli/issues/587
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
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