Setup releases to publish to choco and/or winget package managers about artifacts-credprovider

[XVII]

Not stale.

[Dan-Albrecht]

@jeffreyrivor, is there an actual plan here? I'm setting up a new machine now and cannot use your official install script https://aka.ms/install-artifacts-credprovider.ps1, because of the rate limit problems mentioned in multiple other won't fix issues (#244, #369, #380).

Supporting winget would be perfect here.

[XVII]

I had mentioned something similar in #370 but they won't accept feature requests here.

If you would like to upvote/comment on the following it might help get some attention:
https://developercommunity.visualstudio.com/t/Add-installer-options-for-Azure-Artifact/10308779

[JohnSchmeichel]

We're no longer forwarding to the developer community, so having issues here is appropriate.

[XVII]

@JohnSchmeichel , great another overnight change :), so the two issues that were closed #370 and #379 can be added to this request. I'll reiterate my comments here.

An installer or winget package would help deployment at a larger scale though services like InTune or other software management tools.
This might be an MSI, Exe or winget based deployment options.

At the moment the only installation options are a Zip of un-trusted PS scripts.

[github-actions]

This issue has had no activity in 90 days. Please comment if it is not actually stale.

[github-actions]

This issue has had no activity in 90 days. Please comment if it is not actually stale.

[XVII]

🙄

[jeffreyrivor]

It seems like this should be possible now in winget now that Windows Package Manager manifests allow portable zip, although I can't tell at first glance if the zip must contain an installer or if the contents can just be extracted into a directory directly as the "installation."

[jeffreyrivor]

I just linked a PR in winget-pkgs to this issue that takes a crack at integrating into winget, but the standalone zip with lack of an installer (WiX/Nullsoft/etc.) seems to make it unable to be fully automatic with winget; the install location can't be preset to the NuGet plugin directory, or if this can be set in the manifest I couldn't tell what YAML property would do it.

And I guess requiring the --location argument to be specified manually on install is preventing the PR build validation from succeeding, but the failure in the PR build is opaque so I'm not sure.

Update: the issue appears to be due to the default symlinking winget does to add the CredentialManager.Microsoft.exe to the PATH and the test case of launch the console app via the PATH symlink fails due to inability to find dependent DLLs (the DLL loading algorithm doesn't use the actual location of the exe as the DLL search path). That said, there seems to be no mechanism to just "extract the zip here and don't add it to PATH" in winget.

[jeffreyrivor]

Unfortunately, winget doesn't support raw zip (e.g. no nested installer exe/msi/etc) in the structure that would be required to place the artifacts credprovider in the NuGet plugin location.

1. As noted in the linked PR, the --location argument would need to be manually specified to the NuGet plugin directory %USERPROFILE%\.nuget\plugins, there's no way in the winget YAML definition to default this value.
2. winget adds the executable extracted from the raw zip to PATH via a symlink.
3. Additionally, winget PRs are tested against an integration that attempts to ensure that raw zips that just extract an executable (and not launch the extracted executable as an installer) that are added to PATH are executable on that PATH; this test fails because the credprovider needs to load DLL dependencies that fail to handle symlinking properly. This is blocking the PR in its current state.

In summary, unless winget changes to allow a different default location (in this case, the NuGet plugin directory) and to allow disabling symlinking and adding to PATH for raw zipped exe extraction (NuGet doesn't need to use PATH to locate it anyhow), the credprovier will have to be packaged into an actual installer (using WiX/Nullsoft/Inno/etc) in order to be ingested into winget.

[kimsey0]

Can we package it into an actual installer? If so, is there a preferred install system, for example one of those you mentioned (WiX/Nullsoft/Inno)? I guess the installer should just reproduce the behavior of the current install script closely.

[namra98]

Best solution would be to make MSI out of it and publish to winget? since all this script is doing is some installation?

[kimsey0]

The script has a bit of logic to handle .NET versions, but other than that, it just copies a DLL into a specific folder.

[kimsey0]

And if we're to make an MSI, we need to decide on an MSI creation tool, like WiX or NSIS mentioned above.