Please make installation for current user/all users, consistent for all packages

[plastikfan]

Description of the new feature/enhancement

I build my windows partition on a regular basis (to avoid the accumulation of junk) and I find that there is no easy way of rebuilding the application set. I have tried chocolatety for application installs as I thought that might give me a more linux like package handling capability, but I was wrong. To be fair to them, its not entirely their fault, but they do delegate the installation to the package so I suppose they are responsible to some degree. Which is why I turn to winget, in the hope that it would be able to fix this issue.

For winget, the problem as I see it is what does this mean?:

winget install <PACKAGE>

Is this installed for all users or just the current user? If there was an overriding parameter (I'm not suggesting there should be, that's up to you), like 'ALLUSERS=1', then what is the default and is this standardised for all packages.

What my request would be, is firstly enforce standardisation for all packages. Secondly I would say, an application should be installed for all users by default, like it was in the old days with 'program files', how on earth did we get to a situation where this is no longer the case and worse still, this not being consistent.

One package as an example is Discord. I installed (via chocolatety, but I am requesting a better install experience under winget) that the other day on 1 account, but it was only for that account. I spent a few frustrating minutes in a different windows account wondering where on earth the app was and why I couldn't launch it, as it was not on the start menu and didn't pop up under the search application launcher.

This request is in slight contradiction with #281, but there is a way for both to be accommodated.

Proposed technical implementation details (optional)

If you want to make install to current user only, then let's have a system setting where we can specify this. I don't want the requirements of most users to trump the way that I want to use my own system, so please give us a choice.

[ferventcoder]

Related: #189

[ferventcoder]

To manage an installer that is inconsistent with expectations (like Discord), you have to go back and change the installer. That's unfortunately going to be the ONLY option with WinGet as it manages to the installers and depends on how good they are.

[plastikfan]

Well the whole point of my request is to put in a mechanism that ensures ALL package developers behave in the same way, and they should be removed if they don't conform. We need consistency here otherwise we end up with a mess, much like most package managers on windows 10 are today. I was hoping that because winget is in is relative early stages, this would be an issue that could and should be addressed. And for this reason, I would argue that no, it does not depend on how good 3rd party package handlers are. Force them to conform or reject them. This is the whole point.

[ferventcoder]

ALL package developers behave in the same way

You say package developers - but there isn't a "package" here. It's only a manifest to an installer. So I think you mean the discord installer developers. It's been 20-30 years of a free for all on installer formats and that just doesn't get corrected overnight. I mean they have had a standard of MSI for years (and now MSIX), but folks can choose what they want and what works best and that's what you'll see a lot of. It's going to take years to correct that, although I could be wrong.

[plastikfan]

Well I think you should take a stand, and fix the mess that we now have to put up with. Be authoritarian and get everyone to do the same thing. I dont care what the end decision is, as long as everything is consistent. I long for the days when we could just install an app and every account on the machine gets access to it. That the way it works on a mac and it works well, in fact I didnt even think this was an issue. I've only noticed it recently since I have started making the comeback to windows, but issues like this make me wonder if I should bother.

[ferventcoder]

The right thing to do is likely force everyone to MSIX and only work with MSIX. I don't think WinGet will go this route, even though I read that was one of the original thoughts.

[denelon]

This is also related to #149

[denelon]

@ferventcoder do you have a source for an MSIX only path?

[ferventcoder]

Unfortunately, I doubt there is an MSIX available. I was speaking in generalities

[Annihilator]

Currently, winget defaults to (and seems to encourage), the use of per-user installers, and provides no method of selecting at installation time a per-machine installation for software that originally provides that choice. I propose implementing a switch/commandline parameter which would enable the end user to choose whether the installation performed would be per-user or per-machine. Some software offers this choice within their own installer (example: WinSCP), so a commandline parameter for the installer would be appropriate for such cases, and other software has completely separate per-mahine installers available; those would have to point to two different download URLs in the manifest, and select one depending on the choice (example: MS VS Code).

Also, the following logic would possibly be useful:

if running in an elevated command prompt: default to per-machine
if running in user context: default to per-user

[A9G-Data-Droid]

There is a software called Cameyo that monitors installation. It keeps track of everything that happens during the install, every file and registry entry that is changed. Then it creates a portable package that includes all of those things in a sandbox. It's not always perfect but I think that Microsoft has a better perspective on this to be able to reliably capture all changes. A similar concept could be used to support any installer. It could detect unconventional installs and redirect them to a different location. It could track all changes so that it could automatically remove all traces in the event that the supplied uninstaller doesn't clean up after itself. If this information was stored in an easily readable format it would make great benefits to security and cleanliness of Windows, in general. This could solve the age old problems that come from installers that pepper the systems with changes that will never be undone.

