Notes

Wednesday, January 5, 2022

Migration to .Net 6.0

The one blocker we have is that .Net 6.0 is not installed Ubuntu based Microsoft-hosted agents in Azure DevOps. See this GitHub issue discussion: https://github.com/actions/virtual-environments/issues/4424

The workaround is to add a task in the YAM: pipeline to install the desired .Net SDK version:

- task: UseDotNet@2
  inputs:
    packageType: 'sdk'
    version: '6.0.x'

I thought the SDK installation would lengthen the build time significantly but it adds only 7 seconds to the build.

The overall build time seems to have decreased dramatically (at least 50% decrease)


Breaking change: Default console logger format set to JSON when running in Docker container using the aspnet image. https://github.com/dotnet/dotnet-docker/issues/3274

This change only affects applications running in a Docker container, for instance when running in Kubernetes. I don’t think this is a big deal for us and we should embrace the new default.


Migration guide from .NET 3.1 to 6.0

https://docs.microsoft.com/en-us/aspnet/core/migration/31-to-60?view=aspnetcore-6.0&tabs=visual-studio

Command to clear Nuget package cache:

$ dotnet nuget locals --clear all

Now I’m having a build error due to the migration of ServiceCollection from Microsoft.Extensions.DependencyInjection to the Microsoft.Extensions.DependencyInjection.Abstrations Nuget package. See: https://github.com/dotnet/runtime/pull/52284

The same issue is reported here: https://github.com/grpc/grpc-dotnet/issues/1481 The workaround is to add an explicit Package Reference to Microsoft.Extensions.DependencyInjection v6.0.0 in the .csproj.

  <ItemGroup>
    <PackageReference Include="Microsoft.Extensions.DependencyInjection" Version="6.0.0" />
  </ItemGroup>

Possible code improvements:


Some date and time improvements were introduced in .Net 6.0: https://devblogs.microsoft.com/dotnet/date-time-and-time-zone-enhancements-in-net-6/

One of the most interesting improvement is the automatic conversion between Windows time zones and IANA timezones (e.g. “Eastern Standard Time” <-> “America/Toronto”). This was a minor pain point when working with both Windows and Linux.

DateOnly and TimeOnly structs could be useful as well.