Don't have fixed set of supported TFM

[kant2002]

We assume that anything net6.0 and up is supported.

Closes: #947

[ForNeVeR]

In my opinion, it's worth investigating how this works in the other compilation toolsets (e.g. C#).

I imagine that the SDK finds the reference assemblies for the current compialtion (based on the TFM) and will pass them to the compiler.

Thus it is, in a sense, creating a "constructed framework" (consisting of the SDK-resolved reference assemblies, as opposed to our set of hard-coded TFMs).

Cesium should have a mode to accept this "constructed framework" from a set of SDK-calculated options.

And then, we can redefine Net to mean "the .NET runtime Cesium is currently running on" (i.e. .NET 10 currently), NetFramework as "the currently available .NET Framework version on the current machine" (i.e. smth like .NET 4.x on Windows), and NetStandard we can leave as-is.

---

Your current solution will help us to make a step forward in processing the other TFMs, but essentially Cesium will still use hard-coded .NET 6.0 as the compilation target. See more in my comment on #947.

[kant2002]

And then, we can redefine Net to mean "the .NET runtime Cesium is currently running on" (i.e. .NET 10 currently),

I don't think this is right. I would like to have .NET Cesium run onto to be completely decoupled from binaries which Cesium produces. Otherwise it would be confusing, and we can use only 1 TFM. Again, not desirable.

[ForNeVeR]

I would like to have .NET Cesium run onto to be completely decoupled from binaries which Cesium produces.

There's no formal way to do so, because for pure command-line usage, you don't have any external nuget packages, in particular no reference assemblies for any TFM other than the one you are running on.

[ForNeVeR]

My general opinion on the matter: command-line compiler in simple use-case should be able to produce something immediately runnable, with no additional setup and options. So, targeting .NET 10 should be okay.

For advanced cases when people wanna target older runtime, they should make their build system to produce a set of arguments to create a "constructed framework", i.e. a set of ref asms for the older runtime. Cesium can help with that, but I am not considering this as the main use case.

If this is something we can achieve easy, though, we can try.

[kant2002]

Right now we have only dependencies on following things

• Runtime library / mscorlib / System.Runtime
• Cesium runtime

We possible have something in the future where we add reference to Nuget packages, or to other projects, but since it's not here I don't worry too much. In my opinion to support these cases we should send external reference assembles to cesium.compiler as CLI parameters so we can actually support constructed TFM without too much problems.

[ForNeVeR]

Runtime library / mscorlib / System.Runtime
Cesium runtime

We have three main use cases.

1. Command-line compiler. In simple cases, it should be able to "just" compile the binaries, without complex arguments being passed. Defaulting to bundled version of Cesium.Runtime is okay for this purpose.

   But probably it would make sense to pack different (netstandard/net48) versions of Cesium runtime with the compiler?

2. Usage inside of the MSBuild SDK. In this case, I expect us to rely on MSBuild that will pass us the link to runtime assembly (System.Runtime, netstandard.dll or whatever it is), and possibly (in the future?) even Cesium.Runtime.

3. Usage in CMake toolchain (not immediately .NET-aware so we can't rely on NuGet and stuff in there).

From these three, I believe that the best general course of action is:

1. Allow optional passing of "constructed framework" — i.e. explicit file references to the system assembly and Cesium Runtime.

   Investigate how would it be possible to get at least the system assembly path in MSBuild SDK (by comparing to the behavior of C# compilation in .NET SDK).

   Use this mode of operation in Cesium SDK.

2. For the console compiler and perhaps the CMake toolchain case (we aren't yet explicitly testing it, and generally think that CMake will call Cesium as a console compiler anyway — but the set of parameters will be heavily customizable) — add optional parameters for the "constructed framework" case, but also add sensible defaults. Current runtime/SDK (i.e. target .NET 10) sounds like a fine default.