During startup of my .NET Core 2.0 web API, I register routes to my controllers via the MapRoute() method. I would like swagger to recognize these routes or allow me to add them during startup. I know the documentation indicates swagger does not support conventional routing out of the box (only attribute based routing), but does anyone have any alternatives to providing documentation for routes created dynamically during startup?
I have created Swashbuckle.AspNetCore.SwaggerGen.ConventionalRouting which replaces the original Swagger generator with a custom one that recognizes conventional routes. It supports ASP.NET Core 2.1 and ASP.NET Core 3.X applications. I have used it in a production application with more than 400 dynamic conventional routes (custom constraints, regexes, etc) and the results are pretty good.
Related
I've used Laravel to build web apps, but now I'm trying to learn ASP.NET CORE. I need to create a custom middleware and apply it to an action of a controller. How can I do it? Thanks.
In .net core sense of middlewares, middleware runs early - before the route is known. Each middleware is used for each request. For what you want, you can use action filters. Action filters can have services injected into them - and will most likely be sufficient for you. https://learn.microsoft.com/en-us/aspnet/core/mvc/controllers/filters?view=aspnetcore-3.1
Here's a link!
Taking the middleware specific approach in .NET Core 3.1, we can conditionally add middleware using the following-
In configure method-
app.UseWhen(context=>context.Request.Path.StartsWithSegments("your-route-url"),branch=>branch.useMiddleware(););
There are a few ways how the pipeline branching can happen, follow the docs for more information-
https://learn.microsoft.com/en-us/aspnet/core/fundamentals/middleware/?view=aspnetcore-5.0#branch-the-middleware-pipeline
When one creates a new server-side Blazor project, you actually get two projects within a solution. Why is this? I suppose it has something to do with the architecture as shown in this diagram from the docs? So in other words, a .NET core process must be used to host the Blazor app. Is that the basic idea? In other words, IIS would serve up the .NET core app, which in turn "serves" up the Blazor app, or something to that effect?
According to "ASP.NET Core updates in .NET Core 3.0 Preview 2" blog article...
https://blogs.msdn.microsoft.com/webdev/2019/01/29/aspnet-core-3-preview-2/
Why two projects? In part it's to separate the UI logic from the rest of the application. There is also a technical limitation in this preview that we are using the same Razor file extension (.cshtml) for Razor Components that we also use for Razor Pages and Views, but they have different compilation models, so they need to kept separate. In a future preview we plan to introduce a new file extension for Razor Components (.razor) so that you can easily host your components, pages, and views all in the same project.
I know that Asp.Net MVC and Asp.Net Web API were merged into one code in Asp.net Core and they inherit from Controller base class and can all return implementations of IActionResult. it be a View for MVC or Json for web api.
But when i want to create a Asp.net Core project, it offers two templates (Web Application and Web Api ), according to what i said in above, there is no differences between these controllers, why there is two templates? is there any differences that i don't know about it?
The web application template will create folders and import stuff needed for a web application such as jquery, css etc. Web api template will create folders and import stuff for a web api. Also the controllers created by default will have different implementations, for example, web application will be returning views and the views will be created in the appropriate folder.
So although they derive from the same controllers, each type of project requires different dependencies.
If I were you I would go ahead and create one for each type and see the difference.
If you want to have both web api and web application in the same project, use areas. This way your web and api will have separate controllers, folders and models. Also if you want to separate them in the future, it will be easy to do so.
The difference between 2 templates is-
The WebAPI template starts with a Controller class that will allow you to respond to RESTful requests at the /api/Values endpoint.
The Web Application template will give you an MVC framework enabled project with some Razor views, the bootstrap CSS framework and jQuery library installed.
If you want to create project with both MVC and API controllers then I would suggest to go with ASP.NET Core Web Application template and add require dependencies.
Let's start with an example:
I've added mvc core to asp.net core pipeline two times on different branches. See following sample codes:
aspNetCoreApp.Map("/1", innerAspNetCoreApp => { innerAspNetCore.UseMvc(...); })
aspNetCoreApp.Map("/2", innerAspNetCoreApp => { innerAspNetCore.UseMvc(...); })
And I've following services configuration:
services.AddMvcCore().AddJsonFormatters().AddApplicationPart(assembly1ForExample).AddControllersAsServices();
I'd like to have something like this too:
services.AddMvcCore().AddXmlFormatters().AddApplicationPart(assembly2ForExample).AddControllersAsServices();
I'd like to use first configuration for first branch ('/1'), and the second configuration for second branch ('/2')
Note that this is a sample only, I'm not looking for some extensibility solutions in asp.net core mvc, I'd like to find a solution in asp.net core itself.
Imaging that You've developed an middleware to write exception details to response. (I'm aware of AspNetCore.Diagnostics package, this is a sample only).
Based on branching you can write something like this:
aspNetCoreApp.Map("/1", innerAspNetCoreApp => { innerAspNetCore.UseBeautifulExceptionWritter(...); })
aspNetCoreApp.Map("/2", innerAspNetCoreApp => { innerAspNetCore.UseBeautifulExceptionWritter(...); })
Now let's imaging that we've a interface to make exception details writing extensible. For example IExceptionDetailResolver, and there is a default implementation named DefaultExceptionDetailResolver. In services configuration I'd like to register different implementations for each usages of that middleware.
In Owin pipeline, I was able to achieve this using nested containers. I created a root container for the whole application, and I created nested containers for each web api configurations.
I was able to register different implementations for asp.net web api interfaces every time I added http configuration to pipeline. For example I was able to add web api several times to owin pipeline on different branches, one time for odata, one time for asp.net web api itself normal usages, and one time for web hooks. And I was able to provided Different IAssemblyResolver implementations for each of them.
How can I achieve this in asp.net core?
Additional notes: I've managed to do this for owin pipeline on top of asp.net core pipeline, and I've no problem with manually developed asp.net core middlewares too. My main problem is with some middlewares like mvc core, identity server, signalr etc.
So I'm about to create my first SPA project using .NET MVC4. But I just need a little clarification before I start. It seems from a few tutorials, SPA is built based on WebAPI architecture.
Is it safe to say SPA = WebAPI + knockout.js + history.js +
upshot.js which all together function as a web application that can
run somewhat offline? so later down the road if we want to build a
native phone app, we can always just call it from the SPA
DataServiceController?
What's the difference between webAPI controller
(that inherits from ApiController) VS SPA controller (that
inherits from DbDataController<..>)
SPA works with WebAPI, history.js, upshot.js. Knockout is not necessarily required (i.e. you can choose your own client-side framework. From what I understand, you need to use Entity Framework as well.
DbDataController is a generic type that requires specifying the DataContext you want to expose. This is not required with ApiController. It seems that there SPA requires using EF, which seems restrictive in my opinion.