-
Notifications
You must be signed in to change notification settings - Fork 85
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Missing DLL when using in CI #38
Comments
In case anyone stumbles upon this in the meantime, I created the following workaround. |
Thanks for sharing @JanDeDobbeleer |
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? |
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). |
@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 😊 |
@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 😅). |
I'm torn on how to do this elegantly. Right now our release has https://aka.ms/wingetcreate/latest I could add another exe, and two more aka.ms urls, like this: https://aka.ms/wingetcreate/latest/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! |
Here's what that would look like. https://microsoft.visualstudio.com/Apps/_build/results?buildId=35532464&view=artifacts&pathAsName=false&type=publishedArtifacts |
@palenshus I don't necessarily mind that approach. You do have 4 artifacts. The alternative is working with query params which is also weird... |
@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. |
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 |
Off topic, but nonetheless, we need a ship emoji reaction for this vibe. |
🛳 |
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.Steps to reproduce
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:
The text was updated successfully, but these errors were encountered: