The art of simplicity

Although most developers have heard about Domain Driven Design, most applications I encounter today are the traditional ‘layered cake’ with an anemic domain model . I have to admit that even a lot of applications I’ve helped building the last years are still using this approach. Why? 2 reasons; Lack of DDD knowledge in the teams. Most developers ‘know’ the tactical DDD patterns but are not aware of the strategic DDD patterns. What makes it even worse is that even the tactical patterns like the repository pattern are wrongly applied. Getting a team up to speed with DDD takes time, time that we unfortunately not always have in ‘fixed price, fixed time, fixed scope’ projects. Another reason to go for the ‘product not project’ approach. Lack of access to Domain experts.   Good domain modelling can only work if the necessary expertise is around to help you find the correct ubiquitous language, identify bounded contexts and create a shared understanding of the business. T...

This year Microsoft Build will be fully digital. An unique opportunity to get a non-stop, 48-hour interactive experience. It will be more than just an online streaming event. You can help shape the agenda by submitting a specific topic during registration and even get 1:1 expert guidance from the Microsoft engineers! Register here: https://mybuild.microsoft.com/

My first answer on the question in the title would be to use Application Insights . But in case you didn’t configure Application Insights for your AppService, here is an alternative way to gain some insights. To immediately spoil the answer, we will use Project Kudu to look behind the curtains of our Azure App Service. How to find Project Kudu? Go to the Azure Portal Open the App Service Blade for your App Service and click on Advanced Tools. Click on go. Or if you want the quick way, browse to the scm endpoint through .scm.azurewebsites.net/">https://<appservicename>.scm.azurewebsites.net/ Process Explorer Click on the Process Explorer at the top Remark: This is only available when your are running the Windows version of an App Service Now you can see all the processes and even start profiling

Although C# 8 is released for a while, I’m still discovering new features. When I want to conditionally assign a value to a variable whether it is null or not, I typically used either the conditional ternary operator: or a coalesce expression: With C# 8, you can even write this shorter with the null coalescing operator:

One of the neat tricks that you can do in XUnit is to make your test more readible. Here is one of my unit tests: And here is how this looks by default in the Test Explorer: Adding a configuration file Let’s now add a configuration file to improve the default behavior. Add a new JSON file to the root of your test project. Name the file xunit.runner.json . Add a schema reference to get autocomplete behavior while editing the file: Remark: In case of Visual Studio, this is not really necessary as it will recognize the file name and apply the correct schema automatically.  Tell the build system to copy the file into the build output directory. Edit your .csproj file and add the following: <ItemGroup> <Content Include="xunit.runner.json" CopyToOutputDirectory="PreserveNewest" /> </ItemGroup> Update the configuration Let’s now tweak the behavior by changing some settings in...

While doing a code review of an Azure Function I noticed the following line: var personalAccessToken = Environment.GetEnvironmentVariable("KeyVault_PersonalAccessToken", EnvironmentVariableTarget.Process); Could it be that the developer directly stored a secret in an environment variable? Instead of using a secure storage like Azure Keyvault? Inside the configuration on the Azure Portal I found the following: @Microsoft.KeyVault(SecretUri=https://sample-vault.vault.azure.net/secrets/personal-access-token/<removedthekey>) Luckily my assumption was wrong and it turns out that is a feature I wasn’t aware of in Azure (Functions). To use this feature you first have to create a Managed Service Identity for your Azure Functions app as described here: https://docs.microsoft.com/en-us/azure/app-service/overview-managed-identity?tabs=dotnet#creating-an-app-with-an-identity Once you have a Managed Service Identity you can add an Access policy in your Azure Ke...

To be able to test my application I had to create a ‘dummy’ ClaimsPrincipal and ClaimsIdentity: However when I tried to run my test, the test failed because the ClaimsIdentity returned ‘false’ for the IsAuthenticated check. To create an authenticated ‘dummy’ identity I had to pass on an extra ‘authenticationType’ parameter to the constructor: The exact value that you specify doesn't matter.