1

I am building a bootstrapper using WiX toolset (my first). It is for an add-on package for the Microsoft Flight Sim family. There are several versions of MFSF and customers often want to install our add-on package into multiple simulators. This naturally means installing many of the same files into multiple different root directories. I know I can easily choose ONE root folder by passing a property from the bootstrapper to the MsiPackage. But is there a way to get the package to install to multiple root folders?

My title is perhaps slightly misleading - running the same MSI twice may well be a massive no-no. I'm really asking what is the best direction I can take to install a group of files to multiple user-selected locations, without including them multiple times in my bootstrapper?

Thanks Farley

lequinne
  • 118
  • 8
  • You definitely can't run the same MSI twice - it will go into maintenance mode, not a fresh install of files. How many different flight simulators do you support? – PhilDW Apr 09 '18 at 20:37
  • Four. They all consist of some files that get installed to the same place for all versions (I am installing these once through a separate MSI in the bootstrapper), some files that are different for each version, and a large number that are the same files for all versions, but need to be installed to each of the four sim directories. Right now I'm simply using a different MSI for each version which includes all the files which go into the sim directory, both version-dependent and shared files, but this results in an extremely large installer, and I figure there has to be a better way. – lequinne Apr 09 '18 at 21:16
  • Are the files the same just different directories? – Christopher Painter Apr 10 '18 at 01:57
  • @ChristopherPainter Affirmative. same files, same directory tree structure, distributed to 1-4 different locations (root directories) during install. – lequinne Apr 10 '18 at 04:38

1 Answers1

1

This sounds like what I have to do in my IsWiX installer to integrate with Visual Studio. I have a bunch of files that need to be installed into every detected version of VS. To do this I:

1) Author AppSearch to set properties with destinations.

2) Create components and install to my directory. These aren't ever actually used by anything but it's harmless.

3) Use CopyFile elements to duplicate the files to the destinations. If AppSearch didn't find a destination then the duplication is implicitly skipped by MSI.

https://github.com/iswix-llc/iswix/blob/master/Source/Installer/IsWiX/Code/Product.wxs

https://github.com/iswix-llc/iswix/blob/master/Source/Installer/IsWiXNewAddInMM/IsWiXNewAddInMM.wxs

Christopher Painter
  • 54,556
  • 6
  • 63
  • 100
  • Sounds like exactly the same problem, I will try out your method and let you know. Thanks! – lequinne Apr 10 '18 at 19:27
  • It has been forever since I used this feature, but as I recall MSI will even remove the duplicated files on uninstall - provided the hosting component is being uninstalled during the uninstall. This should be a good solution I think, but a lot of work for you to test. Best of luck. If the package is huge to compile, maybe try to use uncompressed, external source files or external cabs to speed up the compilation process? (I have never tried uncompressed files with WiX, but it should be easy to do). Alternatively, if you have huge binaries replace them with tiny test files during setup testing? – Stein Åsmul Apr 10 '18 at 23:32
  • Sure, it'll remove them. I've used this pattern extensively since 2008. There's very little to test. – Christopher Painter Apr 10 '18 at 23:52
  • Thanks for verifying Chris - so many things that I haven't used recently. With regards to testing; I was thinking about the different combinations of how many products are installed at a time. There are some permutations, but you are right, not the worst test problem. I guess it depends how big the products are to install. If they are big I hope the OP has some QA guys to get busy helping to share the tedious testing. Big packages are never fun with the long turnaround time. – Stein Åsmul Apr 11 '18 at 00:05
  • I don't see anything in his question that says its a big package. I also don't see how many files he has to install. My pattern isn't that great at scaling... it was only designed for a handful of files. – Christopher Painter Apr 11 '18 at 02:15
  • I was referring to one of the OP's comments: _"...this results in an extremely large installer, and I figure there has to be a better way"_. I figured a couple of tricks for dealing with large installers could also help. – Stein Åsmul Apr 11 '18 at 13:19