Use Directory.Packages.props to Centralize Version Management of Consumed NuGet Packages in a .NET Solution

 Using NueGet packages and keep the versions upto date is a requirement as well as a challange if the versions are defined all over in many projects, in a given dotnet solution. We can limit the reference to packages to refer only in one project for a solution as consuming projects will inherently get the references. However, when it comes to using unit test projects we must reference the packages in all test projects to ensure test dicoverability in pipelines as well as in Test Explorer of the Visual Studio. Therefore, centralize Nuget Package management is essential in a complex and large solutions.

The Directory.Packages.props is the saviour for this requirement which allows us to define all the package versions centrally in the solution, by adding a Directory.Packages.props to the root of the repo, similar to using nuget.config.

Expose AKS Deployed RabbitMQ AMQP Access for Local Development via Load Balancer

 We have discussed "Setting Up RabbitMQ Cluster in AKS Using RabbitMQ Cluster Operator" in a previous post. Within the AKS cluster apps can access RabbitMQ with AMQP with rabbitmq-cluster.rabbitmq.svc.cluster.local using cluster IP service. However it is important to expose the rabbitmq cluster for local development. For this purpose we have to setup a load banacer service as Rabbit MQ AMQP protocol is not supported via Nginx. Let's look at how to setup a load balancer service to enable local development of applications using a RabbitMQ cluster deployed in an AKS cluster in this post.

Linux AKS Scaled Jobs Handle Graceful Termination for dotnet App using IHostedService

 We have discussed "Windows AKS Scaled Jobs Handle Graceful Termination for dotnet App using IHostedService When Preemption" previously. However,  for Linux scaled jobs we have to handle the graceful termination, using a bash script intead of a PowerShell script.

We can create a script with bash as shown below.

Windows AKS Scaled Jobs Handle Graceful Termination for dotnet App using IHostedService When Preemption

 We have discussed "Gracefully Shut Down dotnet 8 IHostedService App - Deployed as a Windows Container in AKS - While Scale In or Pod Deallocations" previously. The approach  works fine for pods deployed as a deployment in kubernetes. Similary to the deployment pods, scaled job pod can be terminated abruptly due to preemption in kubernetes, if a high priority pod is scheduled. One way to reolve abrupt termination of scaled job pod due to preemption, would be to assign all scaled jobs to highest possible priority. However, setting highest prority to all scaled jobs is not a good solution, as the job may not require highest priority and job should be able to scheduled after other high priority app pods. Let's look at a better solution that can be implented with pre stop hook for scaled jobs running with base docker image Windows server core 2022.

Windows Nanoserver Image Pre Stop Hook to Avoid 502 for Requests

The pods deployed to AKS gets terminated due to reschduling, low priority evictions as well as during scaled in. We can add a termination grase period and pre stop sleep time as shown below in Linux and Windows containers to allow, sufficient time to ingress services to get updated about terminating pods. However, Windows nanoserver does not support PowerShell. Therefore, we need to use a specific mechanism to pre stop hook for nanoserver images. For nanoserver images shutdown signal is correctly get sent to the dotnet app. So we can just setup a sllep time for pre stop hook as necessary.

Gracefully Shut Down dotnet 8 IHostedService App - Deployed as a Windows Container in AKS - While Scale In or Pod Deallocations

 Applications implemented with IHostedService in dotnet, deployed to Azure Kubernetes Services (AKS) as containers in pods get terminated when pod recheduling happens or scaling-in opertaions happen. However, unlike Linux containers, the Windows containers does not receive the signal (similar to SIGTERM or SIGINT) to graceful shutdown. Once the pre stop hook is done the container is immediatly killed disregarding the value set in the terminationgraceperiod. Since, the Windows container did not receive a message to start a graceful shut down, and it is killed abruptly, the in flight operations in the Windows app container are abandoned. Such abadoning of operations cause inconsitency in system data and cause system failures. Therefore, it is mandatory to implement a proper graceful shutdown for Windows containers as well. Let's explore the issue in detail and how to implement a proper solution to enable graceful Windows container shut down, for dotent apps implemented with IHostedService. The issue is happening in mcr.microsoft.com/dotnet/runtime:8.0-windowsservercore-ltsc2022 images and the solution is tested with the same.

