Missing DLL when using in CI

[JanDeDobbeleer]

Brief description of your issue

I'm trying to embed wingetcreate in my CI workflow by downloading the tool and using the sumbit command to auto-create a PR. When doing so, this fails due to a missing DLL.

System.DllNotFoundException: Unable to load DLL 'WinGetUtil.dll' or one of its dependencies: The specified module could not be found. (0x8007007E)
   at Microsoft.WingetCreateCore.Common.WinGetUtil.WinGetValidateManifest(String manifestPath, Boolean& succeeded, String& failureMessage)
   at Microsoft.WingetCreateCore.Common.WinGetUtil.ValidateManifest(String manifestPath)
   at Microsoft.WingetCreateCLI.Commands.BaseCommand.ValidateManifest(String manifestPath)
   at Microsoft.WingetCreateCLI.Commands.SubmitCommand.SubmitManifest()
   at Microsoft.WingetCreateCLI.Commands.SubmitCommand.Execute()
   at Microsoft.WingetCreateCLI.Program.Main(String[] args)

Steps to reproduce

# Get the latest wingetcreate exe
Invoke-WebRequest https://aka.ms/wingetcreate/latest -OutFile wingetcreate.exe
# Create the PR
wingetcreate.exe submit --token $Token $Version

Expected behavior

Should execute the submit command without error. This should work without any other dependencies.

Actual behavior

Fails due to missing DLL.

Environment

OS Name: Microsoft Windows 10 Pro
OS Version: 10.0.19042 N/A Build 19042
OS Manufacturer: Microsoft Corporation
OS Configuration: Standalone Workstation
OS Build Type: Multiprocessor Free
BIOS Version: Parallels Software International Inc. 16.5.0 (49183), 4/2/2021

When trying to get the version number of wingetcreate it fails with the following as well:

.\wingetcreate.exe -?
                                                                                                     
A fatal error occurred. The required library hostfxr.dll could not be found.
If this is a self-contained application, that library should exist in [Y:\oh-my-posh\packages\winget\].
If this is a framework-dependent application, install the runtime in the global location [C:\Program Files\dotnet] or use the DOTNET_ROOT environment variable to specify the runtime location or register the runtime location in [HKLM\SOFTWARE\dotnet\Setup\InstalledVersions\x64\InstallLocation].

The .NET runtime can be found at:
  - https://aka.ms/dotnet-core-applaunch?missing_runtime=true&arch=x64&rid=win10-x64&apphost_version=5.0.5

[JanDeDobbeleer]

In case anyone stumbles upon this in the meantime, I created the following workaround.

[denelon]

Thanks for sharing @JanDeDobbeleer

[palenshus]

Thanks for filing @JanDeDobbeleer! We made a conscious decision to publish a non-self-contained binary as we felt users would be running on machines with .NET installed. Adding self-contained changes the exe size from 31MB to 91MB. We could re-evaluate this though, or possibly publish a second, self-contained, exe. @denelon / @KevinLaMS, thoughts?

[JanDeDobbeleer]

My thoughts on this is that, when I install an executable, I expect it to be able to run standalone. However, I get the context. Making both available and leaving the choice to the consumer is the best way forward, next to adding the current requirements to the documentation (I just filed a PR for the current state).

[denelon]

@JanDeDobbeleer we agree. Would you prefer that we convert this Issue into a Feature to capture that work, or close this bug and create a new feature to add a standalone .exe for the dependencies included version? We will continue to offer both based on your feedback 😊

[JanDeDobbeleer]

@denelon how you handle this in regards to ticketing is up to you (and what works best). I'm not attached to this issue outside the context of looking for a solution. I would only add a reference here in case you create a new feature/roadmap issue (people always tend to end up in the closed one 😅).

[palenshus]

I'm torn on how to do this elegantly. Right now our release has wingetcreate.exe, and two aka urls that point to it:

https://aka.ms/wingetcreate/latest
https://aka.ms/wingetcreate/preview

I could add another exe, and two more aka.ms urls, like this: wingetcreate-self-contained.exe, and

https://aka.ms/wingetcreate/latest/self-contained
https://aka.ms/wingetcreate/preview/self-contained

That doesn't feel particularly elegant to me, so if anyone has a better idea let me know, otherwise I'll go ahead with that. Thanks!

[palenshus]

Here's what that would look like. https://microsoft.visualstudio.com/Apps/_build/results?buildId=35532464&view=artifacts&pathAsName=false&type=publishedArtifacts

[JanDeDobbeleer]

@palenshus I don't necessarily mind that approach. You do have 4 artifacts. The alternative is working with query params which is also weird...

[denelon]

@palenshus at some point we may have breaking changes, Is the thinking to keep the URLs above and add a version number in the future? It's a pile of URLs to maintain, but it seems to be helpful. If we start to exceed the limits of GitHub for hosting the releases, we could move the artifacts to another CDN in the future.

I agree with @JanDeDobbeleer on avoiding the query parameters.

https://aka.ms/wingetcreate/1/latest

[palenshus]

Yep, we used "preview" to indicate the all the preview releases, but once we hit 1.0, we'd switch to /v1 or /1x or maybe just /1 for all the 1 major version releases, then /2, etc. "latest" will always point to the latest release, breaking change or not.

Okay, sounds like we're all on board with the implementation, I'll PR it

[JanDeDobbeleer]

Off topic, but nonetheless, we need a ship emoji reaction for this vibe.

[denelon]

🛳