The art of simplicity

For the last 2 days I have been struggling with a breaking change I had in my ASP.NET Core web api that caused the consuming application to fail. I had a header parameter that was optional but became required after changing the nullability of my project to enabled . Although I found the issue and was able to fix it quite fast, I was not happy with my current process and was wondering how I could prevent this from happening again. This brought me to a final solution where I introduced some extra tests that compared the OpenAPI metadata between different implementations. Let me show you how I did it… Generate OpenAPI documents at build time To compare 2 OpenAPI metadata documents we first need to get them. For the already released version of the API, I can download the document through the OpenAPI endpoint ( /openapi/v1.json by default). But what about the new version of the API that is still in development? I solve this by generating the OpenAPI document at build time. This m...

Yesterday I talked about a breaking change I had inside my ASP.NET Core web api that caused my application to fail. I had a header parameter that was optional but became required after changing the nullability of my project to enabled . My hope was that this would be visible in the OpenAPI metadata for my OpenAPI. Unfortunately, the generated metadata always looked like this: So both this code: and this code: return exactly the same metadata. The lack of a required property marks this header as optional, which doesn't reflect the actual behavior of the application after enabling nullability. I decided to investigate this a little further and found out that it is possible to emit the correct metadata by explicitly adding a [Required] attribute to the parameter: After adding this attribute the metadata was updated correctly. It’s unfortunate that ASP.NET Core doesn’t do this by default as it is aware of the possible nullability of the provided parameters.

Although it is not the first time that I stumble over the nullability feature and breaking changes, this one still caught me by surprise. Let me first explain the context; I have an application built in ASP.NET Core with the nullability feature still disabled. As I had to make some changes to the API, I though it was a good timing to enable the nullability feature to help me avoid nullreference exceptions. As always I started by updating the application to enable the nullability feature. Therefore set the nullable value to enabled inside the csproj file: After enabling the feature, our integration tests started to fail. Here is the specific error message that got returned: In our API we have the option to pass an optional(!) X-Environment header parameter. We use this attribute to avoid that the API is accidently called from our development or test environment. In our original API implementation this attribute is optional; in case the attribute is ommitted we don’t do the en...

In JUnit you have the @RepeatedTest annotation. This annotation allows you to run a single test method multiple times with different execution contexts. Unlike simply calling a method in a loop, each repetition is treated as a separate test execution with its own lifecycle. Although it can be useful to discover and investigate race conditions, I never had a good reason to start using this kind of functionality. But with the introduction of AI workloads inside my applications, times have changed. As AI output is less deterministic, it now starts to make sense to run the same test multiple times as the AI output could differ from test run to test run. Let me show you how to do this using NUnit and XUnit... NUnit: Built-in Repeat Attribute NUnit provides the most elegant solution with its built-in [Repeat] attribute: XUnit: Using Theory and Custom Attributes XUnit doesn't provide an out-of-the-box equivalent to the @RepeatedTest annotation but you can build your own ...

If you are new to GitHub Copilot or other AI coding assistants, it can be a challenge to get good results as you are still learning on how to write good prompts. What if there was a way to automatically transform your basic prompts into comprehensive, context-rich instructions that consistently produce better results? Enter Prompt Boost , a VS Code extension that bridges the gap between what you quickly type and what AI models actually need to generate high-quality, relevant code. What is Prompt Boost? Prompt Boost is a VS Code extension created by Chris Dias that enhances your prompts by adding relevant technical context, best practices, and specific requirements. Instead of sending bare-bones requests to GitHub Copilot, it helps you create detailed instructions that lead to more accurate and useful responses. The extension transforms your basic prompts into comprehensive specifications. Here's a real example of the transformation: Before (Basic prompt): Create a new l...

After upgrading the .NET Aspire NuGet packages to the latest version on one of my projects, I started to get the following compiler error: 'Project' requires a reference to "Aspire.AppHost.Sdk" with version "9.0.0" or greater to work correctly. Please add the following line after the Project declaration <Sdk Name="Aspire.AppHost.Sdk" Version="9.0.0" /> . The error message is self explanatory and clearly defines how we could fix this. Add the Sdk reference to your csproj file to get rid of this compiler error: The strange thing was that after applying the upgrade on one branch, I also started to get the same compiler error on other branches although the Aspire NuGet were not (yet) upgraded on these branches. Bizar! More information Compiler Error ASPIRE007 - .NET Aspire | Microsoft Learn