[release/6.0] Support Single-file executable in Windows 7

[NN---]

Backport #63196 to .NET 6.0

Customer Impact

As of .NET 6.0 single file apps are not supported on Windows7.
A 6.0 singlefile app does not include API set files (api-ms-win-... files). It was assumed that the apps cannot run without bundling/extracting these files due to various dependencies.

Turns out the actual API set requirements of .NET runtime are very modest. We only use UCRT and WinRT API sets.

• UCRT, if present, is known to the loader and does not need API set files
• WinRT API is used to initialize WinRT and only if WinRT is present and detected by a dynamic check.

So the real reason why 6.0 singlefile app does not run on Windows7 is because api-ms-win-core-winrt-l1-1-0.dll is eagerly loaded, even though it would not be used.

Making api-ms-win-core-winrt-l1-1-0.dll delayloaded in singlefilehost enables apps to run. That would also match the behavior of standalone coreclr.dll where api-ms-win-core-winrt-l1-1-0.dll is also delayloaded.

Basically, with this change, instead of not supporting singlefile apps on Windows7, we can support, as long as SP1 and UCRT are installed, which is reasonable expectation and SP1 is already a requirement.

Testing

I have verified manually that with this fix singlefile apps run on Windows7 SP1

I've tried:

• default console app
• default wpf app
• default wpf app with IncludeNativeLibrariesForSelfExtract

Risk

Risk is low.
Currently .net 6.0 singlefile apps do not run on Windows7 at all, so it can't get worse.
For other versions of Windows, singlefile app will just match closer the delayload behavior of standalone coreclr.dll.

[ghost]

Tagging subscribers to this area: @agocke, @vitek-karas, @VSadov
See info in area-owners.md if you want to be subscribed.

Issue Details

---

Backport #63196 to .NET 6.0

Author:	NN---
Assignees:	-
Labels:	area-Single-File
Milestone:	-

[VSadov]

CC: @agocke

[VSadov]

I have tested the release/6.0 changes and they unblock 6.0 singlefile apps on Windows7, as expected.

[jeffschwMSFT]

Approved. We should take for consideration in 6.0.x. We will need to ensure to get a code review from the owning area and look at the CI failures.

[agocke]

@VSadov How confident are we that this will solve all problems for win7?

[VSadov]

@agocke It fixes the known problem - it no longer requires api-ms-win-core-winrt-l1-1-0.dll be present, by delay-loading it. We use it conditionally only if winrt is available, and Windows7 does not have it.
That is the only API set besides UCRT that singlefilehost.exe requires.

  Image has the following dependencies:

    KERNEL32.dll
    ADVAPI32.dll
    ole32.dll
    OLEAUT32.dll
    USER32.dll
    VERSION.dll
    SHELL32.dll
    api-ms-win-core-winrt-l1-1-0.dll
    api-ms-win-crt-stdio-l1-1-0.dll
    api-ms-win-crt-runtime-l1-1-0.dll
    api-ms-win-crt-string-l1-1-0.dll
    api-ms-win-crt-convert-l1-1-0.dll
    api-ms-win-crt-heap-l1-1-0.dll
    api-ms-win-crt-utility-l1-1-0.dll
    api-ms-win-crt-math-l1-1-0.dll
    api-ms-win-crt-time-l1-1-0.dll
    api-ms-win-crt-locale-l1-1-0.dll
    api-ms-win-crt-filesystem-l1-1-0.dll

The crt API sets are known to the OS loader and the actual implementation is loaded instead, assuming that UCRT is installed, which we should document as a requirement on Windows 7, but it is a reasonable assumption.

Considering that a WPF app runs with this fix, a lot of other apps will run.
Next to not being able to run any kind of singlefile app, this is definitely an improvement.

[NN---]

@VSadov .NET 5 already requires UCRT in Windows 7.
There is nothing changed here.

[NN---]

@leecow The SDK fix is mandatory for publishing: dotnet/sdk#23336

[agocke]

If we can't bring the SDK fix in in time, users can also use the win-x64 RID until the next update.

[NN---]

The SDK fix is merely removing the warning and string resources.
Currently main and 6.0.3xx branch don't build successfully.
This why PR is failing right now.