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

Ability to install prerequisites without adding entry in ARP #4822

Closed
wixbot opened this issue Jul 10, 2015 · 11 comments
Closed

Ability to install prerequisites without adding entry in ARP #4822

wixbot opened this issue Jul 10, 2015 · 11 comments

Comments

@wixbot
Copy link

wixbot commented Jul 10, 2015

Follow up from this thread :
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Prerequisite-Burn-and-the-ARP-td7600376.html#a7600382

Originally opened by soundararajan

@wixbot
Copy link
Author

wixbot commented Jul 14, 2015

Release set to v3.x

@wixbot wixbot added this to the v3.x milestone Dec 20, 2015
@Danielku15
Copy link

I wanted to raise this problem again since it is currently quite a problem for us. Reason is that this becomes more problematic when a reboot is required due to the .net Framework installation. We currently face a similar issue to the one that is mentioned mentioned at this stackoverflow post: We install .net 4.6.2 on the target machine and it is quite common that a reboot is required due to this (from our observations). Then the system reboots and the setup starts again. The user can enter all details (installation directory etc.) but when pressing on install the installer fails.

Is somebody already working on this topic? I don't know the complexity behind creating the ARP entry but if it's only a simple call to an API it shouldn't be a big effort to introduce a setting which does not do this call during the prerequesite steps but only after the real software installation happened.

@barnson
Copy link
Member

barnson commented Oct 24, 2016

Burn treats all packages the same; nothing distinguishes between prerequisites and "real" packages.

@Danielku15
Copy link

Danielku15 commented Oct 24, 2016

I understand that this is the current behavior, but isn't this issue exactly questioning whether this behavior is always correct? The prerequisites are not really part of the application itself, even though they are part of the installer. When my .net application is uninstalled, WIX should also not uninstall the .net Framework since it is not directly part of the software package. Also from this perspective they are special.

I cannot guarantee that not our BA is to blame that the installation fails, there might be a event or status code that we handle wrong. But considering only the cancelling approach, it is, from user perspective, already wrong that a ARP entry is created for an application that was not installed.

There might be cases where this behavior is correct, that's why the suggestion in #4905 was that it becomes a setting where the developer can decide how it should behave.

@robmen
Copy link
Member

robmen commented Oct 24, 2016

This issue is asking for more control. That is why it is flagged as a feature for burn.

Do you want to implement it? If so, start here: http://wixtoolset.org/development/wips/0000-wix-improvement-proposal/

@Danielku15
Copy link

Danielku15 commented Oct 24, 2016

