The art of simplicity

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII -  API integration Part XIV – Bring your own API Part XV – Pass authentication info to your linked API If you have read my post yesterday, you know that you can link an existing API exposed through Azure API Management, an Azure App Service or Azure Container Apps to your Azure Static Web App. When using th

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII -  API integration Part XIV(this post) – Bring your own API In the last post in this series, I explained that with every Static Web App you get a serverless API endpoint (based on Azure Functions) for free. However you have also the option to bring your own API. This can be an Azure Function but also an API expos

After using other DI containers like Microsoft Unity, StructureMap and Autofac, I'm now using the built-in Microsoft.Extensions.DependencyInjection DI container most of the time.  The default DI container lacks some more advanced features that these other containers have, but for most use cases it is sufficient. Most of the time when registering a type as a service, you want to register it with the interface it implements: To simplify this I created an extension method AsImplementedInterfaces that register a type with all its interfaces: To use this method, you call any of the Add methods on the IServiceProvider and call the AsImplementedInterfaces method afterwards: Feel free to use it in your own projects... Remark: If you are looking for some other convenience methods that can help you when using the default DI container, check out Scrutor .

After using other DI containers like Microsoft Unity, StructureMap and Autofac, I'm now using the built-in Microsoft.Extensions.DependencyInjection DI container most of the time.  The default DI container lacks some more advanced features that these other containers have, but for most use cases it is sufficient. This week I was looking at a way to check if a specific service was registered in the DI container without resolving and constructing the service instance. Turns out that this feature was introduced in .NET 6 through the IServiceProviderIsService interface (what’s in a name). This interface provides a single method that you can invoke to check whether a given service type is registered in the DI container. To use it, you can resolve the IServiceProviderIsService service itself from the container and call the IsService method: Nice!

When adding NuGet packages to your .NET projects, it's important to understand the difference between direct dependencies and transitive dependencies . Direct dependencies are the packages that are added directly as a package reference to your project file. For example in this Azure Function project, you see one direct dependency: So knowing and managing your direct dependencies is quite easy. But this package has also dependencies that are not directly added to your project. These are the transitive dependencies. To prevent supply-chain attacks, it is important to have a good understanding of the full dependency treed and know all packages that are used directly or indirectly in our projects. Visual Studio helps you to see and manage these transitive dependencies by making them visible in the NuGet Package Manager: You can hover over any transitive dependency to understand the top-level dependencies that brought it into your project: And you can always promote a tran

As a follow-up on the presentation I did at CloudBrew about Azure Static Web Apps I want to write a series of blog posts. Part I - Using the VS Code Extension Part II - Using the Astro Static Site Generator Part III  – Deploying to multiple environments Part IV – Password protect your environments Part V – Traffic splitting Part VI – Authentication using pre-configured providers Part VII – Application configuration using staticwebapp.config.json Part VIII – API Configuration Part IX – Injecting snippets Part X – Custom authentication Part XI – Authorization Part XII -  Assign roles through an Azure function Part XIII(this post) -  API integration So far I’ve mostly talked about the Static content part of Azure Static Web Apps but I only briefly touched the API integration when talking about configuration . With every Static Web App you get a serverless API endpoint (based on Azure Functions) for free. When using this Managed Fu

A trap I easily fall in to as an architect is that I can be become quite enthusiastic about a specific technology. If you are a long time reader of my blog, you certainly have seen me write about specific tools, techniques and products over the years. Unfortunately this enthusiasm got me into trouble a few times as an architect. Because I have an important stake into a project and some influential power it happened that I started spreading this enthusiasm and influenced the team to join my enthusiasm. Sorry team! But this means that I was no longer doing my job as an architect. Instead of seeing the trade-offs ; I fell in love with the good parts and turned blind for the bad parts. Although I know better and that I should  be wary of any tool or technique that promises to make everything better, I couldn’t resist. It's a trap that many architects fall into: becoming so enamored with the positive aspects of a technology that they overlook its shortcomings. In doing so, we negl

