The art of simplicity

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

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

f you have never heard about Property based testing, I would recommend to check my blog series about it first. But if you are too lazy to go through all these posts, here is a short definition: Property-based testing is a powerful testing methodology used in software development to verify that a system behaves correctly across a wide range of inputs. Instead of writing individual test cases with specific inputs and expected outputs, property-based testing defines properties —general rules that should always hold true for a given system. It serves as an alternative to example based testing where we focus on a set of example cases to validate the behavior of our code. There are a lot of libraries out there that help you write Property Based Tests. In .NET I mainly use FSCheck and CSCheck . As I’m doing more and more Python, I also start using Property Based Tests there through Hypothesis . In this post I’ll focus on FSCheck and how to update to the latest version as some breakin...

While working in Visual Studio today I noticed a message appear at the top my idea. The message stated the following: Speed up your git experience in Visual Studio by enabling the git commit graph algorithm. No idea what that exactly means but that sounds promising… so let’s find out Why this commit graph algorithm? Git repositories can become sluggish as they grow in size and complexity. If you've ever waited impatiently for git log to load or noticed that branch operations take longer than they should, you're not alone. Recently, Git introduced a powerful feature that can dramatically improve performance: the commit graph algorithm. The commit graph is a data structure that Git uses to store precomputed information about your repository's commit history. Instead of traversing the entire commit tree every time you run commands like git log , git merge-base , or git show-branch , Git can use this precomputed graph to answer queries much faster. Think of it ...

Not a long post today, just an interesting visualization I noticed; the LLM timeline . This timeline shows the fast evolution of large language models over time starting from the original "Attention Is All You Need" paper by Google researchers to today's cutting-edge models. Nice! A big thank you to Michael Gathara for creating and maintaining this visualization. More information Attention Is All You Need LLM Timeline