0

We have a unique requirement to create an msi using wix,the catch is that the msi must support multiple instance installation. User should be able to use the msi to install the product more than once on a particular system, so in order to achieve this we should disable repair mode and upgrades in msi, so literally each invocation of msi should be treated as fresh install.

Is the above requirement technically feasible with Wix? I am aware that having unique product code and package code for every invocation of msi will treat the installation as fresh install. Can this be achieved using a wrapper around the msi?

Santhosh
  • 671
  • 12
  • 36

2 Answers2

0

Before sending you to the MSI SDK I should add that I dislike this instance transform concept myself, and have not used it in practice. It might be that I have become a grumpy old man! :-).

MSINEWINSTANCE: Please investigate the MSINEWINSTANCE property and read up on the MSI SDK topic: "Installing Multiple Instances of Products and Patches". And here is perhaps a better example - more practically oriented.

Also some context on why I am not too keen on this feature. Carolyn Napier was on the original MSI team - this is straight from the horse's mouth as they say.

I know some people claim success with these instance transforms (Chris Painter might be able to illuminate my claims here), but I'd rather virtualize in scenarios such as these. Please see this age-old post from serverfault.com: I want to install an MSI twice (please skim all the other answers in that "thread" too).

APP-V: I have almost zero App-V experience, but my guess is that this is what you should try to convince your manager to spend some time on investigating. Maybe call in some favors and talk to guys who are operative in current deployment. They always have the current prevailing prejudice to report - with the tricks that make things work in the real world.

Great if you can let us know how you end up solving the problem.

Disable Repair & Modify: And for the record: disabling repair and modify (buttons only) can be done by setting the ARPNOMODIFY and ARPNOREPAIR properties. But this is not what you are looking for to allow multiple instance installations. MSI is not easily fooled and knows what you have installed and when - no reason to waste time testing these "options". All these two properties do is to hide or disable the modify and repair buttons - yields nothing you need apart from that.

Stein Åsmul
  • 39,960
  • 25
  • 91
  • 164
  • The documentation for ARPNOREPAIR doesn't disable repair, it just hides the button in the Programs-Features etc, as the docs say. – PhilDW Apr 12 '18 at 20:03
  • Yes, I am already stating that I think. Maybe I didn't make it clear enough. Can I ask what your take is on instance transforms? Do you use them? I am asking of the impossible one sentence summary :-). – Stein Åsmul Apr 12 '18 at 20:18
  • Stein, your text says "disabling ... repair...." can be done by setting the ARPNOREPAIR property. It doesn't do this - it merely hides the explicit button, and I'm sure you know repairs can occur spontaneously sometimes. So yes, it could be phrased a little different, but I can be overly obsessive about wording. – PhilDW Apr 12 '18 at 20:25
  • OK, I have bolded the section at the bottom where I state that the properties merely disable / hide buttons. And also modified the link that you read at the top - I added "(buttons only)". No problem on the wording - happy to receive feedback. Hope it is clear now. – Stein Åsmul Apr 12 '18 at 20:45
0

You could do this with a wrapper around the MSI. In general your wrapper program would start with the base MSI, alter the ProductCode and PackageCode using the Windows Installer APIs, copy this MSI to a location on the system then install it from there.

I say "copy and install" because it's futile trying to disable repair - it's too baked into the architecture of Windows Installer. If you have each separate MSI product cached somewhere then repair will work using that unique MSI, and it also means that you could modify as well. Repair is too unpredictable to completely prevent. Any shared files can trigger repair from other installed products that share them. What do clients do if they accidentally delete files or registry entries? And there's this about keeping the source MSI available, although the list of reasons doesn't come with a lot of explanation, Rule 31:

https://blogs.msdn.microsoft.com/windows_installer_team/2006/05/24/tao-of-the-windows-installer-part-3/

There are a lot of other issue that aren't mentioned, so it's not clear if you care about patches and maintenance in general, about multiple entries in Programs/Features (that you could suppress, but how do you uninstall?) and so on. It's also not clear that each of these separate installs don't conflict with each other in any way, such as common files/registry entries, service names, files being installed in the same location with the same name.

PhilDW
  • 20,260
  • 1
  • 18
  • 28