ForNeVeR/Cesium

Imagine the following C program: typedef enum Side { Side_L, Side_R } Side; I expect Side_L and Side_R to be available for .NET side: either Side type should be exported, or at least constants Side_L and Side_R should exist. I propose: let's start by exposing this as a real enum type. Note that the scope of this issue is to export the type purely for .NET interop purpose: this doesn't mean that the C functions accepting this enum's values have to be converted as well. It would be nice, surely, but I'm not sure what the consequences for the function pointer compatibility this might be. So, for now, let's just update the CLR metadata, and not use the values of this enum anywhere in the Cesium-generated IL code.

In C23, bool and _Bool are the same. See section 6.4.1 Keywords:

Reproduces in the app Tabularius, commit 5a10babce37e1d1165aec11efda052eed5208a72. If I try to open any UI form using Rider's Avalonia previewer integration, it throws an error: TypeLoadException: Could not load type 'System.Runtime.Versioning.TargetFrameworkAttribute' from assembly 'Tabularius.Interop.Dto, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'. System.TypeLoadException: Could not load type 'System.Runtime.Versioning.TargetFrameworkAttribute' from assembly 'Tabularius.Interop.Dto, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'.    at System.ModuleHandle.ResolveMethod(QCallModule module, Int32 methodToken, IntPtr* typeInstArgs, Int32 typeInstCount, IntPtr* methodInstArgs, Int32 methodInstCount)    at System.ModuleHandle.ResolveMethodHandleInternal(RuntimeModule module, Int32 methodToken, ReadOnlySpan`1 typeInstantiationContext, ReadOnlySpan`1 methodInstantiationContext)    at System.ModuleHandle.ResolveMethodHandle(Int32 methodToken, RuntimeTypeHandle[]

Currently, the integration test suite on Windows periodically takes longer than 10 minutes, which is quite long. I have a hypothesis: does the MSVC compiler takes all that time? Or some of our compilation infrastructure? Whatever that is, we should optimize it somehow. And to know what to optimize, we should measure it. So, as the first step, let's measure the time taken by different stages of our integration tests on all the operating systems, and emit the results to some JSON file — so that we could download it from the CI and analyze. After having a timed breakdown, we'll see how to improve that time.

Cesium Compiler has an inherent ability to generate .runtimeconfig.json. This ability is implemented mostly for the console compiler use. Cesium SDK, on the other hand, relies on the .runtimeconfig.json generation introduced by the common .NET SDK (see #946 for details). In the logs produced when compiling a project via Cesium SDK, there are also traces of the .runtimeconfig.json being generated by the compiler — which is then subsequently ignored. To reduce the confusion, we should introduce an option for the compiler to skip generation of the .runtimeconfig.json — and this option should be utilized by the SDK, so that no redundant work is done or logged as being done. The behavior of the current command-line compiler (generate the .runtimeconfig.json by default) should be left as-is.