Explicitly use the oldest* available LTS framework

[jashook]

Explicitly use the oldest* available LTS framework as the TargetFramework. This will more easily allow using tools like PMI with both a 3.1 runtime and a 5.0 runtime.

[jashook]

Note that 2.1 is still in support; however, to avoid changing it in a few months I chose 3.1.

[BruceForstall]

Seems reasonable, but what happens if you don't have 3.1 LTS installed (but do have 5.0 installed)? I think we need to support that scenario.

[jashook]

The SDK will allow building an older TargetFramework, and it will run with the newer runtime. Both are supported scenarios.

Example:

docker run -it mcr.microsoft.com/dotnet/sdk:5.0 bash git clone https://github.com/jashook/jitutils -b use_older_target_framework ./build.sh -b release

Will give a clean build with only the 5.0 SDK installed. The output managed dlls are all targeting .netcoreapp3.1; however, can be run with a newer runtime (5.0+).

[jashook]

The TargetFramework property should only need to be updated when the oldest LTS SDK goes out of support. At that point in time theoretically we would not care to run jitutils with those runtimes anyways.

[jashook]

Gentle ping @BruceForstall

[BruceForstall]

@jashook, If I try your example (using the same docker container), I get:

root@cba76a3dd425:/jitutils# dotnet ./src/pmi/bin/release/netcoreapp3.1/pmi.dll
It was not possible to find any compatible framework version
The framework 'Microsoft.NETCore.App', version '3.1.0' was not found.
  - The following frameworks were found:
      5.0.4 at [/usr/share/dotnet/shared/Microsoft.NETCore.App]

You can resolve the problem by installing the specified framework and/or SDK.

The specified framework can be found at:
  - https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=3.1.0&arch=x64&rid=debian.10-x64

So, the build works (that surprised me, but cool). But how do you run it without the 5.0 runtime installed?

[jashook]

Seems the ability to use the same runtime to target other frameworks breaks down with the dotnet sdk. It is still possible with CoreRun, but not with the cli.

[jashook]

Let me know how you would like to go forward, to use the 5.0 sdk/runtime without explictly requiring someone to download the 3.1 runtime would require some sort of parsing of dotnet --list-runtime and passing an env variable to be picked up by msbuild.

[BruceForstall]

Presumably, the way it is now, if you only have 3.1 installed, it builds against 3.1. But if you have just 5.0 installed, or both 3.1 and 5.0 installed, it builds against 5.0. That actually seems like good behavior to me. You must have a scenario where you have both 3.1 and 5.0 installed, but want to build against 3.1... maybe so you can copy the build somewhere that only has 3.1 LTS installed? Maybe there could be some easy-to-use option to allow your desired behavior? Or, just hack the build configuration when you need to?

@dotnet/jit-contrib Any other comments?

[kunalspathak]

I agree with what @jashook is proposing.

[jashook]

The problem is the following:

1. We have the 5.0 sdk installed
2. Using a 3.1 build of coreclr we are unable to run because pmi.dll will attempt to load System.Runtime 5.0.0.