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
Allow burn packages to be hidden in the ARP #4454
Comments
|
Has to be opt-in.
|
|
@TriageTeam makes sense. Wouldn't want to break existing expectations. In our case we're actually using a custom BA as well, so I'd expect to have to make a change or two to support this.
|
My initial thought is for |
A use case to consider: What happens when a bundle is both installed nested and hidden by a bundle and installed by the user directly (and vice versa)? Two key design pivots come to mind:
Some user experience questions that are interesting (or irrelevant) based on answers to the above questions: a. If a bundle is installed hidden then installed directly does the ARP entry appear? |
That means that for (b), the bundle is not removed.
|
That was my guess as well, which I think means if the bundle is installed hidden, then the end-user installs it directly the BA will fail or succeed (whatever its behavior is) and hopefully indicate to the end-user that the bundle is already installed. I asked the question to understand if there would be an indication in ARP that the bundle is installed. If not, it would be easy for the end-user to be frustrated because it would appear the bundle is not installed even though it indicates it already is installed. Similarly, is the bundle visible in ARP after installing the bundle directly then installing the bundle nested+hidden then uninstalling the bundle directly from ARP?
Does the nested bundle get a reference from the parent bundle and its own reference count if the nested bundle is installed visibly? |
I don't understand "then the end-user installs it directly". This won't happen. The user will get the modify screen for most BAs. The bundle is not installed multiple times regardless of the order between nested and directly. This is the premise I'm questioning. |
Riiiight, of course. Updated questions with that in mind:
|
|
For the initial implementation (not intended to be final, just the least amount of code) this is how it works:
If a parent bundle does actually run the bundle nested (Repair, ForcePresent) then it will get hidden.
|
The general rule of thumb is that child packages which are installed as part of a product should be hidden in Programs & Features, and all anyone should see is the thing you installed.
In the case of MSI packages, the bundle achieves this by passing
ARPSYSTEMCOMPONENT=1.
Now, if one of the child packages is itself a burn package, the same logic should apply. The host bundle should pass -embedding (or whatever) and the child package should not add itself to the ARP.
The text was updated successfully, but these errors were encountered: