.NET 8: Enable build and run of project with arbitrary TFM

I write a bunch of samples that I want to enable for developers to learn the product. TFMs are a limiting artifact when you want to enable a project to run on a newer runtime even though it targets an older one. I feel badly when I change the TFM solely to get to the app to run on a newer runtime.

App I am using: https://github.com/richlander/testapps/tree/master/versioninfo

In past, I used the TargetFrameworks approach, like the following:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFrameworks>netcoreapp3.0;net5.0</TargetFrameworks>
  </PropertyGroup>

</Project>

This is a pain, because dotnet build does the following:

PS D:\git\testapps\versioninfo> dotnet run
Unable to run your project
Your project targets multiple frameworks. Specify which framework to run using '--framework'.

That’s unacceptable as a default experience for samples, and only to enable a more advanced scenario.

Next approach is to configure the project for the min-support TFM and then mutate via the CLI:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
  </PropertyGroup>

</Project>

PS D:\git\testapps\versioninfo> dotnet run
**.NET Core info**
Version: 3.1.2
FrameworkDescription: .NET Core 3.1.2
CoreCLR Build: 3.1.2-servicing.20066.2
CoreCLR Hash: fd22fd600a2526a7c58536da0e80325eb710d7f1
CoreFX Build: 3.1.2
CoreFX Hash: e946cebe43a510e8c6476bbc8185d1445df33a1a

**Environment info**
OSVersion: Microsoft Windows NT 6.2.9200.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

PS D:\git\testapps\versioninfo> dotnet build /p:TargetFramework=net5.0
Microsoft (R) Build Engine version 16.7.0-preview-20220-01+80e487bff for .NET Core
Copyright (C) Microsoft Corporation. All rights reserved.

  Determining projects to restore...
  Restored D:\git\testapps\versioninfo\versioninfo.csproj (in 61 ms).
  You are using a preview version of .NET. See: https://aka.ms/dotnet-core-preview
  versioninfo -> D:\git\testapps\versioninfo\bin\Debug\net5.0\versioninfo.dll

Build succeeded.
    0 Warning(s)
    0 Error(s)

Time Elapsed 00:00:00.83
PS D:\git\testapps\versioninfo> .\bin\Debug\net5.0\versioninfo.exe
**.NET Core info**
Version: 5.0.0
FrameworkDescription: .NET 5.0.0-preview.4.20227.9
CoreCLR Build: 5.0.0-preview.4.20227.9
CoreCLR Hash: 6d1f7e01d3429054ec3dcb7c75b3450b9fe1429e
CoreFX Build: 5.0.0-preview.4.20227.9
CoreFX Hash: 6d1f7e01d3429054ec3dcb7c75b3450b9fe1429e

**Environment info**
OSVersion: Microsoft Windows NT 10.0.19624.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

PS D:\git\testapps\versioninfo> dotnet run /p:TargetFramework=net5.0
/p:TargetFramework=net5.0
**.NET Core info**
Version: 3.1.2
FrameworkDescription: .NET Core 3.1.2
CoreCLR Build: 3.1.2-servicing.20066.2
CoreCLR Hash: fd22fd600a2526a7c58536da0e80325eb710d7f1
CoreFX Build: 3.1.2
CoreFX Hash: e946cebe43a510e8c6476bbc8185d1445df33a1a

**Environment info**
OSVersion: Microsoft Windows NT 6.2.9200.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

PS D:\git\testapps\versioninfo> dotnet run /p:TargetFramework=net5.0 -- arguments
/p:TargetFramework=net5.0
arguments
**.NET Core info**
Version: 3.1.2
FrameworkDescription: .NET Core 3.1.2
CoreCLR Build: 3.1.2-servicing.20066.2
CoreCLR Hash: fd22fd600a2526a7c58536da0e80325eb710d7f1
CoreFX Build: 3.1.2
CoreFX Hash: e946cebe43a510e8c6476bbc8185d1445df33a1a

**Environment info**
OSVersion: Microsoft Windows NT 6.2.9200.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

I added the following code to the app to print arguments.

            foreach(var a in args)
            {
                Console.WriteLine(a);
            }

The approach with /p:TargetFramework seems to be generally working, but is failing for the run case. The docs suggest that what I’m doing should be working.

Can my preferred pattern be enabled? This: dotnet run /p:TargetFramework=net5.0 --. That’d be awesome.

Not what I want, but I did discover that the following pattern works:

<Project Sdk="Microsoft.NET.Sdk">

  <PropertyGroup>
    <OutputType>Exe</OutputType>
    <TargetFramework>netcoreapp3.0</TargetFramework>
    <TargetFrameworks>netcoreapp3.0;net5.0</TargetFrameworks>
  </PropertyGroup>

</Project>

PS D:\git\testapps\versioninfo> dotnet run
**.NET Core info**
Version: 3.1.2
FrameworkDescription: .NET Core 3.1.2
CoreCLR Build: 3.1.2-servicing.20066.2
CoreCLR Hash: fd22fd600a2526a7c58536da0e80325eb710d7f1
CoreFX Build: 3.1.2
CoreFX Hash: e946cebe43a510e8c6476bbc8185d1445df33a1a

**Environment info**
OSVersion: Microsoft Windows NT 6.2.9200.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

PS D:\git\testapps\versioninfo> dotnet run -f net5.0
**.NET Core info**
Version: 5.0.0
FrameworkDescription: .NET 5.0.0-preview.4.20227.9
CoreCLR Build: 5.0.0-preview.4.20227.9
CoreCLR Hash: 6d1f7e01d3429054ec3dcb7c75b3450b9fe1429e
CoreFX Build: 5.0.0-preview.4.20227.9
CoreFX Hash: 6d1f7e01d3429054ec3dcb7c75b3450b9fe1429e

**Environment info**
OSVersion: Microsoft Windows NT 10.0.19624.0
OSDescription: Microsoft Windows 10.0.19624
OSArchitecture: X64
ProcessorCount: 8

For clarity, I don’t like this approach for two reasons:

• It is an abomination of the project format.
• It requires including all the TFMs I want to support. This is similar to how RIDs were in 1.0. Super painful.

On the one hand, the existing dotnet build support for my use case is satisfactory (super happy it works), but on the other, it seems the scenario is broken for dotnet run where run and build should have parity.

So, I think this should be fixed. Thanks!

[jkotas]

<TargetFramework>netcoreapp$(NETCoreAppMaximumVersion)</TargetFramework> works as “latest” since .NET Core 3.0.

It would be nice if one can say <TargetFramework>latest</TargetFramework> to get the latest. Or even better - default to latest if TargetFramework is not specified.

[richlander]

Related to: https://github.com/dotnet/runtime/issues/71286