I've been following this guide to create developer friendly documentation for my ASP.Net REST WebApi using Swashbuckle.
However, the current version Swashbuckle.AspNetCore v2.2.0 generates a huge single page app, which is confusing for my users.
If I remember correctly, Swashbuckle was generating separate pages for each controller/method (early 2017?). My configuration looks like this:
app.UseSwaggerUI(c =>
{
c.SwaggerEndpoint("/swagger/v1/swagger.json", "API V1");
c.EnableFilter();
c.MaxDisplayedTags(5);
});
Q: Is there any way to make Swagger-UI generate separate pages for each controller and method instead of a huge single scrolling mess?
Some more Details:
VS2017
Microsoft.AspNetCore 2.0.0
Microsoft.AspNetCore.Mvc 2.0.0
Swashbuckle.AspNetCore 2.2.0
Pure WebApi - only JSON is generated, no HTML at all.
Self Hosting via Kestrel on
either Windows using net 4.6.2 (here Swashbuckle is used)
or embedded Linux using dotnet core 2.0 (Swashbuckle disabled)
Swashbuckle.AspNetCore v2.2.0 has support of arbitrary grouping of API actions into multiple Swagger documents.
Please refer the documentation here:
https://github.com/domaindrivendev/Swashbuckle.AspNetCore#generate-multiple-swagger-documents
Related
In ASP.NET Core 2.2 it was rather straightforward to have an ASP.NET Core website with React front-end and working server-side rendering - since SSR was supported out-of-the-box in the ASP.NET Core+React template, which internally run the NodeServices to executed the javascript using node.
However with ASP.NET Core 3.1 things are not so easy anymore, mainly because the SpaServices and NodeServices classes are declared as obsolete and will be removed with .NET 5, according to this link. So no javascript execution with node from C# anymore.
Now, besides the information, that the server-side rendering suggested in ASP.NET Core 2.2 is now obsolete, the only suggestion how to go forward I found is from above article:
To enable features like server-side prerendering and hot module reload please refer to the documentation for the corresponding SPA frameworks.
But if I understand correctly, to have react-based server-side rendering, I need to have a node.js server which will perform the rendering on the server-side.
Does that mean, that if I want to have an ASP.NET Core 3.1 website with a React front-end with SSR - I should have one ASP.NET Core project for the WebAPI, and another separate Node.JS project for the front-end with SSR?
And then deploy them on two separate Azure AppServices?
Is that the recommended architecture for ASP.NET Core + React projects?
I came across exactly the same problem. It took me a few weeks to create a new set up where frontend is separate from the backend.
I published the prepared boilerplate on GitHub and wrote a blog posts that explains how to enable server-side rendering with ASP.NET Core and React in details. The solution is a combination of CRA (Create React App), Storybook for CRA and a standard ASP.NET Core MVC template.
To make a long story short I built my custom asp-prerender-module and asp-prerender-data attributes. They communicate with an Express server based on Node.js to get the rendered HTML. Thereafter the HTML served to the browser gets "hydrated" with actions.
After spending some time researching, that are the current options:
Live on .NET Core 3.1 with the NodeServices with an obsolete flag
Create separate projects for back-end (asp.net) and front-end (node.js)
Fork/copy NodeServices and maintain by myself
Hope that a there will be a community driven fork of the NodeServices in the comming months before .NET 5 release were it will be removed eventually
You can use a new library to invoke JS from .net which is
https://github.com/JeringTech/Javascript.NodeJS
You can use SSR on .net with the above library Razzle described here:
https://dev.to/pruttned/integrating-react-into-asp-net-core-using-razzle-with-all-the-goodies-like-ssr-routing-code-splitting-and-hmr-part-1-2-34g8
BUT at the time of writing I find that there is no information on how to deploy such an application.
Reactjs is working on the Server component to stream partially rendered UI in the form of JSON data to clientside. https://github.com/reactjs/rfcs/blob/2b3ab544f46f74b9035d7768c143dc2efbacedb6/text/0000-server-components.md
I think for future integration of Server component, it needs a native NodeJS process to handle server rendering.
I am using Service Fabric with .net core with Service Fabric Remoting V2. and I am building a multi-tenant app and I want to add custom header to send the tenant ID automatically.
I have started with the solution for this question which uses normal .net framework with service fabric but in the case of .net core it didn't even compile since the service fabric with .net core has different APIs and Methods.
The code goes as follows and There are many cases for non existing APIs:
The Client
ProxyFactory
var _proxyFactory =
new ServiceProxyFactory(c => new ServiceRemotingClientFactoryWrapper(new WcfServiceRemotingClientFactory(callbackClient: c)));
The bold class comes from the Microsoft.ServiceFabric.Services.Wcf package (aside whats said in the nuget site) it is asking me to add a System.ServiceModel Dll which is a full .net library and not even in the stated dependencies.
The ServiceRemotingClientWrapper provided in the solution contains a class named ServiceRemotingMessageHeaders which according to documentation is the in the service remoting class but it doesn't exist.
Also the functions in the interface take IServiceRemotingRequestMessage which is different from the aforementioned demo.
The Server
the class ServiceRemotingDispatcher should be in the remoting Dll and yet it doesn't exit.
Finally, This project uses the same methodology to implement my goal and its based on the same SOF question but uses full .net framework and it works. Link to project
I'm having issues with a SignalR project I'm currently working on. I'm trying to build a server using .Net Core, and a client using traditional .Net (framework 4.6.1). However the server and client don't seem to be compatible.
The last issue I've run into is a StatusCode: 405, ReasonPhrase: 'Method Not Allowed'. I found an answer on GitHub that states that there are many breaking changes between versions.
Looking at the NuGet package versions available, I get even more confused. for the .Net Core server I'm using 1.0.0-preview1-final. There's also a 1.0.0-alpha2-final available, but I have no clue if 'alpha' is newer or older than 'preview'.
On the client side I was using version 2.2.2, and there's a whole range of versions to choose from, I tried the oldest and latest, but both versions give me the same "method not allowed" error.
The error is on the client side, on the server side, my breakpoints are not even hit, so it could be an Owin/iis issue as well.
Is there any chart out there that can map SignalR clients and server version compatability? I guess that would be a great step moving forward.
You can't mix the .NET Core 1.x with the older client (1.x or 2.x). You will need to decide which is the best option for you but you need to implement the same compatible version across CLIENT and SERVER.
Check the link for more details but essentially:
What’s Changed?
We added a number of new features to SignalR for ASP.NET Core but we
also decided to remove support for some of the existing features or
change how they work. One of the consequences of this is that SignalR
for ASP.NET Core is not compatible with previous versions of SignalR.
This means that you cannot use the old server with the new clients or the old clients with the new server.
Check the services are injected, possible some is not yet injected in the service container.
When add the signalR service you can enable detailed errors to know what is happening.
builder.Services.AddSignalR(o=>
{
o.EnableDetailedErrors = true;
});
I need some clarification on API versioning in .Net Core framework.
My client want the version to be handled in Router level. Like
[Route("1/[controller]")]
public class SampleController : Controller
{
[HttpGet("version")]
public IActionResult GetVersion()
{
return Ok({"Message": "API Version 1"});
}
}
I access this using, https://www.somedomain.com/api/1/sample/version
In IIS, I will create an application called 'api' (The path 'api' in my URL will be taken care here) under default web site and host my code here.
In order to do API versioning, what is the better way that I can follow here.
Can I do this?
[ApiVersion("1")]
[Route("{version:apiVersion}/[controller]")]
public class SampleController : Controller
{
[HttpGet("version")]
public IActionResult GetVersion()
{
return Ok({"Message": "API Version 1"});
}
[HttpGet("version"), MapToApiVersion("2" )]
public IActionResult GetVersion()
{
return Ok({"Message": "API Version 2"});
}
}
Is it possible to create an application under an application in IIS. Like,
Default Web Site - > api -> 1 -> Code without API version mentioned
Default Web Site - > api -> 2 -> Updated Code without API version mentioned
Or can I create the versions as application in IIS and deploy the code under each applciation version. Like,
Default Web Site - > 1 -> Code without API version mentioned
Default Web Site - > 2 -> Updated Code without API version mentioned
This will end up in changing my API URL, which i don't prefer. I still want to go with the same URI.
I access this using, https://www.somedomain.com/api/1/sample/version
Please advise the best approach that I can follow here.
Here is a popular repository that provides a set of libraries for adding API versioning to ASP.NET Web API, OData with ASP.NET Web API, and ASP.NET Core applications.
For ASP.NET Core applications, you can install this repository's ASP.NET Core API Versioning by running the following command in the Package Manager Console:
Install-Package Microsoft.AspNetCore.Mvc.Versioning
Perhaps the Map extension method of ApplicationBuilder suits your needs :
app.Map( "/1", myVersion1MappingFunction)
in the Configure method of Startup let myVersion1MappingFunction configure a separate middleware pipeline:
private static void myVersion1MappingFunction( IApplicationBuilder app)
{
// start your special middleware for version 1
app.UseMvc( routes =>
{
routes.MapRoute( ... );
}
}
On using Map extension the fragment ("/1") is removed from HttpRequest.Path
If I understand you correctly are wanting to use URL Path Segment Versioning for ASP.NET Core. With that said in your examples you will NOT have separate website deployed. You have one website deployed and you do NOT create multiple applications for versioning under your default website.
With URL path segment versioning you have one web application and that application manages all routes using the ApiVersion convention. You will need to maintain the code in such a way that it can deliver old functionality with new functionality and manage all dependencies.
I would recommend reading what Microsoft has to say about this here and doing a simple proof of concept that makes sense for your implementation.
I hope this helps clear up your confusion about deploying the application multiple times for versioning.
In your case the best method would be to employ the versioning from the web server level so you can have different deployments and a folder per version without specifying a version in the application routing itself. (your option 2/3?)
However since IIS merely proxies requests to kestrel with .net core unlike asp.net, you'll have to setup the reverse proxy by URL/URL Re-write with ARR to different versions of the deployment.
So you could have:
/root/V1/
/root/V2/
etc... like you explain.
Each deployment would be running kestrel with different ports numbers and IIS would re-verse proxy to them by URL.
Here is an article on how to setup ARR with url-write. it's written with asp.net in mind, but it's the same principal:
Reverse Proxy with URL Rewrite v2 and Application Request Routing
In my application I have the following two nuget packages installed:
Microsoft.AspNet.Cors - 5.2.2
Microsoft.AspNet.WebApi.Cors - 5.2.2
My application is a WebAPI back-end connected to an AngularJS front-end. The back-end and front-end are on different web servers. The application uses bearer authentication and logon is estabilished with a call to /token. I am using ASP.Net Identity 2.1
I have managed to get CORS working by following directions from here:
http://www.codeproject.com/Articles/742532/Using-Web-API-Individual-User-Account-plus-CORS-En
However I would like to learn more about the differences between the two Cors packages. Are they both required for my type of project and when would one use the AspNet.Cors and when would one use the WebApi.Cors?
Microsoft.AspNet.WebApi.Cors: use it to enable the CORS request ONLY for the Web APIs.
Microsoft.AspNet.Cors: I think you can use this when you want to enable CORS for your MVC controllers.
Microsoft.Owin.Cors: use it to enable CORS for all cross-origins requests coming to your site, so if you use Web API and SignalR for example and you want to enable CORS for both- use Microsoft.Owin.Cors library.
Hope that helps.