Windows app pod scaled-in or pod rescedule 

Copy Blob Between Azure Storage Accounts with C# Using DefaultAzureCredential

 Copying a blob between Azure storage account without downloading the blob locally is realy simple with azcopy command. Now using Azure.Storage.Blobs we can copy blobs between Azure sotrages without downloading the blob locally, with C# code as well. Using DefaultAzureCredential for the copy operation is useful, when we use apps with managed identities, such as workload identity in AKS. Let's explore steps necessary to copy a blob from one storage account to another with C# console app.

How it works

When the example simple console app is executed it copies blob from sourse storage account to target storage account as shown below.

Azure File Share with DefaultAzureCredential in .NET with Azure.Storage.Files.Shares - Is it possible?

 Using DefaultAzureCredential with most of the Azure resources is straight forward and simple with most of the Azure resources with relevant Azure .NET SDKs (We can use nuget packages Azure.Storage.Blobs and Azure.Identity). For example, with storage blob we can easily use DefaultAzureCredential as shown in below code.

    private static BlobServiceClient GetBlobServiceClient(string accountName)

    {

        return new(new Uri($"https://{accountName}.blob.core.windows.net"),

            new DefaultAzureCredential());

    }

However, we cannot simply create ShareClient with .NET SDK Azure.Storage.Files.Shares to use DefaultAzureCredential . as shown below.

ShareClient share = new(new Uri(fileShareUri),

    new DefaultAzureCredential());

With the above setup, we will get runtime errors when we try to perform operations with the Azure file share. As per the GitHub issue here it is not possible to use DefaultAzureCredential with Azure File Share with .NET SDK Azure.Storage.Files.Shares  due to "SMB Files cannot authenticate with a TokenCredential". So is it impossible to use DefaultAzureCredential  to perform operations with an Azure File Share using Azure.Storage.Files.Shares ? Let's look at a wokaround, which can help if desperately need to use DefaultAzureCredential with Azure.Storage.Files.Shares .

Installing .NET 8 Runtime on Ubuntu 22.04 Docker Image

 .NET 8 was release on November 14. There are docker container images for .NET 8 available for dotnet runtime and can be found with tag list here https://mcr.microsoft.com/v2/dotnet/runtime/tags/list . However, if you want to setup .NET 8 runtime on another specific Linux docker image for example on ubuntu:jammy , amd64/ubuntu:22.04 or with a special image such as ffmpeg Linux server image linuxserver/ffmpeg:amd64-version-6.0-cli, where you might want to run your .NET app to use ffmpeg, In such cases, where you you might have to setup .NET 8 runtime on a specific docker image, with your other tools readily available, details mentioned may come in handy.   Lets, see how we can install .NET 8 runtime on base Ubuntu 22.04 images, using a docker file.

Installing .NET 8.0 SDK on WSL

 WSL (Windows subsystem for Linux) is a great way to work with Linux on Windows. .NET 8 is released on November 14th, and let's see how we can get .NET 8 SDK setup on WSL to build and test our .NET 8 apps on Linux on a windows machine.

What we want is when we do a dotnet --list-sdks to see the .NET 8 available in WSL. 

Avoid GitHub Action Workflow Code Duplication - Using Composite Actions to Create Reusable Templates

 Azure DevOps yaml files for piplines can be created as templates to avoid duplicating same set of tasks in multiple areas of the pipelines. For GitHub actions workflow, we have seen here in "Build and Unit Tests for .NET Apps with GitHub Actions" the same steps are repeated in both Windows and Linux, build and unit test run. The solution to avoid duplicating same steps in multiple jobs in a GitHub actions workflow is the usage of composite actions. Let's modify our workflow implemented in "Build and Unit Tests for .NET Apps with GitHub Actions" to use composite action to build and unit test, and reuse that in both Windows and Linux job.

