The art of simplicity

I talked last year about vscode.dev as a way to bring Visual Studio Code to your browser. But did you know that this experience got nicely integrated into Github? Hit the . key on any repository and the github.dev web based editor is loaded. It also works for pull requests: You can make your changes and directly push them back to Github. Nice! And that is only the beginning, if you want to learn about some cool things you can do with Github.dev, check out this post: https://dev.to/lostintangent/10-awesome-things-you-can-do-with-github-dev-5fm7

At work I use C# most of the time, but for my pet projects(don't we all have pet projects?) at home I prefer to use F#. I do think that functional programming is the future and if you have a look at the latest language features that are added to C#, it is becoming more and more functional. When you get started with F# for the first time, there are 2 struggles you need to go through: #Struggle 1 -  Getting to know the syntax of the language #Struggle 2 – Understanding the functional paradigm and how to write idiomatic F# To help you go through the first struggle, the following guide will be your friend: A good follow-up is the old but still relevant F# introduction at PDC 2008(!):

Yesterday I introduced the concept of an SBOM, a Software Bill Of Materials. An SBOM lists all the components that make up the software , or were used to build it. I showed you how to use the docker sbom command to generate such an SBOM for your container images. Today I want to show you how you can use this generated SBOM to check for vulnerabilities. The tool we want to use for this is Grype. Install Grype on Windows Out of the box, Grype is only built for Linux and MacOS.  As I’m a Windows user, probably the easiest way to get Grype running on your system is through WSL(Windows Subsystem for Linux). Open up a terminal to your installed Linux Distribution(I typically use Windows Terminal), or if you didn’t have a Linux distribution installed yet, install a distribution of your choice: wsl --install -d Ubuntu Downloading: Ubuntu Installing: Ubuntu Ubuntu has been installed. Launching Ubuntu... After the installation has completed, a new menu item

One element to improve the security of your software systems, is the Software Bill Of Materials(SBOM). Today most applications are build using a combination of open source and commercial software components. The SBOM lists all the components that make up the software , or were used to build it. The concept of a BOM is well-established in traditional manufacturing as part of supply chain management.A manufacturer uses a BOM to track the parts it uses to create a product. If defects are later found in a specific part, the BOM makes it easy to locate affected products. The recent Log4J vulnerability was a good example of why such an SBOM is important to find out if one of your systems or applications is impacted or not. Some of my customers had no idea if they were impacted or not and had to search through all there systems and applications which of course is time consuming and error-prone. Docker sbom Starting from Docker Desktop 4.7, a new CLI command is introduced that display

