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
Comments
|
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. |
Burn treats all packages the same; nothing distinguishes between prerequisites and "real" packages. |
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. |
This issue is asking for more control. That is why it is flagged as a Do you want to implement it? If so, start here: http://wixtoolset.org/development/wips/0000-wix-improvement-proposal/ |
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:
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:
I will try to feed my findings and a possible solution into an improvement proposal. |
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. |
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. |
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. |
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. |
This issue includes many linked discussions and issues that all will have separate solutions, so I'm breaking this up.
|
Follow up from this thread :
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/NET-Prerequisite-Burn-and-the-ARP-td7600376.html#a7600382
The text was updated successfully, but these errors were encountered: