The art of simplicity

Ever wondered how Microsoft is using some .NET features in it's own codebase? One way to find this out is through the .NET Source Browser . This site allows you to browse through all the .NET source files and find out how specific features are implemented or specific classes used. For example, I’m working on a piece of code where I wanted to use the Channels API but I was wondering how it was implemented. And what better place to learn than from the creators themselves? So I opened up the .NET Source Browser and searched for Channel.CreateBounded : This returned multiple results: When you click on a specific result you arrive at the specific source file and can further check the implementation: Another option is to go through the official .NET documentation and click on the source links there: This brings you to the code source in GitHub:   Have fun browsing through the codebase! More information Source Browser .NET API browser | Microsoft Learn

For security reasons I am switching to a different account on my development machine. After adding this new account to Windows and setting up the Visual Studio configuration for this new account, I thought I was good to go. So I opened a first solution inside my fresh Visual Studio instance. Everything looked OK at first sight, but then I noticed a small warning message at the right bottom corner of my Visual Studio: And when I took a look at the Git Changes window, no changes were shown:   What is going on? Starting from Git v2.35.2 , Git now checks for ownership of the folder trying to ensure that the folder you are using Git in has the same user as the owner as your current user account. As the original Git repo(and corresponding Windows folders) was created using a different account, Git considers this repository as unsafe. This check was introduced in Git to tackle a security issue which allows parent repositories directories to override permissions of child reposi...

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 ...