RuntimeFrameworkVersion seems to be ignored

[stefanloerwald]

Description

I am trying to work around #53990, where a regression in .net runtime 5.0.7 is causing fatal exceptions on interop. I added <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion> to my csproj file, but printing System.Environment.Version still results in 5.0.7.

Steps for reproducing this

1. dotnet new console
2. Modify Program.cs to print out Console.WriteLine(Environment.Version);
3. dotnet build
4. dotnet run
5. Verify output is 5.0.7
6. Modify project.csproj to include <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion> in a PropertyGroup, as described in https://docs.microsoft.com/en-us/dotnet/core/versions/selection
7. dotnet clean
8. dotnet build
9. dotnet run
10. Notice output is still 5.0.7
11. dotnet publish
12. cd bin/Debug/net5.0/publish
13. Verify that runtimeOptions.framework.version in the project.runtimeconfig.json file reads 5.0.6
14. Run project.exe or dotnet project.dll
15. Notice that output is 5.0.7.

What's going on here? Why is RuntimeFrameworkVersion ignored in all these cases?

My concrete use case is a dotnet tool, so my csproj structure is

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>myToolName</ToolCommandName>
    <PackageId>myToolName</PackageId>
    <Version>1.2.3</Version>
    <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion>
  </PropertyGroup>
</Project>

I deploy my tool as a nuget package, so my deployment steps are

dotnet build project.csproj -c Release
dotnet pack project.csproj .c Release -o tmp
dotnet tool update -g --add-source=tmp myToolName

I see that when I publish my application using dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true, then running the application prints 5.0.6 as expected, but that doesn't seem like a feasible solution for deployment as dotnet tool.

Other information

> dotnet --list-sdks
2.1.816 [C:\Program Files\dotnet\sdk]
3.1.410 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.201 [C:\Program Files\dotnet\sdk]
5.0.204 [C:\Program Files\dotnet\sdk]
5.0.301 [C:\Program Files\dotnet\sdk]

> dotnet --list-runtimes
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

[ghost]

Tagging subscribers to this area: @vitek-karas, @agocke, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Description

I am trying to work around #53990, where a regression in .net runtime 5.0.7 is causing fatal exceptions on interop. I added <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion> to my csproj file, but printing System.Environment.Version still results in 5.0.7.

Steps for reproducing this

1. dotnet new console
2. Modify Program.cs to print out Console.WriteLine(Environment.Version);
3. dotnet build
4. dotnet run
5. Verify output is 5.0.7
6. Modify project.csproj to include <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion> in a PropertyGroup, as described in https://docs.microsoft.com/en-us/dotnet/core/versions/selection
7. dotnet clean
8. dotnet build
9. dotnet run
10. Notice output is still 5.0.7
11. dotnet publish
12. cd bin/Debug/net5.0/publish
13. Verify that runtimeOptions.framework.version in the project.runtimeconfig.json file reads 5.0.6
14. Run project.exe or dotnet project.dll
15. Notice that output is 5.0.7.

What's going on here? Why is RuntimeFrameworkVersion ignored in all these cases?

My concrete use case is a dotnet tool, so my csproj structure is

<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>net5.0</TargetFramework>
    <PackAsTool>true</PackAsTool>
    <ToolCommandName>myToolName</ToolCommandName>
    <PackageId>myToolName</PackageId>
    <Version>1.2.3</Version>
    <RuntimeFrameworkVersion>5.0.6</RuntimeFrameworkVersion>
  </PropertyGroup>
</Project>

I deploy my tool as a nuget package, so my deployment steps are

dotnet build project.csproj -c Release
dotnet pack project.csproj .c Release -o tmp
dotnet tool update -g --add-source=tmp myToolName

I see that when I publish my application using dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true, then running the application prints 5.0.6 as expected, but that doesn't seem like a feasible solution for deployment as dotnet tool.

Other information