Just before the start of my weekend, I got a message from one of our administrators, the disk space on one of our build servers was filling up. Whoops! Yesterday I explained that a part of the disk consumption could be explained by the global packages folder of NuGet. But if you take a second look at the screenshot I shared, you certainly notice that the AppData folder also needs some attention: Let’s further drill into this folder and well’ notice another culprit; the npm-cache folder! What is the npm-cache folder? The npm-cache folder serves as a local cache where NPM stores downloaded packages and their dependencies. When you install a package using NPM, it first checks if the package is already in the cache. If so, it avoids re-downloading it, which speeds up subsequent installations. This cache helps reduce network requests and ensures that packages are readily available for future use. On Windows , the default path for the NPM cache is %AppData%/npm-cache or %Local

Just before the start of my weekend, I got a message from one of our administrators, the disk space on one of our build servers was filling up. Whoops! A took a look at the server and noticed that a lot of the disk space was eaten up by the .nuget folder: What is this .nuget folder? The .nuget folder is the default global packages folder. It is the location where NuGet installs any downloaded package. In the first NuGet versions packages were installed as part of the solution tree where the packages were used. But since a long time, this got replaced by the global packages folder avoiding having package copies found everywhere on your local file system. The default location is: Windows: %userprofile%\.nuget\packages Mac/Linux: ~/.nuget/packages How to change the global packages location? The easiest way to change this location is by setting the NUGET_PACKAGES environment variable to a different path: $Env:NUGET_PACKAGES = "d:\.nuget\packages" More

If you are new to JavaScript or want to refresh you knowledge with the latest and greatest that is inside the language, I can only recommend to spend some time with the 4th edition of Marijn Haverbeke's book; Eloquent JavaScript . I’ve read it during the weekend and I have to admit that it revived my interest(love?) in the language.  After spending most of my time using C# and TypeScript it is great to see how far we can get with modern JavaScript. The book is well written with a lot of examples, handling both basic and more advanced feature of the language. It includes some (small) projects that are fun to build and try and allow you to apply the knowledge you’ve acquired. So if you want to learn how to write ‘modern’ JavaScript, this is a must read!

With big traffic jams everywhere, I try to use public transport as much as possible for my daily commute. This allows me to work already before I arrive at the office. As connectivity is not that great during travel, I tend to work offline. Most of the time this works great, but I get into trouble the moment I need to add or update a NuGet package to a project in Visual Studio. Visual Studio starts to complain when connectivity is lost and I want to add a NuGet Package: Of course, this is not related to Visual Studio directly, if I try do this from the command line, I also get errors: The stupid thing is that I do have the package available offline. If you go to %userprofile%\.nuget\packages, you’ll find a local copy of every package you have installed in your projects: Instead of failing back to the cache when the package source is not accessible, it just fails. Local feeds What you can do, is setup a local feed. This will use a simple hierarchical folder structure on you

I was reading the following blog post when I thought: "How good (or bad) would Github Copilot handle the scenario's mentioned in the post?" This post is the answer on this question.  But before we dive in, I would suggest to first read the original post on the JetBrains blog: Critical Thinking in an AI-Powered World | The .NET Tools Blog (jetbrains.com) . Back? Let’s get started! I already created an XUnit Test project targeting .NET 8 and pasted the first snippet used in the post in a test class: Now let’s ask the same question but not to the JetBrains AI assistant but to Github Copilot in Visual Studio: Suggest a way to refactor the variable `now` so that I can control the value without depending on `DateTime.UtcNow` Here is the response I got: Similar to the JetBrains AI Assistant it suggests me to create my own abstraction and create an IDateTimeProvider interface. Too bad! Let us also mention the TimeProvider class and see if we get a better result