I digged a bit into the WIX Source Code trying to understand the current workflow of the prerequisite installation. Since I'm new to the WIX internal codebase I'm not sure if I can contribute to the WIX codebase in an appropriate soon. What I've got so far:

  • In case .net is not installed (GetAppDomain of the MBA host fails) the wixstdba project acts as fallback BA for the installation.
  • The wixstdba reads the xml definition and parses the prerequisite packages from it.
  • With the wixstdba as BA, it will only install the prerequisite packages as part of a normal installation procedure.
  • When the installation finishes a ARP entry is created as part of the prerequisite installation. (I haven't out so far where this is done)

If we want to consider the prerequisites as "out of installer"-packages that are installed separately before the normal installation starts, I see 2 design flaws in WIX:

  1. The WIX MBA host only considers .net as a mandatory prerequisite. If the .net AppDomain creation fails, the .net installation procedure starts by launching the wixstaba. If you want to treat other packages as prerequisites (e.g. Visual C++ Redistributable), a different mechanism for detecting missing prerequisites needs to be added. It must allow developers to create their own checks (e.g. via XML conditions).
  2. The wixstdba prerequisite installation behaves just like the normal installation process which makes the rest of WIX believe that a normal installation of the actual software happened. A new setting should allow changing this behavior to one of the following 3 possibilities:
    • Install prerequisites as normal application - This is the current behavior. The prerequisites will create an ARP entry named like the application itself.
    • Install prerequisites as separate prerequisite package - The prerequisites are installed as separate ARP beside the main application. The ARP could be named something like {{MyApplication}} Prerequisites beside the {{MyApplication}} main software package. (of course configurable for developer)
    • Install prerequisites silent - No ARP entry will be created for the prerequisites. It is up to the single prerequisite packages to create those if required. (e.g. .net will create an ARP for itself).

I will try to feed my findings and a possible solution into an improvement proposal.

@rseanhall
Copy link
Contributor

Currently, the Burn engine is doing the ARP registration as pretty much the first step in the Apply phase. Like Bob said, it has no concept of prerequisite packages or "the main software". The Burn engine was specifically designed without these things, so going in this direction of teaching Burn what a prerequisite package is or what "the real installer" is will require persuading us that we need to drop the underlying design goals discussed in Burn: Zero, one, or n and B is for Bundle.

On the other hand, Rob and I have already proposed that Burn should only register in ARP after installing the first non-permanent package. This does not require teaching Burn anything new, it only requires making it smarter about when it should register. I feel that this direction will require the least amount of code, though it might be tricky to make sure that all cases are covered since it made it very simple to always register in the beginning.

@Danielku15
Copy link

I've read through the blog posts and I think I understood your thinking behind the current approach a bit better. The main problem I see behind this thinking is that the prerequisites might be one of two types: Application prerequisites or Installer prerequisites. I agree that application prerequisites should be part of the normal installation chain and handled as part of the application. But installer dependencies are slightly different.

Imagine you wrote a custom MBA with .net 4.6.2 with a fancy WPF Gui where you call some native functions written in a Visual C++ 2013 DLL (e.g. for encrypting some information in a custom action). This makes the .net framework an Vc++Redist packages rather part of the Installer than part of the Bundle. And from there comes my thinking: Why should prerequisites show up as ARP entry in the control panel? This would mean that the installer itself was "installed" as my application, rather than my real packages.

@yial2
Copy link

yial2 commented Jan 30, 2018

Just want to follow up on @Danielku15 comment. My company happens to have the exact same requirement of "installer prerequisites" instead of "software prerequisite". WPF needs Visual C++ 2013 before even launching the WPF UI. Similar questions/feature request were also made before this.

ARP entry on .NET installation reboot is also an issue.

@robmen
Copy link
Member

robmen commented Jan 30, 2018

This issue is open and unassigned. That means it is waiting for someone to investigate the root problem, discuss possible solutions to that problem then implement the decided solution.

If you are interested in doing so yourself, our developer documentation provides a great checklist for getting started.

If you are not interested then you are waiting for someone else to become interested. If this issue has been open for a long time then there probably isn't much interest in this particular issue. In that case, you'll want to consider how to motivate others to fix it for you. This is a pretty good list of support options.

@rseanhall
Copy link
Contributor

This issue includes many linked discussions and issues that all will have separate solutions, so I'm breaking this up.

  1. I'm treating the core of this issue to be the title - the ability to install prerequisites without adding an entry in ARP. Mostly because many, many people have asked for Burn not to write the ARP entry in the first place. This is declined, and explained in the first ever declined WIP. Registering the visible ARP entry at the beginning of installing the bundle is required to meet the design goals of Burn.

  2. In-Progress ARP DisplayName #6296 is tracking the new feature intended to migitate the required ARP entry by allowing the name to be different before installing the first non-permanent package.

  3. Burn needs to do better at unregistering #6297 is tracking all the different scenarios where Burn should be able to tell that because none of the bundle's non-permanent packages are installed, it needs to uninstall itself either at the end of the chain or before closing if installation wasn't started. The most common scenario was where the preqba installed .NET, the managed BA was started, and then the user cancelled the installation.

  4. The prerequisite bootstrapper does not install prerequisite support packages on resume when prerequisite package initiates restart #4718 is tracking the ability to have installer prerequisites always installed by the preqba before the managed BA is started.

@rseanhall rseanhall removed this from the v3.x milestone Dec 11, 2020
@wixtoolset wixtoolset locked as resolved and limited conversation to collaborators Dec 19, 2020
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants