By default, the OpenAPI specification created by Swashbuckle for ASP.NET Core web API doesn't include the descriptions for endpoints and models from XML comments. There are step-by-step instructions how to add them in the documentation, but even then there will be no descriptions for models from other assemblies.
GitHub Actions can be a good choice for deploying an ASP.NET Core application to an Azure Web App Service if you have the code in a GitHub repository. You can even generate the GitHub Actions workflow directly from the Azure Portal. However, if your solution is not very simple, the generated workflow may not work correctly.
In a previous blog post, I looked at integration testing of ASP.NET Core Web APIs. But often unit tests make more sense. So instead of checking the already serialized responses from the REST service, you would check the value returned by the controller action method before it is serialized into an HTTP response by the ASP.NET Core runtime.
I recently had an issue with optional route parameters in ASP.NET Core Web API not showing as such in the Open API specification generated by Swashbuckle. The most comprehensive source of information I could find on this issue was a blog post, which I used as a basis for further research.
An endpoint in my ASP.NET Core web API project suddenly started returning a truncated JSON response with a 200 response code. According to the logs, an exception was thrown, but for some reason the response code was not 500 as I would expect.
ASP.NET Core provides great support for integration testing of Web APIs. You can host the server in the test process and still make requests over HTTP. However, if your app reads its configuration from the appsetting.json file, you'll quickly find that the test server cannot find your regular configuration file.
Braintree's Hosted Fields offering is a great compromise between payment form customization and PCI SAQ A compliance requirements. Although it is not immediately evident from the documentation, the payment form can also easily be extended with custom data fields that your business might require. This post demonstrates how to do it in an ASP.NET Core application.
If you're used to the old ASP.NET, it's not all that obvious how to deploy an ASP.NET Core application to IIS. Although, there is documentation available for the process, I still struggled a bit, before I got everything working. This post contains the steps I had to take, so that I can simply follow them the next time. At least, until something changes again with one of the future releases.