PR #434703 - How to proceed with missing dependency

[Piotr Frankowski (fioletoven)]

Hi,
I have a question to my PR #434703:

I just realized after my comment in the pr, that Stephen Gillie probably do not see these comments and there is some kind of automatic validation first, that I somehow must probably pass first.
But at this point I do not know what dependency I am missing, I have checked manifest on a clean Win10 installation and it runs without any problems, And as I am expecting, that adding next comment to the PR would probably end with the same message, what should I do next? Is there something obvious that I do not see here or should do?

[Tanbir Hossain Ramim (TanbirRamim)]

The exit code tells you which kind of problem it is: -1073741515 is 0xC0000135, STATUS_DLL_NOT_FOUND, so Windows could not load a DLL that b4n.exe imports, before your code even ran. (The wminet_utils.dll lines above it are the validator failing to clean up child processes, not your package.)

I downloaded b4n-1.0.1-x86_64-windows.zip (the SHA256 matches your manifest) and listed the imports of b4n.exe. Everything is part of Windows (kernel32, ntdll, bcrypt, ws2_32, the api-ms-win-crt-* UCRT set...) except one: VCRUNTIME140.dll. Your Win10/Win11 machines run it because the VC++ runtime is almost always already installed by some other app; the clean validation VM evidently still does not have it at launch time, even with the PackageDependencies you added (your manifest syntax for those is correct).

The robust fix for a Rust binary is to not depend on it at all: link the C runtime statically, then cut a new release and update the URLs/hashes.

# .cargo/config.toml
[target.x86_64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

[target.aarch64-pc-windows-msvc]
rustflags = ["-C", "target-feature=+crt-static"]

After rebuilding, dumpbin /dependents b4n.exe (from a VS Developer prompt) should no longer list VCRUNTIME140.dll, and you can drop the VCRedist dependencies from the manifest. The binary grows by a few hundred KB, which is the usual trade-off for CLI tools on winget.

[Piotr Frankowski (fioletoven)]

Thanks for the detailed answer.

I know that my app requires VCRUNTIME140.dll. I just thought that I fixed it by adding a dependency to the manifest.
I have confirmed it by running b4n on clean Win 10 installation before running WinGet (it was not working), and after installing the manifest (worked perfectly fine, see reattached screenshot):

Therefore, are you saying that it is not possible to go through this automatic validation with a dependency in the manifest? I just hoped that maybe I am missing something obvious here and I do not need to statically link everything (I would like to avoid increasing the size of the binary).

[Imre Eilertsen (DandelionSprout)]

There's a notorious(ly stupid) and at least slightly officially acknowledged glitch in the pipelines for portable ARM64 apps, where the pipelines will somehow insist on trying to find the x64 version of a criticial system .dll called wminet_utils.dll instead of the ARM64 version.

The only workaround that doesn't involve waiting for months, is to remove the ARM64 installer from the manifest.

[Piotr Frankowski (fioletoven)]

Thanks, removing arm64 helped.