-
Notifications
You must be signed in to change notification settings - Fork 1.5k
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
COM API "upgrade" not working when MinimumOSVersion is set in App Manifest! #4589
Comments
@JohnMcPMS thats the issue for my comment yesterday :) |
This would also help for analyzing 🗡️ /// a lot of fields and no one requesting it. <<< I DOES NOW :D /// DESIGN NOTE: |
So i think i got finally an idea what is happening: @JohnMcPMS This should be an easy fix for you and your team for the next release :) Snakefoot has a MinimumOSVersion included ManifestVersion: 1.6.0 If you go to this check ---> (sadly OSFilter is NOT publicly changable ) You will see that the relevant function is using verifyversioninfow , which delivers a wrong comparism under WIndows10 if the manifest is not changed If i change that in my app manifest it works for my code, but not for the COM or detection from winCLI via COM. https://learn.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-verifyversioninfow This must be fixed OR at least adressed via an OSFIlter ignore option :) Packages that are working like VIM has NO MinOS on MetaData |
I'm not sure exactly what is happening in your setup, but based on the data provided I'm guessing that you are using I can add the manifest, but I also recently changed the way that the code underlying that factory works. I would be very surprised if it continues to work from The supported way to use winget COM from |
@JohnMcPMS "I can add the manifest, but I also recently changed the way that the code underlying that factory works. I would be very surprised if it continues to work from SYSTEM." That would be really downer :( adding the manifest would be cool or simply make the OS check "optional". "The supported way to use winget COM from SYSTEM is with the in-process DLL. Using that, you would have control over the behavior of the version API via the manifest in your own executable." I will look into the in-process DLL. is there any example / documentation of this? It was hard enough to handle the COM API like Marti did here. Without any idea / sample, we dont have a clue how to archive that. https://github.com/marticliment/WinGet-API-from-CSharp/tree/main/WindowsPackageManager%20Interop/WindowsPackageManager Whats the difference here with this official package used in comparism to the in-proc version?https://www.nuget.org/packages/Microsoft.WindowsPackageManager.ComInterop#readme-body-tab i tried a early approach via the https://github.com/JohnMcPMS/winget-cli/blob/master/src/Microsoft.Management.Deployment.Projection/Initializers/ActivationFactoryInstanceInitializer.cs stuff and the InProc specific class IDs, BUT i always get "REGDB_E_CLASSNOTREG" and the CLSID (for example 2DDE4456-64D9-4673-8F7E-A4F19A2E6CC3 ) is not found in my registry, where as the outproc CLSID are there (C53A4F16-787E-42A4-B304-29EFFB4BF597) I am open for any approach, i simply just dont know how to implement! |
They would be coming to you via nuget (winrtact.dll), so technically you could avoid them by not updating (or not updating the interop you are using). The change is to use the registered package location to find the executable, which will not work from
Unfortunately I don't have any shipped solution here. The closest thing would be to look at https://github.com/microsoft/winget-cli/tree/7ea9bca4deebf50f1b4d8c7092e61e1339d2830f/src/Microsoft.Management.Deployment.Projection and specifically https://github.com/microsoft/winget-cli/blob/7ea9bca4deebf50f1b4d8c7092e61e1339d2830f/src/Microsoft.Management.Deployment.Projection/Initializers/ActivationFactoryInstanceInitializer.cs |
I've also created that PR for the manifest since it was very easy and shouldn't hurt anything. That is not an endorsement of support, just that it is the correct thing to do. You should still try to move to in-proc. |
I see, my current workaround already is based on the detection mechanic within the ManualServerActivation and "giving" the method what it wants. It would be interesting to see if there is some possibility to also make it seem "registered" for the USER and locate to the "correct" working executables. "cli/tree/7ea9bca4deebf50f1b4d8c7092e61e1339d2830f/src/Microsoft.Management.Deployment.Projection and specifically https://github.com/microsoft/winget-cli/blob/7ea9bca4deebf50f1b4d8c7092e61e1339d2830f/src/Microsoft.Management.Deployment.Projection/Initializers/ActivationFactoryInstanceInitializer.cs" I did look into the given stuff you posted yesterday already before, since like you said its the closest to anything. And i tried to make it work and i understand in-proc is the way. I created the WIngetFactory exactly like that and filled it with the ActivationFactoryInstanceInstaller. I updated the ClassesDefinition with the "inproc" ones. BUT i always get "REGDB_E_CLASSNOTREG" wenn calling "CreateInstance within ActivationFactoryInstanceInstaller" and the CLSID (for example 2DDE4456-64D9-4673-8F7E-A4F19A2E6CC3 ) is not found in my registry either so the error is correct, where as the outproc CLSID are there in my registry(C53A4F16-787E-42A4-B304-29EFFB4BF597) and are loaded correctly via the ManualActivation way 2)Implementation like found Microsoft.Management.Deployment.Projection/Initializers/ActivationFactoryInstanceInitializer.cs, error is happening then within CreatePackageManager So the question is, if In-proc is the solution, why are the CLSIDs not registered on my system? How can i use CreateInstance with the ActivationFactoryInstanceInstaller. It would be really great if you by any chance could update a short sample ( or someone from your team), if the other COM way is unsupported . This would be a great benefit to the community using winget and promoting this great tool :) Sidenote |
For the in-proc case, did you have Registering for SYSTEM is not supported as far as I know, other than a few select frameworks. I can ask about it again though in case things have changed. |
Related to #4589 ## Change Applies the existing shared manifest to the COM server executable.
Renaming |
Wow, i never came to THAT idea. I tested, scanning/finding packages, install, uninstall, UPGRADING the package, no "NoApplicableInstallers" :) NICE Now i just need to make the Dll export/rename thing "releasable", but that should be managable. |
I'm going to go ahead and close this issue since it looks like there is a solution. |
Brief description of your issue
When using the COM-API ( based on this project https://github.com/marticliment/WinGet-API-from-CSharp/tree/main/WindowsPackageManager%20Interop/WindowsPackageManager)
installation etc is working fine. Binaries coming from the project.
But "upgrading" via UpgradePackageAsync has been a very poor experience so far.
Most of the upgrades fail with "NoApplicableInstaller" error code, while winget.exe upgrade does upgrade successfully.
I tested it with many packages, some work (Docker.DockerDesktop) , but many does lead to the above error ( like Java8 etc )
Steps to reproduce
Install a package like "snakefoot.snaketail" in an older version "1.9.7.0"
Then use the COM API to run the UpgradePackageAsync mechanic.
Expected behavior
Successfully upgrade to application with InstallResultStatus.OK
Actual behavior
InstallResultStatus.NoApplicableInstaller
![image](https://private-user-images.githubusercontent.com/9859622/343674981-cf75a552-4b2b-416d-9990-0ed46b81ee04.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2NTg0MTMsIm5iZiI6MTczOTY1ODExMywicGF0aCI6Ii85ODU5NjIyLzM0MzY3NDk4MS1jZjc1YTU1Mi00YjJiLTQxNmQtOTk5MC0wZWQ0NmI4MWVlMDQucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMTVUMjIyMTUzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YmFkYjY0NTMzMmVkMTM4NThmMTUxY2IyYTU2ZGUyNjY3YjM2YzRmZjg0YTY2Y2U0N2I0Y2MwNzVjNWQzODQyYiZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.Rsk-bDaTDE2PQK_FAedSxGA3-fuf3CFDYU7qK6vxR-U)
By the documentation this means, that means that the Upgrade function could not find an available installer given the "options". i tried every options combination, architecture stuff, used all the switches to ignore stuff. Everyhing leads to the same result.
I looked up via the installedVersion property which "Installer" is used and what characteristiks but they are all normal and even setting stuff to the settings the installedVersion has.. It all ends the same.
If i just put "winget upgrade --id snakefoot.snaketail --silent --force" it instantly downloads the msi and installs it successfully.
Proposed problem and solution
So i think i got finally an idea what is happening:
Snakefoot has a MinimumOSVersion included
ManifestVersion: 1.6.0
MinimumOSVersion: 10.0.0.0
PackageIdentifier: snakefoot.snaketail
If you go to this check ---> (sadly OSFilter is NOT publicly changable )
You will see that the relevant function is using verifyversioninfow , which delivers a wrong comparism under WIndows10 if the manifest is not changed
![image](https://private-user-images.githubusercontent.com/9859622/344156715-eb5d03ba-9abc-45ae-879a-261f93e25297.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2NTg0MTMsIm5iZiI6MTczOTY1ODExMywicGF0aCI6Ii85ODU5NjIyLzM0NDE1NjcxNS1lYjVkMDNiYS05YWJjLTQ1YWUtODc5YS0yNjFmOTNlMjUyOTcucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMTVUMjIyMTUzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9ZDgwMzBlM2IwMTVhMDkxYTkxY2ZmMDE5NGEzY2YxYTUxYjdkNDkxYWZjNTljZmE2NGY0NDIxZDI2OTk1ZDhiZCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.BsGtWYxFqvnm1ipirCZiWJSnDs1oyUj17wNUMiaUIHI)
If i change that in my app manifest it works for my code, but not for the COM or detection from winCLI via COM.
![image](https://private-user-images.githubusercontent.com/9859622/344156922-9b9fe310-85cf-4497-8744-b480359f7dea.png?jwt=eyJhbGciOiJIUzI1NiIsInR5cCI6IkpXVCJ9.eyJpc3MiOiJnaXRodWIuY29tIiwiYXVkIjoicmF3LmdpdGh1YnVzZXJjb250ZW50LmNvbSIsImtleSI6ImtleTUiLCJleHAiOjE3Mzk2NTg0MTMsIm5iZiI6MTczOTY1ODExMywicGF0aCI6Ii85ODU5NjIyLzM0NDE1NjkyMi05YjlmZTMxMC04NWNmLTQ0OTctODc0NC1iNDgwMzU5ZjdkZWEucG5nP1gtQW16LUFsZ29yaXRobT1BV1M0LUhNQUMtU0hBMjU2JlgtQW16LUNyZWRlbnRpYWw9QUtJQVZDT0RZTFNBNTNQUUs0WkElMkYyMDI1MDIxNSUyRnVzLWVhc3QtMSUyRnMzJTJGYXdzNF9yZXF1ZXN0JlgtQW16LURhdGU9MjAyNTAyMTVUMjIyMTUzWiZYLUFtei1FeHBpcmVzPTMwMCZYLUFtei1TaWduYXR1cmU9YWRmZmI3Y2Y4NGUzMzVmOGQ3M2E1ZTBkNDhlMmI5NDJiOWFiMDlmY2FjZjdlMTk1NWU0NzVhZThlNmNkZWFmNCZYLUFtei1TaWduZWRIZWFkZXJzPWhvc3QifQ.opFGW6iiZl-Kfw5gV1XfJ0FHmXo597bK6Sd0AoZXPjg)
https://learn.microsoft.com/de-de/windows/win32/api/winbase/nf-winbase-verifyversioninfow
This must be fixed OR at least adressed via an OSFIlter ignore option :)
Environment
The text was updated successfully, but these errors were encountered: