Does not support 8.0 and other frameworks

[kant2002]

Create new app project. Change TFM to net8.0

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

dotnet run produce following error

dotnet run
C:\Users\HP\.nuget\packages\cesium.sdk\0.2.0\Sdk\Sdk.targets(58,9): error Unsupported TargetFramework: net8.0. Supported frameworks are: net6.0, netstandard2.0 and net48.

[ForNeVeR]

See more in my comments for #946 and #948. I believe these issues to be two sides of the same task — utilising the SDK-resolved reference assemblies more. We can do that.

[pkazakov-dev]

Repro'ed this one as well. To me looks like this one blocks #946, because even if the templates updated to net8.0 or net10.0 we'll run into issue in the subject!

[ForNeVeR]

So, together with @pkazakov-dev we found how it works in C#.

During build .NET SDK calculates @(ReferencePathWithRefAssemblies) (mostly calculated during ResolveTargetingPackAssets MSBuild target), and passed that to the C# compiler.

The compiler then uses these assemblies as references/inputs for compilation.

In fact, the same target is part of a compilation based on Cesium SDK as well! Cesium just ignores these items.

We can easily make Cesium to respect @(ReferencePathWithRefAssemblies) in either of two ways.

1. In Cesium SDK's compilation task, we could filter these input assemblies, locate the system runtime DLL among them (System.Runtime.dll, mscorlib.dll, netstandard.dll — which one depends on the target framework), and use it for further compilation.

   We could also include detection of Cesium.Runtime.dll here, although we might skip that for now, and focus on the system runtime assembly only.

2. Alternatively, we could change the way we approach the compilation. Right now, our two referenced assemblies (system runtime & Cesium runtime) are represented as two different hardcoded assemblies — two separate strict arguments.

   We could consider not treating them as two distinct assemblies, but instead implement a generic mechanism to search among referenced assemblies. All places where we currently look up things in the system runtime or in the Cesium runtime would need to be refactored to use a generalized search across references. Then this way of passing inputs to the compiler would work naturally on its own — no more distinct arguments, and just type resolve across the all referenced assemblies.