> dotnet --list-sdks
2.1.816 [C:\Program Files\dotnet\sdk]
3.1.410 [C:\Program Files\dotnet\sdk]
5.0.100 [C:\Program Files\dotnet\sdk]
5.0.104 [C:\Program Files\dotnet\sdk]
5.0.201 [C:\Program Files\dotnet\sdk]
5.0.204 [C:\Program Files\dotnet\sdk]
5.0.301 [C:\Program Files\dotnet\sdk]

> dotnet --list-runtimes
Microsoft.NETCore.App 2.1.12 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.24 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.26 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.27 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.28 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.13 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.14 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.15 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 3.1.16 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.0 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.4 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.6 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
Microsoft.NETCore.App 5.0.7 [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Author:	stefanloerwald
Assignees:	-
Labels:	area-Host, untriaged
Milestone:	-

[elinor-fung]

The RuntimeFrameworkVersion property described in https://docs.microsoft.com/en-us/dotnet/core/versions/selection#self-contained-deployments-include-the-selected-runtime has a slightly different meaning for self-contained versus framework-dependent deployments. For self-contained, it specifies the exact version, while for framework-dependent, it specifies the minimum version. By default, framework-dependent apps roll forward such that the latest patch version will be used (so in your case, 5.0.7 will be used instead of 5.0.6).

The roll forward behaviour can be configured through the RollForward property. For example, setting <RollForward>Disable</RollForward> would disable any rolling forward such that only the version specified by RuntimeFrameworkVersion would be acceptable - and if that exact version is not found, the app will fail to run. There's an open issue for properly documenting this: dotnet/docs#12237

I see that when I publish my application using dotnet publish -c Release -r win-x64 -p:PublishReadyToRun=true, then running the application prints 5.0.6 as expected

When a runtime identifier is specified during publish, the deployment is assumed to be self-contained (so RuntimeFrameworkVersion would mean the exact version).

[stefanloerwald]

Thanks @elinor-fung for pointing RollForward out to me. It's a shame that the docs issue is unresolved for such a long time now. The behavior isn't at all obvious and discoverability of RollForward is essentially zero (no relationship to RuntimeFrameworkVersion in the name, IDE wouldn't help either). If RuntimeFrameworkVersion would respect package-style version numbers where we can specify ranges or maximum versions, that would be far superior in my eyes.

In any case, I can now finally continue my work again, as <RollForward>disable</RollForward> correctly pins the runtime to the specified version.

I'm leaving this issue open for now because maybe it's worth having a discussion about the properties itself, not just the docs?

Thanks!
Stefan

[vitek-karas]

The potential support for version ranges is discussed here: #43332
And also here: #45306

I'm curious if there's other changes you have in mind as well?

[stefanloerwald]

Thanks for referencing those, @vitek-karas!

I was thinking that it would be more intuitive to me, if I could specify the RuntimeFrameworkVersion in the same way I can specify nuget package versions: https://docs.microsoft.com/en-us/nuget/concepts/package-versioning#version-ranges

In my case, I would have just specified [5.0.6], and then I wouldn't even have bothered anyone here ;-)

If I understand #43332 and #45306 right, it's focused on RollForward rather than RuntimeFrameworkVersion. The rules of nuget packages would be compatible with the current mechanism, as far as I can see. Only RollForward could potentially be marked as obsolete.

[vitek-karas]

Thanks for the details!

#43332 is mostly about the runtime side of things. When the app starts the version ranges would be in the .runtimeconfig.json and the runtime would have to parse them and apply them to the available frameworks on the machine (including applying roll-forward behaviors).

You're right that there should also be an SDK side of this, which could contain changes to RuntimeFrameworkVersion property and potentially others.

I don't think RollFoward would become obsolete, maybe just less used. The version ranges can't express the difference between:

• I want to run on the closest compatible version in the range
• I want to run on the latest compatible version in the range

Roll forward can do this today and there are use cases for both.

[vitek-karas]

I'm closing this in favor of #43332 which tracks the overall scenarios better.