I am new in ASP.Net core and migrating framework code into asp.net core but not understanding how to convert below code into asp.net core.
HttpContext.RewritePath(HttpContext.Request.RawUrl.Substring(0, HttpContext.Request.RawUrl.IndexOf("?", StringComparison.Ordinal)), string.Empty, queryString);
Rewriting the path in ASP.NET Core is as simple as running a middleware very early in the pipeline that manipulated the relevant parts of the http request. You can tweak Path, PathBase, QueryString etc and affect the middleware that runs after the rewrite code. This is what the rewrite middleware does that ships as part of ASP.NET Core.
Related
I have the following projects in my solution all .net core 5.0.
myproject.domain
myproject.infrastructre
myproject.webAPI
myproject.UI.Razorweb page.
Instead of using SPA which calls the webAPI, I am using razor web page which will call the webAPI(.net 5.0). My question is can we merge the webAPI and the razorwebpage into one? Can we write webAPI in the razor web page itself?
Is that allowed?
I agree with the suggestion given by Jeremy.
You should have a web API and Razor project separate.
Besides, if you would like to make some tests then you could refer to the articles below.
Use Razor Pages, MVC, And Web API In A Single ASP.NET Core Application
Hosting ASP.NET Core Razor Pages and Web APIs in a Single Project
Razor pages and webapi in the same project
I'm working on migrating an ASP.NET WebAPI application to ASP.NET Core. In this application I'm using batch routes (as described here: https://devblogs.microsoft.com/aspnet/introducing-batch-support-in-web-api-and-web-api-odata/). It's quite elegant - all I need to do is to map a batch route using config.Routes.MapHttpBatchRoute, and then just batch whatever API requests I want to from the client. However, I haven't found an alternative to this in ASP.NET Core. Does it exist, or do I need to write batch APIs myself that perform what I need to do?
I've had success using this library: https://github.com/Tornhoof/HttpBatchHandler
It works for .Net Core 3.0 and newer. The documentation isn't the best though.
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 have a large Visual Studio solution with several ASP.NET web sites with a mix of WebForms, MVC and WebAPI. What I'd like to be able to do is add an ASP.NET Core project to this solution to provide MVC, Razor Pages, WebAPI and SPA (Vue.JS in this case) facilities. The plan is to take each WebForms page at a time and convert to the new framework.
I'll target .NET Framework and the Core site will share some assemblies from the WebForms - but no state is shared except a session cookie and any state stored in the database.
I specifically want to be able to serve the new framework from IIS Express on the same port. So for example, an old page such as http://localhost:1234/page1.aspx will be converted to http://localhost:1234/core/page1. However, I'm unable to simply change the Core project to be hosted on IIS Express and change the path to http://localhost:1234/core. I have managed by following instructions to host in IIS but this has several disadvantages for development. I've also tried adding <urlRewrite> configuration to the WebForms site to forward requests to Core running on a different port but I wasn't very successful and I believe POST request are not supported which renders it fairly useless!
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);