search

OneGet / oneget

PackageManagement (aka OneGet) is a package manager for Windows
MIT License
2.38k stars 189 forks source link

Question: MSI Install Location #420

Closed Smorgan05 closed 5 years ago

Smorgan05 commented 5 years ago

Are there any plans to resolve the install location / Source when it is empty (specifically the UninstallKey -> InstallLocation entry is blank on the registry side). When I execute the "Get-Package -ProviderName msi" many of them have a blank Source. Thanks. Also happy new years.

edyoung commented 5 years ago

I'm afraid there are no specific plans to work on the MSI provider at this time. Would be open to considering pull requests.

The properties exposed for MSI packages are calculated by calling the Windows Installer API (see https://github.com/OneGet/oneget/blob/WIP/src/Microsoft.PackageManagement.MsiProvider/Deployment/WindowsInstaller/ProductInstallation.cs), we don't reference any registry location directly.

I'm not incredibly familiar with this chunk of code, but I believe the Source property comes from the Windows Installer property InstallLocation, which should be the root directory for (most of) the files that were installed as part of the MSI but is not set for most of the packages in the wild. http://robmensching.com/blog/posts/2011/1/14/arpinstalllocation-and-how-to-set-it-with-the-wix-toolset/ has some background.

If you want the Source to provide some other value, happy to discuss but probably best to work out what the desired behavior really is before digging too far into the implementation - ie, what is the desired use case for the info?

Smorgan05 commented 5 years ago

In regards to the Windows Installer API, at the end of the day the Windows Installer API pulls information registry so that it is exposed for OneGet to provide this information. Are there any plans to implement proper error checking so that the Install Location resolves such that you can calculate the install size? I mean currently the Windows Installer API pulls the values from the registry and then in the case of the Install Location key being empty returns a null / empty value. This additionally means that there is no interpretation occurring on the back end.

As noted above the desired use case is calculating the install size. I think it is time to ask whether there is any error correction in place for the APIs that you guys made?

edyoung commented 5 years ago

If what you really want is the size, there's an ARPSIZE property in Windows installer which MAY provide a better size than finding a folder and then enumerating the contents, but that's an optional property so not all msi packages will have it populated. It should be possible to expose this as an extra property from get-package, but it would be null some of the time.

In general I don't think it will be practically possible to report a reliable size for all packages installed via msi. Design decisions back in Windows 95 mean that info is not reliably available. See https://blogs.msdn.microsoft.com/oldnewthing/20040709-00/?p=38493 for more.

I understand "you're all Microsoft" but in practice I don't know what plans the Windows Installer team have. I don't think it makes sense to implement elaborate workarounds for the current behavior in oneget.

Smorgan05 commented 5 years ago

Ok, I'm just gonna respond paragraph by paragraph to be concise. The ARPSIZE Property is mostly useless because it won't get me a good return in terms of the install size and there is no clean way to get the install location to manually calculate it via folder enumeration. That's just what I can see as I've been running through methods to map the install location to the MSI without much success. This is something that the MSI team at Microsoft will have to fix to be frank.

Now on the MSI side in terms of the design decisions made that is hardly a valid excuse because Windows 95 was released over 20 years ago. By this point it should of been evident that the standards in the registry needed to be bolstered while keeping legacy functionality in place. A solution to this would of been to validate the file paths and auto fill values based on information coming from the msiexec or installer on the fly. Another way forward would of been to implement a new simplified registry structure while having an interpreter in place to again keep legacy functionality going. In any case this is a complete mess.

I don't think you guys had much of a choice in terms of what you were given. There are multiple issues in play because of the legacy APIs and what is and isn't required by exes and msis in terms of properties. In order to fix these issues the Microsoft install teams needs to talk with the Windows team to implement stronger standards. Do I think this is likely? Probably not but that is the only clear path forward because the solutions to these issues will be "elaborate workarounds" as you correctly stated. Until such a time OneGet will not be able to have reliable return data / code coverage.

edyoung commented 5 years ago

I believe the main effort on the Windows Installer side is going into MSIX at present (https://docs.microsoft.com/en-us/windows/msix/ ). I'm not really up-to-speed on it personally so don't know if it addresses your scenarios. For now I'm closing this issue because there doesn't seem to be anything actionable in OneGet.