Portable failes if installed under admin!

[MrHinsh]

I have a portable assembly that is a compiled .NET application.

This works fine under almost all circumstances, but if someone installed it as "admin," then Winget does not create the symbolic linking, and the application will fail to run within the context of its own folder. Thus, referenced assemblies will not be found.

@Trenly suggested that I statically linked assemblies... however, I have never done this (had to go look it up) and it looks like there is no support for it in .NET as far as I can see. I chatted with @stephengillie on this and I don't think we could come to a resolution.

• Is this really a requirement for a .NET tool to be deployed on Winget?
• What other options are there?
• Why does the symlink Winget creates get confused under admin?

I am not interested in creating an "installer" as the zip; its application works just fine. This, as far as I can see, is a winger issue.

For me this affects #140904 and #162930.... and any other command line application that I might build.

[stephengillie]

Would an ElevationRequirement: elevationProhibited mitigate the issue?

Note

This would have to be specified at the root level.

[MrHinsh]

OK, so Im:

1. Clone repo to get latest manefest (could not figure out how to download with wingetcreate)
2. Updating the fine locally
3. using winget create submit to replce

[MrHinsh]

OK, I suck... I tried to do wingetcreate submit --token redactedtoken -r "C:\Users\MartinHinshelwoodNKD\source\repos\wi nget-pkgs\manifests\n\nkdAgility\AzureDevOpsMigrationTools\Preview\15.1.3-Preview.2\" but the PR was a delete.

[MrHinsh]

Done:

• UPDATE: Azure DevOps Migration Tools 15.1.3-Preview.2 #163100
• UPDATE: Azure DevOps Migration Tools 15.1.3  #163101

[Trenly]

@stephengillie - Packages with the effective installer type Portable do not check for elevationProhibited since WinGet is the installer and can install them with either elevation level

[MrHinsh]

Also, the prerequisites fail to install with this specified.

[mdanish-kh]

• Related to Handle DLLs for Symlinked executables winget-cli#2711 issue at the CLI

Short answer

With how WinGet handles installation of zipped portables, a binary that requires .dlls to be referenced properly would not work if installed in an admin context or with developer mode turned on.

Long answer

Depending on the environment, WinGet will handle installations of portables (that need to be added in PATH) differently.

1. Installation from an admin shell / Developer mode turned ON

WinGet will have one directory in the PATH variable (that's usually %LOCALAPPDATA%\Microsoft\WinGet\Links), have the ZIP extracted into another directory (usually %LOCALAPPDATA%\Microsoft\WinGet\Packages) and a symlink of the desired executable gets added in the Links directory. The benefit here is that the user doesn't need to restart the shell/terminal as the Links directory is already in PATH and user can invoke the executable post install without having to reload the terminal. The problem here is that .dlls/other files the package needs can't be referenced when the package is being invoked through the symlink (that's a Windows problem I believe) and thus the package won't work correctly.

2. Installation from a user shell and Developer mode turned OFF

In this case, WinGet cannot create a symlink (symlinking requires admin privileges / Developer mode) and will resort to putting the entire path of the package in the PATH variable. You will need to restart the shell/terminal to reload the PATH variable after installation but a package such as one described above will work correctly and the files will be referenced properly. However, this approach will quickly use up the character limit of the PATH variable if you continue installing packages this way.

There's discussion in the linked issue for possible alternative approaches, but for now these are the caveats. These packages are tracked by "Zipped-Binaries" label over at the CLI repo

[MrHinsh]

Ta