In the world of software development, the role of the architect often looms large. Yet, what if I told you that architecture is not just the domain of a select few, but rather the responsibility of every member on the team? Let's delve into why this shift in perspective is crucial for the success of your projects. Gone are the days when software architecture was solely the concern of a designated architect. In today's landscape, it's imperative that every team member, from developers to testers, possesses a solid understanding of the architectural principles guiding their work. As an architect, your primary aim should be to ensure that everyone comprehends the architecture as thoroughly as you do. Each member should be equipped to answer the fundamental "why" questions about the architecture, breaking down barriers that often lead to miscommunication and inefficiency. Too often, we see organizations where the architect stands as the solitary guardian of th

By default when a message consumer in MassTransit throws an exception, the exception is caught by middleware in the transport (the ErrorTransportFilter to be exact), and the message is moved to an _error queue (prefixed by the receive endpoint queue name). The exception details are stored as headers with the message for analysis and to assist in troubleshooting the exception. Next to moving the message to an error, MassTransit also produces a Fault<T> event. If the message headers specify a FaultAddress , the fault is sent directly to that address. If the FaultAddress is not present, but a ResponseAddress is specified, the fault is sent to the response address. Otherwise, the fault is published, giving you the option to consume these fault messages if you want to: However this can lead to a lot of extra exchanges that could be created.  If you don’t want to publish a Fault event, you can do this by setting the PublishFaults property to false in your MassTransit confi

While working on some class library code in C#, I noticed deprecation warnings in Visual Studio for the following NuGet packages: NuGet Gallery | Microsoft.AspNetCore.Http.Abstractions 2.2.0 NuGet Gallery | Microsoft.AspNetCore.Authentication.Abstractions 2.2.0 A look at the NuGet website confirmed this: But what now? It looked like that no alternative was mentioned anywhere… I first tried to just remove these 2 packages but now my library no longer compiled!? In the end I was able to solve it by adding a framework reference to Microsoft.AspNetCore.app inside the csproj file of my class library:

In my continuous journey to design and write better code I try and experiment with multiple testing techniques. A while ago I wrote a whole series of blog posts about Property based testing, an addition to the traditional example-based testing. A property based test is meant to be fairly succinct and verify that simple properties hold true for all possible inputs given a set of preconditions. Libraries like FSCheck and CSCheck by randomizing the inputs for a particular operation. But what if we need to test a more complicated scenario where it is not so easy to identify the separate properties of our system? This is where model based testing can help us. Instead of randomizing the input for one operation, we execute an arbitrary combination of operations against our system and compare it to a simplified model. Let me show you how to do this using CsCheck . I have created a small Counter with two operations: Increase() and Decrease(): We now define a “simplified” model ba

Yesterday I talked about Bombardier, an HTTP benchmarking tool written in Go and how you can use it to test the performance of your ASP.NET Core applications. While discussing the usage, a colleague mentioned another load testing tool, NBomber . NBomber is a load-testing framework for Pull and Push scenarios, designed to test any system regardless of a protocol (HTTP/WebSockets/AMQP, etc) or a semantic model (Pull/Push). It goes a lot further than what Bombardier has to offer. One of the things I find nice is that load test scenario’s can be written using C#. 😉 Remark: NBomber comes with a free personal license, if you want to use it inside your organization, you’ll have to buy a business license. Let’s write a simple load test to test our API! We start by creating a new Console application and adding the NBomber nuget package: dotnet add package NBomber As we want to test an HTTP endpoint, let’s also add the NBomber.Http plugin to simplify defining and

In the past I’ve always used Apache Bench , Fiddler or Visual Studio Load Testing to test the performance of my ASP.NET (Core) applications and API's. Recently I made the switch to Bombardier , a versatile HTTP benchmarking tool written in Go.   If you have Go Go installed on your system, you can install Bombardier using the following command: go get -u github.com/codesenberg/bombardier But you can also download a binary compatible to your OS directly from the releases without the need to install Go. I already started my ASP.NET Core application: Running the tool is quite easy. Invoke the bombardier command with the target URL and some extra parameters: bombardier -c 100 -n 1000 –l http://localhost:5042/WeatherForecast This command will send 1000 requests with 100 concurrent connections to your application. Bombardier will provide detailed statistics: Reqs/sec : Requests per second. Latency : Average response time. Latency Distribution : Percentiles (