Usage of new TFMs in runtimeconfig and host

[vitek-karas]

The new set of TFMs as per the design is relatively large as the TFM now contains not just the version of .NET but also the target OS and possibly even OS version.

Currently the SDK writes the TFM into .runtimeconfig.json into a tfm property. Typical .runtimeconfig.json:

{
  "runtimeOptions": {
    "tfm": "netcoreapp3.1",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "3.1.0"
    }
  }
}

The value comes directly from the <TargetFramework> property in the project file.

The value in .runtimeconfig.json is used only in two relatively fringe scenarios in the host:

• When the host probes for shared store paths, the path is in the form of $DOTNET_SHARED_STORE/|arch|/|tfm| where the |tfm| is replaced by the value from the tfm property.
• When the host probes for additional paths (specified as either command line or config options) the path can contain the string |arch|/|tfm| where it's again replaced with the value of the tfm property.

The most common usage of these is the .runtimeconfig.dev.json (auto-generated by SDK during dotnet build) which contains path to the user-local shared store:

{
  "runtimeOptions": {
    "additionalProbingPaths": [
      "C:\\Users\\username\\.dotnet\\store\\|arch|\\|tfm|",

and then any usage of the shared store, where the folder structure on disk must match the TFM used in the configuration file.

If we keep the behavior as is, it would mean that these shared store paths would now include the full TFMs - like net5.0-windows10.0 or similar.

Without any changes the shared store may need to have multiple copies of the same file for all of the hierarchical TFMs: net5, net5.0, net5.0-windows and net5.0-windows10 if it would server multiple apps each using slightly different but still fully compatible TFM.

The question is if the SDK should write the "Simple" TFM into the .runtimeconfig.json - in this case probably net5.0 or if the host will have to start understanding the hierarchical nature of TFMs and be able to parse them.

[vitek-karas]

@terrajobst @jeffschwMSFT

Who is the SDK contact for the TFM work? - the SDK has probably much more "shared store" code in it, which might be affected as well.

[jeffschwMSFT]

@dsplaisted

[dsplaisted]

I think we should let this "tfm" be the part of the TargetFramework without the operating system info. So just net5.0, even if the TargetFramework is net5.0-windows. Is there any reason we would need to support a scenario where the shared store or the probing paths would vary based on OS?

[dsplaisted]

FYI @richlander @KathleenDollard @terrajobst

[terrajobst]

Is this something that needs to be done for .NET 5?

[dsplaisted]

We are tracking the SDK change for this with dotnet/sdk#11010. I'm not sure if there's any runtime change that will be needed. @vitek-karas

[vitek-karas]

@dsplaisted could you please link the right issue in SDK (the one you linked is from 3 years ago, so probably not the right one)?

I guess it's back to the original question above: What TFM will SDK write to .runtimeconfig.json - is it the simple one net5.0 always, or is it more complicated than that.

/cc @agocke

[dsplaisted]

@vitek-karas Sorry, I've now corrected the link. Our plan is to write the TargetFramework without platform information to the runtimeconfig.json, ie net5.0 even if the actual TargetFramework is net5.0-windows.

Thanks

[vitek-karas]

Perfect - in that case I don't think there's anything to be done on the hosting side (it all should work just like netcoreapp3.1 for example)

[danmoseley]

@vitek-karas can we close this issue now then? trying to burn down 5.0 milestone

[vitek-karas]

The SDK in dotnet/sdk#11010 makes sure that it only every writes the simple TFM into the runtime config. Since that is really the only place where TFM is read from in the host, it should all work the same as before and thus no new host work seems to be necessary.