NativeAOT: Custom runtime without AppContext class throw

[kant2002]

Description

If you compile application with custom runtime where System.AppContext class is not defined, compiler crash

 System.AggregateException: One or more errors occurred. (Code generation failed for method '[S.P.CompilerGenerated]Internal.CompilerGenerated.<Module>.SetAppContextSwitches()')
 ---> ILCompiler.CodeGenerationFailedException: Code generation failed for method '[S.P.CompilerGenerated]Internal.CompilerGenerated.<Module>.SetAppContextSwitches()'
 ---> System.InvalidOperationException: Expected type 'System.AppContext' not found in module 'SeeSharpSnake'

Even if I apply suggestion from #63862 (comment) to the csproj file due to this line

runtime/src/coreclr/nativeaot/BuildIntegration/Microsoft.NETCore.Native.targets

Line 230 in e790378

<IlcArg Include="--appcontextswitch:RUNTIME_IDENTIFIER=$(RuntimeIdentifier)" />

workaround no longer working.

Reproduction Steps

Close code from this PR MichalStrehovsky/SeeSharpSnake#24
Apply #63862 (comment)

Expected behavior

Custom runtimes can be built using NativeAOT

Actual behavior

Currently it is blocked.

Regression?

No response

Known Workarounds

No response

Configuration

No response

Other information

No response

[MichalStrehovsky]

We could make that line conditional on IlcSystemModule being empty and maybe that would work?

But I'm not very sympathetic to doing all this with dotnet because it's a constant uphill battle. I was surprised you made it work with a csproj in the first place; invoking ILC manually would be better. Either that, or bflat build --bare.

[kant2002]

We could make that line conditional on IlcSystemModule being empty and maybe that would work?

yes, that would work. I manually remove line and everything was working, so that’s essentially the same.

But I'm not very sympathetic to doing all this with dotnet because it's a constant uphill battle

I’m gladly accept burden of testing this. Seems to be we have only one issue related to this mode in 2-3 years? Having no runtime mode using dotnet is IMO important since this is one less habit to change for developers.

technically there UEFI environments where bflat probably would not work.

I would even have appetite to provide fix and have it land Net 7(maybe not in RTM) but at least in first patches. 🥺🙏

[MichalStrehovsky]

I would even have appetite to provide fix and have it land Net 7(maybe not in RTM) but at least in first patches.

I don't know if we have .NET 7 servicing bar somewhere public, but it looks somewhat like this: #72297 (comment). I have a hard time fitting this into any of the bullet points.

technically there UEFI environments where bflat probably would not work.

bflat build --bare -x --libc none. It will fail at the linking stage, but that's fine, we just need the linker command line that the -x argument printed before invoking linker. Then run again as bflat build --bare -c --libc none to get an object file. Run linker manually based on the printed command line, substituting EFI where needed and dropping libraries that are pointless for EFI. This also lets you build EFI apps on Linux, which is not possible with dotnet because dotnet needs link.exe from the Windows SDK, and bflat comes with own linker.