Runtime: Build a Windows 7 compatible Single-file AppHost

[BrainSlugs83]

General

With .NET Core 3.0-preview8 -- I compiled a standalone exe for Windows 7 (x86) RID using the following command:
dotnet publish -c Release -r win7-x86 -o .\bin\Redist\windows /p:PublishSingleFile=true /p:PublishTrimmed=true /p:DebugType=None

This produces a single .exe file output that runs fine on Windows 10 (x64).

But when I copy this .exe file to a Windows 7 Home Basic (x86) machine, I get the following error message when trying to run it:

The program can't start because api-ms-win-crt-runtime-l1-1-0.dll is missing from your computer. Try reinstalling the program to fix this problem. 

According to this issue: https://github.com/dotnet/core-setup/issues/3220 it looks like this external dependency is possibly the "Windows Universal C Runtime", which can be found at this location: https://support.microsoft.com/en-us/help/2999226/update-for-universal-c-runtime-in-windows

There does appear to be a download link for Windows 7 (x86), but when you try to install it on said operating system, you get the following message: The update is not applicable to your computer. -- This leads me to believe that it is impossible to run my app on Windows 7 (x86).

Expected Behavior:

• My app runs on Windows 7 (x86) without having to install anything that does not ship with
  the OS. (Many Corporate and Enterprise environments do not have the ability to install
  random service packs on their machines without significant IT involvement and overhead.)

  • Also, I'd like to avoid dependency issues, e.g. if a user has the wrong version installed, etc.

• If I do have to install some random service pack, tell me about it and where to download it
  instead of a random missing dll notice, as that's a disaster waiting to happen. (A non-technical
  user might just google the error message and follow some youtube video's instructions to
  download random .dll files from untrusted sites and dump them into the app's folder!)

Other thoughts

• This isn't that tall of an ask. We wrote GUI software for Windows 7 with MinGW 20 years ago,
  and it never required any c runtime dlls; everything was statically linkable. (And never more
  than 2 MB) -- This is literally just a console app -- if there is some external dependency, just
  link it into the executable already! 😑

[scalablecory]

We do not claim Windows 7 support: only Windows 7 SP1.

If I do have to install some random service pack, tell me about it and where to download it instead of a random missing dll notice

This is good feedback, thank you.

There does appear to be a download link for Windows 7 (x86), but when you try to install it on said operating system, you get the following message: The update is not applicable to your computer. -- This leads me to believe that it is impossible to run my app on Windows 7 (x86).

Correct, the update is for Windows 7 SP1.

We wrote GUI software for Windows 7 with MinGW 20 years ago, and it never required any c runtime dlls; everything was statically linkable. (And never more than 2 MB) -- This is literally just a console app -- if there is some external dependency, just link it into the executable already! 😑

Dynamic linkage gives users a better experience. By allowing the CRT to be updated independently of the app, you can fix security issues quicker without relying on developers staying on top of things.

[scalablecory]

@jeffschwMSFT is this something you can assist with? I think a version check in the host exe with a useful message would be helpful.

[jeffschwMSFT]

We currently do not do any native trimming, so the api-* files should still be present in the output.

cc @swaroop-sridhar @sbomer

[swaroop-sridhar]

I tried publishing a simple console app. The trimmed published single-file for win7-x86 runtime does contain api-ms-win-crt-runtime-l1-1-0.dll.

@BrainSlugs83 Can you please confirm if api-ms-win-crt-runtime-l1-1-0.dll is indeed missing, or somehow unusable?
1) If you take the output of a "normal" publish to the win7 machine, does it run OK?
[dotnet publish -c Release -r win7-x86 /p:DebugType=None, copy the output folder]
2) If you look at the temp directory (%tmp%/.net/<name-of-app>/<some-hash>/) you can see the files extracted from the single-file app. Is api-ms-win-crt-runtime-l1-1-0.dll found there?

[jkotas]

@swaroop-sridhar The problem is that the apphost depends on these api-ms-win-crt-* contracts. The process fails to start. We do not even start extracting the files.

[jeffschwMSFT]

In the short term we could disable these files from the bundle:


PreserveNewest
true


In the longer term we need to explore what a more Win7 compliant apphost would look like.

[BrainSlugs83]

@swaroop-sridhar the output I get from build is a single .exe file. -- so I'm confused as to what you want me to check. -- There are definitely no DLL files being dumped out into my -o directory.

The lack of SP1 on my environment is interesting. I grabbed the latest installation media from MSDN. Also, it wasn't obvious to me that SP1 was related to this (from any of the error messages I got along the way). It literally never even occurred to me. So yeah, a better error message about what's missing and how to correct it would be nice. If possible. 🤔

@jkotas to get around this issue back in the day, we used to load DLLs at runtime instead of link against them. -- It made the C++ a bit more annoying to write, but nothing a wrapper class couldn't tackle:

• https://docs.microsoft.com/en-gb/windows/win32/dlls/using-run-time-dynamic-linking
• https://docs.microsoft.com/en-us/windows/win32/api/libloaderapi/nf-libloaderapi-loadlibrarya

[swaroop-sridhar]

@BrainSlugs83 We understand the problem given @jkotas's explanation
(https://github.com/dotnet/coreclr/issues/26493#issuecomment-527715066).

Without the Dlls being separate, there's no way to run the host (let alone extract contents or print diagnostic messages). The error message you see is from Windows.

The work around for now is to keep the api-ms-win-crt-runtime-l1-1-0.dll separate from the single-exe, as @jeffschwMSFT suggested above. But in later stages of single-exe support, we need to investigate a better solution (possibilities to link in the DLL into the host).