Advinst as another default installer #5060
Conversation
This comment has been minimized.
This comment has been minimized.
|
@microsoft-github-policy-service agree |
|
I had opened a PR for this previously - One issue with this is that AdvancedInstaller is an installer technology and not an insaller type. AdvancedInstaller can be used to build multiple types of installers, each having different install switches. See the comments in #2617 |
Through the listed installer types, there are also vendors that create these installations (Wix/Inno/Nullsoft). From what I've noticed, if the installer type is a vendor, the installer is considered as an .exe. Am I wrong? |
The difference here is that WiX will always be an MSI thpe, Nullsoft / Inno / Burn will always be an EXE type. However, AdvancedInstaller could be an EXE, an MSI, or an APPX This comment specifically describes that supporting only an EXE implementaion for AppInstaller would "not look very good" - #2617 (comment) |
I don't see any difference in the way to install an MSI, regardless of which vendor it is made. MSI is something generic. Why should an MSI made with WiX be treated as WiX, not as an MSI? Differences between vendors appear only in EXEs. |
Because there are differences between MSI's made with different vendors. Default silent install parameters and install location switches are the most common, but uninstall switches, how they write ARP data, and the internal properties can all differ with the vendor. The point of specified installer types in the client is to provide meaningful default behaviors where there are differences between vendors - and that includes MSI installers. Not only that but some implementations of MSI have bugs specific to their vendor. Take WIX for example - Regardless of what scope (user scope or machine scope) a WIX installer is installed in, the application's uninstaller entry will always be written to HKLM, which should only be for machine scoped installs (user scoped installs should write to HKCU). Other MSI vendors don’t have this issue. For a specific example - If the installer type is specified as |
|
So, from what I understand, winget cannot support "advinst" as install-type because this technology can produce multiple types of installers. However, as in the case of AdvancedInstaller, WiX can produce several types of installers too (.msi and .exe). Why is WiX always considered MSI? |
|
I'm not saying that Advanced Installer can't be supported, I was just trying to make you aware of the history and previous PR and the comments on it from @yao-msft; especially since the comments aren't just nits.
I think there is a nuance there that an msi produced by WiX is |
In this case, is it a solution to use different entries in the install-type for the installers made with AdvancedInstaller, "advinstMsi", "advinstExe" and "advinstMsix", as was proposed here? I don't see another solution. |
I would think so, but I still don’t think there has been an answer to -
|
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
This comment has been minimized.
|
@Trenly From what I can see, the unit tests have changed since the last approach. Are tests still required for installation types? For example, I can't find the tests for Wix and Burn. If they are required, is there a more recent example of such tests? |
This comment has been minimized.
This comment has been minimized.
|
Hi, I lead the team building Advanced Installer. We would like to help get this PR completed. As mentioned by others there are probably hundreds of packages built with Advanced Installer, and I can confirm our product has been used by tens of thousands of paying users over the last 20+ years to build their packages. The MSIX and APPX package types we build follow the same rules as all the packages built by other vendors, so there is no need for a dedicated installer type related to Advanced Installer for these two. The only differences are for the MSI and EXE packages. While the MSIs we build support the same command line params like other vendors, the default install path is set via a different property called APPDIR for packages built with Advanced Installer and not TARGETDIR or INSTALLDIR. The EXE is a wrapper over MSI, on top of the standard MSI switches, similar with the BURN package type for wix EXEs. Do you need more info or help with certain changes in our PR to address the discussed item? |
|
Hey @PirvulescuDaniel and @BogdanMitrache, Thanks so much for jumping in here! I've been chatting with the engineering team about the best way to proceed here. I wanted to share some context to help come to a shared understanding on our typical process. In general, we implement a feature toggle for an "experimental" feature. Then when we're ready to release that feature, we remove the toggle, and it becomes new "stable" behavior. In the case of adding a new supported installer type, that might not be the best route. I'll let our engineering team chime in on that. This would require schema changes in the manifest (WinGet package manifest, REST API, and wingetcreate). We're getting a bit too close for comfort to bring this into WinGet 1.12 (ETA GA last Tuesday in October), but WinGet 1.13 preview-1 would be fantastic. We'd be aiming for the GA of the end of Feb 2025. Normally, schema changes don't get accepted into the community repository until a couple of weeks after rollout so that any "older" clients are most likely updated as this could cause a failure in an older client. I don't think we've added anything like "hey I got a newer schema version than I understand so I should upgrade myself (or ask the user to)" or "fail with an error on invalid installer type". We'd love for you to take a look at https://github.com/microsoft/wingetcreate to help add the best logic to detect the new installer type as well so manifest updates can also be automatically handled.. We'd also time the release of wingetcreate for the same time that we start accepting the new schema in the community repository. I'm also not sure if we'd gracefully see "exe" -> "advancedExe" as an upgrade or if we'd throw the "installer type changed please uninstall the old and install the new" message. The same might hold true for "msi" -> "advancedMsi". side note: naming things is hard. I'll file and cross link the issues for the other repositories, and I expect the engineering team will chime in soon™️. |
|
I'm also curious about finding a reasonable way to make sure when we get a package with an .exe or .msi we do the right things in terms of installer detection to help PR authors over at winget-pkgs do the right thing. I'm sure @Trenly would love to stress test our validation infrastructure by finding a way to crawl all the active packages to get them updated to the proper installer type. 😊 |
|
I've actually been considering that @denelon Now that I have a PowerShell module for detecting installer type, I could iterate over all installer urls and check them |
|
I should have mentioned the winget-pkgs tools as well as wingetcreate. |
|
To be clear, the issue was targetting EXE implementations like microsoft/winget-pkgs#56369 where advinst implenet their own silent switches |
Microsoft Reviewers: Open in CodeFlow