It’s time for the annual “State of the Blog” post! The previous one, for 2023, is available here.
I didn’t blog as much as I expected a year ago, but we still got some useful posts on AWS and Swagger.
The average number of monthly visitors is 1.3k a month, a slight increase year over year. More numbers below!
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.