New Swashbuckle release with .NET 8 support
Swashbuckle.AspNetCore v6.6.1 was released recently, bringing native .NET 8 support and other improvements, so it’s time to update if you experienced related problems before.
>>> Continue reading <<<
Swashbuckle.AspNetCore v6.6.1 was released recently, bringing native .NET 8 support and other improvements, so it’s time to update if you experienced related problems before.
An application running periodically based on a schedule with no interface to interact with it directly (often called background worker) is quite common in today’s architecture design.
In this article, we’ll explore how we can create a Lambda function using an AWS template, define an EventBridge scheduler to run it automatically and deploy everything to AWS using a Cloud Development Kit (CDK) stack written in TypeScript.
Even though we are using dockerized C# lambda function, any supported language would work just as fine, with CDK code being almost identical.
Generating an OpenAPI (Swagger) file during build time is a common scenario, usually done to generate the API client automatically. There are a few ways we can do it,
dotnet swagger tofile
command from swashbuckle.aspnetcore.cli tool being one of them.
Usually, when migrating to a new major .NET version, it’s a good idea to update dotnet-tools.json config file to use the latest swashbuckle.aspnetcore.cli.
However, there is no new version of swashbuckle.aspnetcore.cli for .NET 8, moreover, there is a confusing statement about build-time swagger generation in the official ASP.NET documentation:
Build-time OpenAPI document generation with Swashbuckle isn’t supported in .NET 8 and later. […] Run-time document generation is still supported in .NET 8.
Let’s review the problem and a solution.
UDPATE (5/22/2024): there is a new release of Swashbuckle with .NET 8 support, try getting the latest version if you encounter any problems.
At some point in your Unity 3D development cycle, you may find yourself in a situation where your build size feels much bigger than you would expect.
In this post we are taking a look at Unity 3D tools we can use to get some insights into what’s consuming your precious build bytes.
A smaller size of a game or application is probably one of the most important non-functional requirements since it will make the app download (the first user experience) faster and more pleasant, thus improving the store conversion and saving users drive space.
For some reason, my app, Piano 3D, is not downloaded much even though there are a lot of people visiting the Store Page. It’s a bit disappointing, as is the fact that the app gets 23rd place for “piano” search term in the Windows Store. Probably this is related to low conversion too.
So the question is, of course, how to improve the conversion. I’m not an expert, but I’ll try the following:
This post will be the baseline for future updates, so just want to track conversion change. If you have any advice on what may be wrong, the comments are opened and you are more than welcome.
I’ll attach more statistics just for historical reasons.