Yeah... personally I think it's really unreasonable to expect anyone to do that, because of how complicated dotnet.exe is and how many platforms you'd need to build for. That's why I am hoping we will come to some sort of conclusion in that issue I linked

Technically you could just fork core-setup and change the subsystem linkage of dotnet.exe, and then publish a nuget package with a different name

A stable release of a package should not have on a prerelease dependency. Either modify the version spec of dependency "SkiaSharp [1.56.1-beta, )" or update the version field.An error occurred when executing task 'Create-NuGet-Packages'.Error: NuGet: Process returned an error (exit code 1).

Package Avalonia.Xaml.Behaviors0.4.1-build329-alpha is not compatible with netcoreapp1.1 (.NETCoreApp,Version=v1.1) / win-x86. Package Avalonia.Xaml.Behaviors0.4.1-build329-alpha supports: portable-net45+win8 (.NETPortable,Version=v0.0,Profile=Profile7)
One or more packages are incompatible with .NETCoreApp,Version=v1.1 (win-x86).

Ok. Because I'm not sure how some interoperability scenarios would work efficiently without native layers since they'll already designed to work together: Video rendering and D3D11 swap chain embedding for 3d rendering