Application does not run if TFM runtime not installed

[kant2002]

Create new project ceproj have following content

<Project Sdk="Cesium.Sdk/0.2.0">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <OutputType>Exe</OutputType>
    </PropertyGroup>
</Project>

after dotnet run

  D:\d\scratch\gol\gol.ceproj net6.0                                                                    Restore (15,5s)
You must install or update .NET to run this application.

App: D:\d\scratch\gol\bin\Debug\net6.0\gol.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet

The following frameworks were found:
  8.0.23 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  8.0.24 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  10.0.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  10.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

The following frameworks for other architectures were found:
  x86
    8.0.23 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
    8.0.23 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    8.0.24 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
    9.0.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
    10.0.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
    10.0.2 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    10.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x64&rid=win-x64&os=win10

[ForNeVeR]

In my opinion, we should

1. Cesium SDK should support <RollForward> MSBuild property; whether we should enable it by default or not we can discuss. My opinion is yes; though the standard MSBuild SDKs aren't including that by default.
2. Get portable TFM support for Cesium (which you seem to be doing in Don't have fixed set of supported TFM #948?)
   • this might be a bit more complicated if we wanna support different versions of reference assemblies and all that — I think we do, but that might be quite involved
3. Cesium templates should default to the latest supported TFM by default (net10.0 currently).

[kant2002]

I do agree wit all 3 items on first sight. 3 especially easy to work with. but in order to do that we probably should generate runtime.json using SDK instead of Cesium.Compiler. Consequentially we may need to generate that file in out integration tests as well using other means.

[ForNeVeR]

For the record, I don't understand why the stated problem happens. We already have the roll-forward mode enabled. Could you inspect the runtime config of that assembly?

[pkazakov-dev]

Hello,
I repro'd this issue and here is my runtime config (take into account that I may do something wrong since the project is in Alpha and I may not know some details about how to build projects properly).
Anyways, here is my .ceproj and runtime config:

<Project Sdk="Cesium.Sdk/0.1.2">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <OutputType>Exe</OutputType>
    </PropertyGroup>
</Project>

Runtime config:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "6.0.0"
    }
  }
}

[pkazakov-dev]

I have updated Cesium SDK version to 0.2.0 and dotnet build & dotnet run again:

<Project Sdk="Cesium.Sdk/0.2.0">
    <PropertyGroup>
        <TargetFramework>net6.0</TargetFramework>
        <OutputType>Exe</OutputType>
    </PropertyGroup>
</Project>

This is the output:

App: C:\edu\QuickTest\Project1\Project1\bin\Debug\net6.0\Project1.exe
Architecture: x64
Framework: 'Microsoft.NETCore.App', version '6.0.0' (x64)
.NET location: C:\Program Files\dotnet

The following frameworks were found:
  8.0.5 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  8.0.23 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  8.0.24 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.2 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.12 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  9.0.13 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]
  10.0.3 at [C:\Program Files\dotnet\shared\Microsoft.NETCore.App]

The following frameworks for other architectures were found:
  x86
    8.0.23 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    8.0.24 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    9.0.12 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    9.0.13 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]
    10.0.3 at [C:\Program Files (x86)\dotnet\shared\Microsoft.NETCore.App]

Learn more:
https://aka.ms/dotnet/app-launch-failed

To install missing framework, download:
https://aka.ms/dotnet-core-applaunch?framework=Microsoft.NETCore.App&framework_version=6.0.0&arch=x64&rid=win-x64&os=win10

[ForNeVeR]

It is very interesting that your runtime config doesn't seem to include the roll forward option.

I wonder if the SDK overwrites the config file Cesium compiler generates.

[pkazakov-dev]

It is very interesting that your runtime config doesn't seem to include the roll forward option.

That's true! I saw this discrepancy today too: there is Rollforward option when the assembly is produced without using SDK.
Without SDK the runtime config is as follows:

{
  "runtimeOptions": {
    "tfm": "net6.0",
    "rollForward": "Major",
    "framework": {
      "name": "Microsoft.NETCore.App",
      "version": "6.0.0"
    }
  }
}

[ForNeVeR]

The current resolution.

1. Add documentation for common SDK options (I don’t know where to get them yet — we’ll either need to find existing documentation or just write the most essential ones ourselves).

2. Enable roll-forward by default in the templates.

3. Add an option to the compiler so that it does not generate a runtimeconfig unless explicitly requested, and use this option in the SDK — meaning that only the SDK itself should generate the runtimeconfig, not the compiler, so the compiler doesn’t interfere with us.

[ForNeVeR]

Closed in #959, thanks to @pkazakov-dev.

The remaining work I have extracted to a more focused issue #960.