When moving from OWIN to ASP.NET Core, I've found a bit of information about dependencies to migration, but I've not found information about these other topics:
The middle-ware pipeline. How is this different, or not?
The DelegatingHandler pipeline (e.g. Web API). How is this different, or not?
The startup.cs file. How is this different?
In short, it would be great to know what are the primary hot-spots that would need my attention, in order to move from OWIN to ASP.NET Core.
As a first example - ASP.NET Core does not appear to have HttpConfiguration. There are myriads of example plugins and services that assume its existence. I'd like to infer how to translate instructions for HttpConfiguration into whatever approach ASP.NET Core expects.
As another example, the Swashbuckle documentation gives instructions for setup with OWIN, but those instructions don't work with ASP.NET Core. If I understood the primary differences from OWIN, it would be easier to "guesstimate" how to install Swashbuckle into ASP.NET Core.
Note: Swashbuckle also gives instructions for self-hosted apps. That confuses me because I think of OWIN (vis-a-vis Katana) as being self-hosted already, and so it sounds redundant to me. But I don't think this is related to the present question.
My question has used Swashbuckle as an example, but I am not asking about Swashbuckle specifically.
Update
I've discovered that much of the information I'm looking for is in the article Transitioning from Web API 2 to ASP.NET MVC 6.
Middleware is quite similar between Katana and Core but you use HttpContext instead of IOwinContext.
Startup.cs is similar but there's much more DI support.
WebApi has been merged into MVC
DelegatingHandler is gone, use middleware instead.
HttpConfiguration has been split up into Routing and MvcOptions.
Also https://devblogs.microsoft.com/aspnet/katana-asp-net-5-and-bridging-the-gap/
I think you can start here. It's an entire chapter about OWIN with ASP.NET Core. Hope this helps.
Related
Is there a way to enrich Serilog log data in ASP.NET Core 2.1 application, similar to how enrichers WithUserNameand WithHttpRequestUserAgent work for classic ASP.NET (System.Web)?
I tried implementing ILogEventEnricher interface, but it does not work, because I am not able to gain access to RequestContext from my custom enricher.
As pointed out in the comments it seems like Add Username into Serilog would serve your purpose and would also be the duplicate of this issue.
As I understand it, ASP.NET Core has support for OWIN middleware (via app.UseOwin()) in addition to its own native middleware.
What is the difference between ASP.NET Core middleware and OWIN middleware?
When designing a new middleware, how do I know if I should design it as a ASP.NET Core middleware or a OWIN middleware?
Your question made me curious and I would like to share, what I have learned so far.
Katana is the implementation of the OWIN spec. After version 3.0 of Katana this technology has been fully integration in the web stack we know as ASP.NET Core today.
While this transition much has stayed similar to the OWIN specifications. Although some changes have been made. In order to use existing OWIN middleware in ASP.NET Core the supports OWIN by an optional feature ("app.UseOwin()").
If you want to target with your middleware ASP.NET apps and ASP.NET core apps, then I would use OWIN middleware. If you want to give ASP.NET Core developers a first class citizen experience, then a ASP.NET Core middleware would be recognized as more "fitting".
Some information about the relationship between ASP.NET Core middleware and OWIN middleware can be found here:
Katana, ASP.NET 5, and bridging the gap
Katana Project
https://docs.asp.net/en/latest/fundamentals/owin.html
I have come to understand it as this; ASP.NET Core middleware is on a higher level than OWIN middleware which is on a lower level.
ASP.NET Core middleware has the advantage that it is much easier to develop a middleware in as you get passed in the HttpContext which you can use. The disadvantage is that the middleware you develop depends on ASP.NET Core.
OWIN is on a lower level and you get a OWIN environment which is a IDictionary<string, object>. The advantage is that is it not tied to ASP.NET hence can run on any OWIN server (such as Nowin). The disadvantage is that it takes more effort to code since you have to build your own context from the OWIN environment or use the OWIN environment dictionary directly and keep track of all OWIN keys and objects.
Edit: You don't have to keep track of OWIN keys yourself, you can use the OwinEnvironment class to get a strongly typed environment.
var environment = new OwinEnvironment(HttpContext);
var features = new OwinFeatureCollection(environment);
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
i need few reason for which people mixed ASP.Net MVC and web-api in same project. when we can develop a full project in mvc only then why web api need to include. also we can host webapi project separately which can server request to MVC and other devs or mobile devs etc.discuss the reason and advantages.
some one answer :
We have recently built a project within MVC and WebApi, we used the WebApi purely because from a Mobile Apps perspective. We allowed the mobile dev guys to call our methods within our MVC application instead of them having to go and create the same function.
WebApi allows to create services that can be exposed over HTTP rather than through a formal service such as WCF or SOAP. Another difference is in the way how WebApi uses Http protocol and makes it truly First class Http citizen.
still the above answer is not clear to me and i think this is not the reason for which people mixed ASP.Net MVC and web-api in same project.
so anyone mind to discuss the actual reason and advantages with example scenario.
thanks
Each have a purpose. Most of the time it's usually caused by legacy code. I know we included documentation which used MVC, but we're fully webapi.
FYI, was MS's auto documentation for WebApi ironically.
I am looking for an ioc container to use for asp.net webapi. Couple of the key feature we are looking for are as follow
Custom lifetimes
Built-in support for web request lifetime
Good integration with web api in terms of manage the dependency registration.
Mark Seemann knows his DI/Ioc and has an article on implementing it for Wep Api with Castle Windsor here. I don't know about custom lifetimes but it definitely solves the second and third requirements.
Castle is not as lightweight as say Autofac but it's been around for years and is tried and tested: I am using Castle for my Web Api and Mvc projects without issue so far.
Both should do the job though.
I personally like Unity. The reason why I use Unity is that it is build by Microsoft and with that you can expect that it is nearly up-to-date. Also I had prior experience with it and it has good support for ASP.NET Web API, but the final choice for or against a container is up to you. It really dependent on personal flavor.
There's a small part in the ASP.NET tutorials which talks about using Unity with Web API.