The art of simplicity

After reading the blog post of Scott Hanselman about the container tools in Visual Studio, I was eager to try this out. But I couldn’t find the containers window at the location mentioned in the post: View Menu –> Other Windows –> Containers Turns out that is a rather new feature that requires Visual Studio 2019 version 16.4 (or higher). After installing the update the menu item should appear: Now you can start viewing containers, browsing available images, check logs and port mappings, launch a terminal window, … and so on, all directly from within Visual Studio. Nice!

While creating a new Azure DevOps Server project, I accidently created a Project Wiki. Unfortunately there is no option yet to delete this wiki. The trick is to use the REST api to delete the GIT repo that is used behind the scenes: First get the correct wiki git id through the following call: GET http://tfs:8080/tfs/defaultcollection/_apis/wiki/wikis?api-version=4.1 This will return all the wikis. From that we can get the repository Id of the particular wiki we need to delete. Now we can use another API to delete the correct git repo: DELETE http://tfs:8080/tfs/defaultcollection/_apis/git/repositories/{repositoryId}?api-version=4.1   That’s it! Remark: To be able to call this through a tool like POSTMAN, you need to create a PAT and include it in the Authorization header(Postman will do the base64 encoding for you) or use the NTLM support in POSTMAN. Authorization: Basic PAT

Visual Studio 2017 and .NET Core introduced the new csproj format where your NuGet packages are no longer referenced through a Packages.config file but are added to your csproj file: If you want to create a NuGet package from your project, you no longer need a separate configuration file but your csproj file can contain all the information about your NuGet package. It will automatically include all PackageReferences that you are using, so gone is all the copy/paste work. But what if you have a dependency that is purely used during development and that you don’t want to expose to projects that will consume your package? In this scenario, you can use the PrivateAssets metadata to control this behavior. There are multiple possible values that you can find in the documentation: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#controlling-dependency-assets

Almost every (web) application built today is using one or more open-source components. But are you sure that none of the packages that you are using has vulnerabilities? NPM already helps you by running an NPM audit when you install new packages, but wouldn’t it be nice to go one step further and have everything nicely integrated into your build pipeline? Enter WhiteSource Bolt for Azure DevOps . It is a FREE extension, which scans all your projects and detects open source components, their license and known vulnerabilities. It supports the most common programming languages and does continuous tracking of multiple open source vulnerabilities databases like the NVD, security advisories, peer-reviewed vulnerability databases, and popular open source projects issue trackers. The only limitation in the free version is that you can scan any project up to 5 times a day. To install it go to the Azure DevOps Marketplace and click on the ‘Get it free’ button (or go to the Marketp...

A lot of applications even today are build using the layered architecture pattern. Inside a layered architecture, an application is organized into a set of horizontal layers where each layer performs a specific role. A typical example is a 4 layer architecture with presentation, business, persistence and database layer: In a layered architecture each layer has its own responsibilities which allows you to have a clean separation of concerns.  Each layer can only talk to the layer directly below it(see the direction of the arrows). As a consequence your presentation layer cannot directly talk to the database layer directly but have to pass through all layers to finally reach the database. By default all layers are closed . A closed layer means that as a request moves from layer to layer, it MUST go through the layer right below it to get to the layer below that one. What some people seem to forget is that inside a layered architecture it is also possible to mark layers as...

While investigating an issue in one of our (older) applications I was wondering about the exact steps taken to handle a specific request. So far I’ve always used the following poster : But thanks to Matthew Jones it even became easier. He walks through every step in much more detail so that you know exactly what is going on. Thanks Matthew! https://exceptionnotfound.net/the-asp-net-web-api-2-http-message-lifecycle-in-43-easy-steps-2/

While reviewing some code I noticed that a project was using both Moq and NSubstitute. It seemed strange to me to use 2 mocking libraries in the same codebase. Turned out that there was a problem when trying to combine IHttpClientFactory and NSubstitute. The reason is that the IHttpClientFactory returns a concrete type (HttpClient) and that NSubstitute cannot mock its methods (like SendAsync()). The trick was to create your own HttpMessageHandler instead: The mocking code became the following: