Skip to content
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

Closed
wixbot opened this issue Jun 24, 2014 · 12 comments · Fixed by wixtoolset/wix#162
Closed

Allow burn packages to be hidden in the ARP #4454

wixbot opened this issue Jun 24, 2014 · 12 comments · Fixed by wixtoolset/wix#162
Assignees
Milestone

Comments

@wixbot
Copy link

wixbot commented Jun 24, 2014

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.

Originally opened by jdluk

@wixbot
Copy link
Author

wixbot commented Jun 24, 2014

Originally changed by jdluk
Release changed from v3.8 to

@wixbot
Copy link
Author

wixbot commented Jun 26, 2014

Has to be opt-in.

Release set to v3.x

@wixbot
Copy link
Author

wixbot commented Jun 26, 2014

Type changed from Bug to Feature

@wixbot
Copy link
Author

wixbot commented Jul 2, 2014

@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.

Originally posted by jdluk

@wixbot wixbot added this to the v3.x milestone Dec 20, 2015
@rseanhall rseanhall self-assigned this Apr 1, 2022
@rseanhall rseanhall modified the milestones: v3.x, v4.0 Apr 1, 2022
@rseanhall rseanhall added this to To do in wix.4.0-preview.1 via automation Apr 1, 2022
@rseanhall
Copy link
Contributor

My initial thought is for BundlePackage/@Visible to be added similar to MsiPackage/@Visible. Although this one would default to yes for Permanent="yes", which could arguably be done for both package types.

@robmen
Copy link
Member

robmen commented Apr 2, 2022

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:

  1. What is the reference count on the bundle?
  2. If/when does the bundle appear/disappear in Add/Remove Programs?

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?
b. If a bundle is installed directly then installed hidden then uninstalled directly, is the bundle removed? Does the ARP entry disappear?

@rseanhall
Copy link
Contributor

  1. This is already resolved. This is what I was asking about with the parent switch yesterday. Installing the bundle directly (no -parent switch) causes the bundle to register itself as a dependent (ref count 1). Installing the bundle as a nested bundle (-parent <parent bundle id>) prevents the bundle to register itself as a dependent and instead registers the parent as a dependent (ref count 1).

That means that for (b), the bundle is not removed.

  1. The premise is questionable. Most BAs will not run Install again, and I wouldn't expect any of the other operations to change the visibility. When run as a nested bundle, the parent bundle will just register themselves as a dependent and not run the bundle. This is how it works with MSIs as well.

@robmen robmen added the triage label Apr 2, 2022
@robmen
Copy link
Member

robmen commented Apr 2, 2022

The premise is questionable.

2. wasn't a premise, it was a question. :)

Most BAs will not run Install again, and I wouldn't expect any of the other operations to change the visibility.

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?

When run as a nested bundle, the parent bundle will just register themselves as a dependent and not run the bundle.

Does the nested bundle get a reference from the parent bundle and its own reference count if the nested bundle is installed visibly?

@rseanhall
Copy link
Contributor

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.

@robmen
Copy link
Member

robmen commented Apr 2, 2022

The user will get the modify screen for most BAs.

Riiiight, of course. Updated questions with that in mind:

  1. If the user clicks update or repair in maintenance UI after attempting to install a bundle directly does the bundle add a reference to itself? Would ARP be added?
  2. Is the bundle visible in ARP after installing the bundle directly then installing the bundle nested+hidden then uninstalling the bundle directly from ARP?
  3. Does the nested bundle get a reference from the parent bundle and/or its own reference count if the nested bundle is installed visibly?

@rseanhall
Copy link
Contributor

rseanhall commented Apr 2, 2022

  1. Research is needed. I would expect it to add itself as a reference to itself.

  1. The nested bundle will never add itself as a reference to itself when run by a parent bundle as a BundlePackage. See parent switch above.

@rseanhall
Copy link
Contributor

For the initial implementation (not intended to be final, just the least amount of code) this is how it works:

  1. Yes, reference is added (this is how it always worked, no changes were made for reference counting). No, once it is installed hidden it stays hidden.
  2. The bundle is visible after initially installing directly. When a parent bundle then plans to install it as nested, it will only add a reference and not actually run the bundle. It will stay visible. When the parent bundle then plans to uninstall it, it sees that it has other references (itself), so once again it does not run the bundle and only plans to remove the reference. It will stay visible.

If a parent bundle does actually run the bundle nested (Repair, ForcePresent) then it will get hidden.

  1. This behavior didn't change. The nested bundle only gets a reference from the parent bundle when run as a nested bundle, regardless of visibility.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
No open projects
Development

Successfully merging a pull request may close this issue.

4 participants