[denelon]

@plastikfan we've implemented settings via winget settings to determine whether a user prefers or requires "user" or "machine". The default is "user". Users may also pass the --scope argument with either "user" or "machine". Does this meet the intent for this Issue?

[sredna]

Does this meet the intent for this Issue?

Should there be a 3rd option; forceUser? This option would act like user but also disable UAC elevation when winget launches the installer with ShellExecuteEx.

The scenario where this is useful is as follows:

• Installer with requestedexecutionlevel set to "highest" in its manifest.
• Installer supports both per-user and machine install modes.
• Winget user is an administrator but wants to install said application in per-user mode.

Without this option the user will have to accept the UAC dialog even though they don't want nor need to run the installer elevated.

This would be useful in automation scenarios.

[plastikfan]

@plastikfan we've implemented settings via winget settings to determine whether a user prefers or requires "user" or "machine". The default is "user". Users may also pass the --scope argument with either "user" or "machine". Does this meet the intent for this Issue?

Yeah this is great, thanks.

[denelon]

@sredna sometimes it's the installer itself prompting for the UAC. That's not something we can override in the Windows Package Manager. Some of them are an unnecessary elevation based on how the installer was built/configured. In other cases, there is a service that does need elevation to be installed while the application a user would run does not require elevation.

[sredna]

That's not something we can override in the Windows Package Manager.

Sure you can.

Some of them are an unnecessary elevation based on how the installer was built/configured.

Which is normally the case when the manifest requests highest.

[JohnMcPMS]

I think that we could accommodate your request @sredna, although it would require figuring out exactly how to convince ShellExecuteEx to run with this semantic. It would also have to be an "at your own risk" option, although you seem to understand it well enough to know that it won't really force all installers to stay restricted.

If you happen to know how to do that it would save us time, as I don't see any immediately obvious way on in the documentation.

[sredna]

it would require figuring out exactly how to convince ShellExecuteEx to run with this semantic

if (forceAsInvoker) SetEnvironmentVariableW(L"__COMPAT_LAYER", L"RunAsInvoker");
ShellExecuteEx(&sei);
if (forceAsInvoker) SetEnvironmentVariableW(L"__COMPAT_LAYER", NULL);

[JohnMcPMS]

I knew that one 😄 , but I'm not sure that something process global like that will be a good fit for us long term. We will have to poke around and see if there is a direct programmatic way, or contain the environment variable effects in some way.

[sredna]

contain the environment variable effects in some way

This seems to work:

STARTUPINFO si = { sizeof(si) };
PROCESS_INFORMATION pi;
WCHAR env[] = L"__COMPAT_LAYER=RunAsInvoker\0"; // A real application needs to merge the current environment from GetEnvironmentStrings() with this new value
WCHAR app[] = L"c:\\Windows\\system32\\SystemPropertiesAdvanced.exe";
BOOL succ = CreateProcess(0, app, 0, 0, false, CREATE_UNICODE_ENVIRONMENT, env, 0, &si, &pi);
if (succ) CloseHandle...

[plastikfan]

Scoop

mmmm, I never heard of scoop. How does it handle installing for all users vs just the current user? Does it have a scope like param?

[EqualDust]

Global dir + env variables. https://github.com/ScoopInstaller/scoop#installation Other than that, the reason why scoop works is because the community cares and go out of its way to make sure that all packages are great and by default, scoop will not allow users to get packages that are non-portable and leave things lying around.

[artem-korolev]

@plastikfan we've implemented settings via winget settings to determine whether a user prefers or requires "user" or "machine". The default is "user". Users may also pass the --scope argument with either "user" or "machine". Does this meet the intent for this Issue?

Hi @denelon,
Unfortunately this setting does not work well for all applications. I'm installing software using winget under admin user. And running this soft using non-admin separate account. So going right to the example:

winget install Microsoft.Sysinternals.ProcessMonitor -h --scope machine

WinGet creates link here - C:\Program Files\WinGet\Links
And application is installed into here - C:\Program Files\WinGet\Packages\Microsoft.Sysinternals.ProcessMonitor_Microsoft.Winget.Source_8wekyb3d8bbwe

Cannot start this application under non-admin user. I started to check what's wrong and realized, that symbolik link have permissions set to read and execute for All Users in system. But target executable for this link has incorrect permissions set. It has permission to read/execute only for admin account, that I use for installing software with WinGet, but not for all users like I expect it to be

[JohnMcPMS]

But target executable for this link has incorrect permissions set.

That is a bug with portable installation. A separate issue would be helpful to track it.

[IkelAtomig]

How does it work now to install for per-user and to all users ?