Until recently, .NET Core updates were not automatically installed on Server Operating Systems. Starting from this month, this has changed and monthly updates can be automatically rolled out on your servers as an opt-in feature. How to opt in? To opt in for automatic updates, you need to set one or more registry keys on the server: . NET Version Registry Key Name Value Allow All .NET Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET] "AllowAUOnServerOS" dword:00000001 Allow .NET 6.0 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\6.0] "AllowAUOnServerOS" dword:00000001 Allow .NET 5.0 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\5.0] "AllowAUOnServerOS" dword:00000001 Allow .NET 3.1 Updates [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NET\3.1

One of my ASP.NET Core applications hosts both an API and a website. There are multiple places where authentication and authorizaton rules are checked: In the Accountcontroller Login Action method In a custom AuthorizationHandler In a custom IAuthorizationFilter Remark: Don’t ask me why we have all these places, that is maybe something for another blog post. Recently I had to make a change to the application so that depending if the request was coming from the website or through the API, a different message was returned when authorization failed. I didn’t like the idea that I had to implement the same change 3 times, so I started to search for a better solution… The solution I found the solution in the implementation of the IAuthorizationMiddlewareResultHandler . By implementing this middleware, you can: Return customized responses. Enhance the default challenge or forbid responses. That is exactly what we need!. Here is a simplified example: Re

By default logging inside XUnit can be done through the ITestOutputHelper . But this is only useful in situations where you are inside in your test code and have direct access to this interface. Most of the logging in your application however, is typically happening inside the application logic itself(through the ILogger<T> provided by .NET). So if we want to capture this information, we need a way to create a bridge between the two. Luckily we don't have to create such a solution ourselves, but can use one of the available open source projects that solve exactly this issue. I decided to give MartinCostello.Logging.XUnit a try. Installation To install it, just add is as a Nuget package to your XUnit test project: dotnet add package MartinCostello.Logging.XUnit Usage To use, it you should register the adapter as your ILogger in Microsoft DI container: Remark: I first had a look at Divergic.Logging.Xunit but it wasn't so easy to integrate it as p

For your async API’s it is a general good practice to allow to pass a CancellationToken parameter. This parameter allows you to check if a cancellation is requested and to handle this properly. Tip: If you want to learn everything about the correct way to use CancellationTokens and handle cancellation in your code, check out the great blog series about this topic from Stephen Cleary. While reviewing some code, I noticed an API where I forgot to add the CancellationToken parameter, so I updated the code like this: The compiler didn’t like this and complained with the following error message: Starting from C# 7.1, you can easily solve this by using the default literal :

I t has been a while since the last time I did some web development using Angular. Today I had to troubleshoot an existing application, so I compiled the Angular code and opened my browser for a debugging session. First thing I noticed however was that although the Javascript code was executed succesfully, no CSS styling was applied. When I had a look at the browser errors I noticed the following error message: Refused to apply style from ' https://localhost:3000/assets/styles/style.css ' because its MIME type ('') is not a supported stylesheet MIME type, and strict MIME checking is enabled. Whoops! That was an error message that didn’t ring a bell. The error turned out to be more scary than the root cause of the issue. It turned out that the path to the CSS file was incorrect and that a 404 response was returned from the server.  I fixed the path and could happily continue debugging…

This is a follow-up on a post from 2013(!). There I talked about how we used Fiddler to inject a client certificate to authenticate the request. This application is still in use today, and we still use the same trick to authenticate when debugging locally. Last week, a colleague contacted me that this approach didn't work anymore. When he tried to connect to the service it failed with the following error message: fiddler.network.https> HTTPS handshake to <site> (for #1) failed. System.Security.Authentication.AuthenticationException A call to SSPI failed, see inner exception. We discovered that the root cause of the issue was that the server was expecting a TLS 1.2 connection and we were using a TLS 1.0 connection. We had to take 2 steps to solve the issue: Step 1 – Update Fiddler We first had to update Fiddler. Therefore go to https://www.telerik.com/download/fiddler and download the latest version. Notice that we downloaded Fiddler Classic not the cro

TypeScript provides several utility types that makes working with types easier. Today I want to take a look at the Readonly<T> type. The Readonly<T> type makes all the properties in T become read-only, it does so by annotating each field with the readonly keyword while mapping: It is useful to make an immutable version of a type. Here is an example: If I load this code in the TypeScript playground , I get the following compiler errors: I was hoping that this TypeScript code in someway was transpiled to an Object.Freeze() implementation but this turns out not to be the case. The TypeScript Readonly<T> type provides only static typing immutability(in favor of performance) whereas Object.Freeze() provides runtime immutability. It is however possible to combine the two :  

The GraphQL ecosystem keeps growing. Today I want to bring GraphDoc under your attention. GraphDoc will take your existing GraphQL API and generate instant documentation for it. Go to https://graphdoc.io/ : Enter the URL of your public GraphQL schema: And you get a documentation website back: If you want to change the default configuration, GraphDoc will check for a the existence of .well-known/graphql.json file on the same domain as your GraphQL API. So if your API runs on https://api.example.com/graphql the config will be expected at https://api.example.com/.well-known/graphql.json.

I try to keep the technical debt in my applications under control by keeping the used dependencies up-to-date as much as possible. Everytime I have to make a small change to an application, I reserve some time to update outdated packages. This helps me to avoid big-bang migrations where the risk is high and updating can take a long time. Today I had to make a small update to an application that was using MassTransit. I used the opportunity to upgrade the application from MassTransit v7.1.5 to v7.2.2 . After upgrading the NuGet packages, Visual Studio showed the following errors and warnings: Let’s walk through the steps I took to get rid of them. First I replaced: With: Afterwards I replaced by: There was a namespace change, so I had to add an extra using : Almost there. I also had to replace: by: As a final step I could remove the following line:

A fter requesting access to the GitHub Copilot a few days ago, I got good news today as my request was accepted. Time to give it a try in Visual Studio 2022. Installing the GitHub Copilot extension for Visual Studio GitHub Copilot in Visual Studio is possible thanks to the GitHub Copilot extension available on the Visual Studio Marketplace. Open Visual Studio. In Extensions | Manage Extensions, from the Visual Studio Marketplace, search for ‘Github Copilot’.  Remark: If you cannot find the extension, update your Visual Studio first. Select the extension and click on Download to download and install the GitHub Copilot extension for Visual Studio. Close Visual Studio to start the installation. A VSIX launcher will start and you will be asked to confirm the installation. Click on Modify to continue with the installation process. Use GitHub Copilot for the first time After the installation has completed, we need to activate the

At one of my clients, we use Web Deploy to deploy our ASP.NET Core applications on our on-premise IIS environment. After upgrading an application to .NET 6, the build pipeline failed and the application wasn't deployed. Let’s find out what was causing the problem. A look at the build logs revealed the following error message: Determining projects to restore... D:\b\3\_work\52\s\DocumentStorage\DocumentStorage.API\DocumentStorage.API.csproj : error NU1201: Project DocumentStorage.Domain is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Project DocumentStorage.Domain supports: net6.0 (.NETCoreApp,Version=v6.0) D:\b\3\_work\52\s\DocumentStorage\DocumentStorage.API\DocumentStorage.API.csproj : error NU1201: Project DocumentStorage.Infrastructure is not compatible with net5.0 (.NETCoreApp,Version=v5.0). Project DocumentStorage.Infrastructure supports: net6.0 (.NETCoreApp,Version=v6.0) Failed to restore D:\b\3\_work\52\s\DocumentStorage\DocumentStorage.API\DocumentSto

In one of our applications we encountered an issue due to incompatible package versions. Therefore it was important that we still could update to newer minor versions but don't accidently update to a next major version. The trick to get this done is through version ranges . By default a ‘minimum version’ is used when adding a NuGet dependency: But this is not the only option. Here is the list of possible notations: Notation Applied rule Description 1.0 x ≥ 1.0 Minimum version, inclusive (1.0,) x > 1.0  Minimum version, exclusive [1.0]   x == 1.0 Exact version match (,1.0] x ≤ 1.0   Maximum version, inclusive (,1.0) x < 1.0 Maximum version, exclusive [1.0,2.0] 1.0 ≤ x ≤ 2.0 Exact range, inclusive (1.0,2.0)