Dapr and .NET 5

Describe the proposal

Compatibility with .NET 5 came up today in the Dapr community call. This issue is a proposal for what the dotnet-sdk needs do about the pending .NET 5 release and a blueprint for how we think about new .NET releases in the future.

FAQ

What is .NET 5?

.NET 5 is the next release of .NET

You can read more about the implications of why it’s called .NET 5 rather than .NET Core 5 here

In technical terms, you can think of .NET 5 as the next release of .NET Core (following 3.1).

When will .NET 5 be released?

You can read about the .NET roadmap and support lifecycle here.

.NET 5 is on track to be released at GA quality in November 2020. RC releases are available now.

Is .NET 5 an LTS release?

You can read about the .NET roadmap and support lifecycle here.

.NET 5 is a current (non-LTS) release. current releases have a shorter support lifecycle compared to LTS releases. Most users will want to use LTS releases and update on the slow path (~2-3 years) - using current releases is the fast path (~1 year).

Does Dapr work on .NET 5?

We have not done any validation with .NET 5 yet. We expect .NET 5 to be highly compatible, and expect that it already works well with Dapr.

We’re aware of one issue: https://github.com/dapr/dotnet-sdk/issues/414

Proposal

Support Matrix

The proposal is that Dapr dotnet-sdk should remain compatible with, and provide support for all supported versions of .NET (beginning with .NET Core 3.1).

Example: .NET Core 3.1 is supported until December 2022 - the Dapr dotnet-sdk should support .NET Core 3.1 until at Dec 2022

Example: .NET 5 will be released in Nov 2020 and supported until at least Nov 2021 - the Dapr dotnet-sdk should support .NET 5 during the same period - after .NET 5 is end-of-life it’s likely that the dotnet-sdk will remain compatible, but support is per the discretion of maintainers - there is no guarantee that the project will accept bug fixes or answer questions related to an unsupported release

Rationale: Unsupported .NET releases no longer receive security patches. Any user running an unsupported .NET release in production cannot have confidence that they are secure. Aligning the Dapr dotnet-sdk support lifecycle with the official .NET plans means that Dapr dotnet-sdk is compatible with all versions that receiving security updates.

Pre-release versions

We appreciate and benefit from users running Dapr with pre-release builds of .NET for validation.

The proposal is that support of pre-release versions of .NET and Dapr is best-effort and at the discretion of maintainers. Concretely what this means is that the maintainers may choose to deprioritize addressing feedback based on a pre-release.

Example: Suppose a pre-release of .NET introduces a bug and is incompatible with the dotnet-sdk. There’s no expectation that the Dapr dotnet-sdk will make code changes to work around the problem.

Testing

The proposal is that the Dapr dotnet-sdk will test will all supported versions of .NET (starting with .NET Core 3.1) and any releases in RC status. The unit tests and integration tests will multi-target to run on all targeted versions of .NET.

Validation passes that are done manually should include all supported versions of .NET. Compatibility issues between .NET runtime versions are far more likely to be found with app building or integration tests than unit tests.

Rationale: We need to strike a balance between our ability to test and the requirements for contributors. Once a new version of .NET enters the support matrix it raises the minimum version of the .NET SDK required to build the repository. Requiring a pre-release of the .NET SDK only when it’s close to release gives the best tradeoff for everyone.

RELEASE NOTE: ADDED validation for .Net 5.

[wmeints]

Agreed, .NET Core 3.1 is LTS and should definitely work. I’ve been using that version at clients everywhere. .NET 5 and 6 are using the new API interface. So I figure we can slowly move towards that interface to be sure it works for 6 when it becomes the new LTS version.

I can create a pull request to make the Dapr .NET SDK work for .NET 5 and Core 3.1 if you like.

[rynowak]

@wmeints - this likely need to change as part of: https://github.com/dapr/dotnet-sdk/issues/434 - the rough plan is to make all of the actors configuration to Startup.cs

The challenge with IHostBuilder is that you don’t want to end up with two web pipelines registered. IHostBuilder shows up in scenarios where you aren’t using HTTP at all (workers). Actors is coupled to the idea of an HTTP serving pipeline (even though it tries to hide it).

Fortunately in a web project both are actually there - we should probably update our samples and docs for now.

public static IHostBuilder CreateHostBuilder(string[] args) =>
            Host.CreateDefaultBuilder(args)
                .ConfigureWebHostDefaults(webBuilder => // this is IWebHostBuilder
                {
                    webBuilder.UseStartup<Startup>();
                    webBuilder.UseActors(options =>
                    {

                    });
                });