WinGet fails in the "silent install check" of the Microsoft Store

henryruhs commented 1 month ago

Brief description of your issue

Running a NullSoft Installer on MS Store's package validation is causing a general fatal error during the "silent install check".

grafik

Steps to reproduce

NullSoft Installer's section block:

Section 'Prepare Your Platform'
    DetailPrint 'Install Git'
    nsExec::Exec '$LOCALAPPDATA\Microsoft\WindowsApps\winget.exe install -e --id Git.Git --silent --accept-source-agreements'
SectionEnd

Expected behavior

Installation should pass like it does on my local machine.

Actual behavior

A general fatal error being thrown.

C:\__w\1\s\external\pkg\src\AppInstallerRepositoryCore\Microsoft\Schema\1_0\Interface_1_0.cpp(197)\WindowsPackageManager.dll!00007FFDEA47597D:
(caller: 00007FFDEA47BE09) Exception(1) tid(1764) 800700B7 Cannot create a file when that file already exists.

Logfile: WPM_40749569_f6582e189d6a255d92767e21d2d72a64dc1b80cb8da6c1d9dc20f9ad670dcc68.txt

Environment

I used WinGet v1.7.11261 and the default 1.6.3482 from Microsoft Store.

Trenly commented 1 month ago

I'm not sure that using winget inside of an installer is a valid use case, and I personally would recommend against it.

Although WinGet is included in many OS builds now, there is no guarantee that a user's configuration will support it. For example, a user could have removed all the default sources and added their own private source which doesn't have Git.Git. Some users could still be on an older 1.6 version of WinGet that can't install anything due to an outdated CDN (requiring them to manually update WinGet first). A new version of Git submitted to WinGet could break your installation flow. There's many other scenarios that could break your install if you take a dependency on WinGet or on the WinGet source. In an enterprise scenario, WinGet could be blocked by Group Policy. In the future Git could decide they want to remove all their manifests from the WinGet source, thereby making it unavailable. A hash mismatch on the Git download would cause the install to fail. Some users could manually remove WinGet from their machine if they try hard enough.

henryruhs commented 1 month ago

It's in the natur of a software developer to question the approach rather than giving a suggestion to solve it. No worries, I do in fact install winget on the system.

The issue seems to be similar to: https://github.com/microsoft/winget-cli/issues/1433 Is this related to adding the manifest due lack of permission?

denelon commented 1 month ago

WinGet has a notion of dependencies in the manifest to handle installing any other packages with dependencies from the same source.

This appears to be a scenario where the installer is looking to leverage WinGet to install dependencies "inside" the installer. I'd like to understand the scenario a bit more here.

The Microsoft Store has their own policies regarding what an installer is doing, and there are several other automated processes evaluating what is being installed on a system during package installation flows.

henryruhs commented 1 month ago

This appears to be a scenario where the installer is looking to leverage WinGet to install dependencies "inside" the installer. I'd like to understand the scenario a bit more here.

Do I understand correct, that you like to know the scenario of using winget? I took this installation guide and wrote a nullsoft installer to automate everything for end-users.

I could just use PowerShell to download and install everything, but a package manager is more elegant in my opinion.

The Microsoft Store has their own policies regarding what an installer is doing, and there are several other automated processes evaluating what is being installed on a system during package installation flows.

I tried to work with --scope user but this did not work.

denelon commented 1 month ago

I see a few potential challenges with the way this is being called by nsexec command.

The first is the explicit path for WinGet may change or may not be valid.
The second is that no source is being specified which means if the user doesn't have the default source your application is expecting, it would fail, or unintentionally install a package from another source.
The "--accept-source-agreements" is an "explicit" call a user may not be making or intending to make when the package is installed, and if package agreements are required, they also would not be handled via explicit consent.

Getting past the technical challenges should be possible.

If the installer is depending on WinGet to handle dependencies, I'd suggest leveraging the COM APIs in WinGet rather than calling the executable. If this package is only going to be used by the Microsoft Store for distribution, then it's reasonably safe to assume WinGet is present on the system, since the Microsoft Store client is leveraging WinGet to perform the WIn32 installation.

We still have work to do in WinGet to expose the sources to the COM API so they can be validated before a call fails during installation. You could test by using winget source remove winget and then running the installer to test that scenario.

There are also Group Policies an enterprise could configure to prevent calls to winget.exe. That would also cause the installation of the dependency to fail. You can set the policies, and run winget --info to see which policies are configured.

As far as the agreements go, that's a bit of a stickier problem. I'm not able to offer legal advice, so I'd check to make sure liabilities can be avoided. I'd expect an application installing other applications to inform me and give me the ability to agree or cancel. If consent is given up front, then the need to prompt for those dependencies may be something that can be eliminated, but again, I'd get legal advice before proceeding on that front.

henryruhs commented 1 month ago

Thank you for bringing up the legal considerations regarding the installer that I need to address. I was not aware of it, but will fix it in the future.

I'm not sure if I understand you correct but the WinGet install script has been added to cover Windows 10 users. The current issue we have are the conflict with the MS Store's instance of WinGet on their server.

Right before you responded, I did another run using --verbose-logs.

WPM_89862289_92d6281ace9434050b96d2fc8a63888f59d06ee1de2440cbc34c2e2d7253d32c.txt

Removing the winget source will cause the package not to be found!? I just tried it and the silent check is passing - this is false positive because nothing has been installed.

grafik

Unfortunately no access to logs in that case.

I tried ealier this day to limit the source to winget - it then ignored the msstore source but I assume writting down the winget manifest (or whetever it does) causes the fatal error.

denelon commented 1 month ago

I'm guessing here since I don't know exactly what the environment validation is happening in for the Microsoft Store. I'd expect either the client in validation for the "msstore" source either doesn't have the default "winget" source enabled/configured, or when the command is being executed, it's not happening "inline", but it's launching a window to run the command. Unfortunately, I don't have a way to determine that. I'll have to reach out to someone on the store team. Either way, this kind of cross-source dependency may be prohibited by some kind of policy.

Can you send me an e-mail so I can forward the thread to the store team?

henryruhs commented 1 month ago

I gave up on the MS Store due this issue and the restriction that everything being installed via winget is considered as bloatware.

microsoft / winget-cli