Build and Unit Tests for .NET Apps with GitHub Actions

 Executing unit tests and viewing results in unit tests in a build pipeline is essential to keep high quality in an application deployment via any pipeline system. GitHub actions are the way forward to implement pipelines with repositories in GitHub. Let's explore how to run unit tests and view results in GitHub actions workflow.

Docker Alpine (mcr.microsoft.com/dotnet/runtime) - Resolve "Microsoft.WindowsAzure.Storage.StorageException: Only the invariant culture is supported in globalization-invariant mode."

.NET app running with mcr.microsoft.com/dotnet/runtime docker alpine images, might run into issue "Microsoft.WindowsAzure.Storage.StorageException: Only the invariant culture is supported in globalization-invariant mode" if your app is requiring globalization. Let's look at what needs to be done to get the issue fixed.

Resolve Windows Docker Build "C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG))"

 Building .NET 6 project with Resource files is running into build issue as shown below, when building with .NET 6 nanoserver build images.

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: The "GenerateResource" task failed unexpectedly. [C:\src\Demo\Demo.csproj]

C:\Program Files\dotnet\sdk\6.0.407\Microsoft.Common.CurrentVersion.targets(3262,5): error MSB4018: System.Runtime.InteropServices.COMException (0x80040154): Retrieving the COM class factory for component with CLSID {7Bxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx} failed due to the following error: 80040154 Class not registered (0x80040154 (REGDB_E_CLASSNOTREG)). [C:\src\Demo\Demo.csproj]

Writing a json Easily and Elegently in in C# 11

 In the previous post "No More " Escaping Needed with C# 11" we have discussed, how the json can be writen in C# code, without having to escape each occurance of double quote, when we use the new C# 11 feature Raw String Literals. You might not want to hardcode the entire json in code, instead may want to use variables dynamically setting the json body content. Let's see how we can use String interpolation, in Raw String Leiterals to write json body elegently, and have variables dynamically set values in the josn.

Resolving “Response status code does not indicate success: 400 (Bad Request)” in NuGet Packages Push to GitHub Packages with GitHub Actions

GitHub packages registry can be use to keep your organization NuGet packages privately or share them publicly. If you create a package in a private repo it would be private to the repo or for the organization if you use an organization. If you keep your packages in a public repo you can share it publicly. Ideally when you build reusable NuGet packages you would build and publish such packages with GitHub action workflow to your GitHub packages. While implementing this you may encounter “Response status code does not indicate success: 400 (Bad Request)” at the push of the package, due to special needs of GitHub based NuGet packages. Let’s look at them in this post.

Resolve the “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”

.NET 5 is released recently and you can use entity framework core 5 with your projects by setting up the version 5.0.0 of the packages, Microsoft.EntityFrameworkCore, Microsoft.EntityFrameworkCore.Design, Microsoft.EntityFrameworkCore.SqlServer, Microsoft.EntityFrameworkCore.Tools if you are using SQL server as the database. However, when you execute dotnet ef commands in the package manager console in Visual Studio you might see the message “Entity Framework tools version '3.1.9' is older than that of the runtime '5.0.0' in Visual Studio Package Manager”. Let’s see how we can get it fixed.

Resolving “System.IO.IOException: The response ended prematurely.” in HttpClient Request

Some times a silly mistake can waste lot of time of a developer. The exception “System.IO.IOException: The response ended prematurely.” while making an http client request to call an API from another web app has wasted considerable amount of my time diagnosing the issue. Therefore, thought worth sharing the experience.

Resolving Azure DevOps Build Error “data at the root level is invalid” in dotnet test

When you try to execute dotnet test with test assemblies in Azure DevOps builds built with Visual Studio 2019 you may run into an error “data at the root level is invalid”. Let’s look at how to solve this issue and get the tests executed in the Azure DevOps build pipelines.