I decided that having the web client (blazor) in the same solution is an acceptable solution regarding debugging and the fact that they are also shipped together. Therefore I made use of the Blazor WASM (ASP.NET Core Hosted) template in Visual Studio. Now I started another project and decided to go for an easy to use application (api + frontend shipped from the server - easier to setup). ASP.NET Core 5 Web API + Blazor WebAssembly (Hosted in WebAPI) Using this flow makes the usage in the daily workflow very easy. The client library is pushed to a NuGet feed and then consumed by the Xamarin application. I currently have my Xamarin project in a separate solution. This works! (Very good! Thanks to Rico Suter for NSwag!) This client project is then used by Xamarin.
This is done using an MSBuild target which generates code into a C# Client project. I am using NSwag to automatically generate the C# client in the first project. : updated examples to aspnetcore 2.2 and NSwag 12.I currently have two projects: 1.: updated examples to aspnetcore 3.0 and NSwag 13.: upgraded to ASP.net core 3.1, moved client generation to Api project, and added output logging to MSBuild.CreditsĬover photo by unsplash-logo Modestas Urbonas Updates
There is an MSBuild “trick” to ensure the correct build order without adding an assembly reference to the Api project but as said, you shouldn’t need that. In short, this should never happen in practice. So as soon as you compile those changes the Client project will be updated. But, to generated a changed client you will always have to modify the Api project first to add or modify some Controller. Theoretically the generated code can get out of sync when the Client project builds before the Api project. So I decided to swap it around and make the Api project generate the code into the Client project instead. This caused quite some build errors when concurrently building because the Client project had an implicit dependency on the Api project. NOTE: I used to do this the other way around, meaning that the Client project contained the NSwag MSBuild target. Want to generate a Typescript client, check out this post
Take a look at the wiki for NSwag if you want to know how to do this and what else NSwag can do. For example NSwag can also generate Typescript clients. I have only shown you a very basic example. NSwag has a bunch of options to customize and tweak how the clients and contracts are generated. If you encounter issues with this example create an issue on that repository or leave a comment here. Having the Client project in the same solution as your aspnetcore API allows you to automatically build and publish up to date clients for your API.Ī fully working example is available on GitHub. All that is left to do is to package your Client project as a NuGet package and share it with the users of your API. Now build the Api project to generate the clients and contracts and the build your Client project. You can also add extra behavior such as retries (with Polly). NET Core to configure the HttpClient (this is why you have to set injectHttpClient to true). The output and contractsOutputFilePath parameters use the CSharpOutputPath to place the generated code in the Client project instead of the Api project. Make sure you set disposeHttpClient to false if you use a dependency injection container to handle the lifetime of your HttpClient. Make sure you set generateClientClasses, generateClientInterfaces, and injectHttpClient. public void ConfigureServices ( IServiceCollection services ) Use this method to add services to the container. This method gets called by the runtime. Next add the following code to your Startup.cs:
Configure Swagger and SwaggerUI with NSwagįirst add the NSwag.AspNetCore NuGet package to your API project: These clients can be packaged and published through NuGet for easy access to your API’s. In this blogpost I will show you how to configure Swagger an NSwag so that up to date API clients are generated and compiled each time you build your solution. With NSwag you can generate client code without having your API running, many generators require the swagger.json file that is exposed when you run your API but NSwag doesn’t. Once you have Swagger enabled you can also use the information Swagger exposes about your API to generate clients for the enpoints and operations your aspnet controllers expose.
When you create an API using aspnetcore it is very easy to add a Swagger endpoint and SwaggerUI for exploring and testing your API. Want to generate a Typescript client, check out this post Background Want to know how you can generate and compile up to date C# API clients each time you build your solution? Take a look at this example on GitHub.