Jump to content

This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.

Historic Nested Woes

1 reply to this topic


  • Full Members
  • 1 posts

Posted 19 November 2009 - 11:40


I have taken on a project that creates some 20 odd MSI files and using a post build step for the installer creates CustomAction..23 & 39 queries allong with InstallExecuteSequence entries. My problem is that installing this takes a very long time because of the 100,000 odd files spread across the MSI files and upgrading is going to be a nightmare.

Bacause of the inherent problems with the nested installs it will not allow me to upgrade just 2 or 3 of the 20 odd MSI files; instead the system wants me to uninstall and reinstall the whole lot... This is where the problem arises. Most customers have this installed on laptops because they require the portability due to the nature of the project. A typical uninstall & reinstall will take upwards of 6 hours because of the amount of files - about 100,000.

Currently the whole build and build of setup is done in Visual Studio 2005. Visual studio install kits are a bit of a nightmare for this project because it is for both PCs and PDAs and has a multitude of supporting DLLs - content management and excludes take up far too much time in the build process.

I have started looking at Wix where I would be in control of the whole thing through XML and like the simplicity of that but that requires a whole lot of work up front to get things right and would exclude me from an upgrade from the original to the new setup.

Recognising that the original coders did not think of these things to start with, what would be your suggestion(s) for:
a. A smaller upgrade than re-installing
b. A product that would allow for better installation control in the future.

I have read that WI 4.5 allows for better transaction control but have not found anything about how to build a multiple MSI install kit using that yet... Would I need to upgrade to a later version of Visual Studio to get things working or is it still going to me manual hard labour :-)

Thanks in advance


  • Full Members
  • 436 posts

Posted 19 November 2009 - 12:15

QUOTE (chawbs @ 2009-11-19 11:40)
I have started looking at Wix <snip> and like the simplicity of that but that requires a whole lot of work up front to get things right and would exclude me from an upgrade from the original to the new setup.

Well, there's no such thing as a free lunch. I've never really got into Wix but I know one of the active chaps on the Wise Application Packaging froum Symantec's Connect (his "nickname" is 'EdT') is a big fan. You may want to converse with him.

I'm not sure why you say that using it would exclude you from an upgrade: if all the ProductCodes and such remain the same, running a new setup would result in no changes, since the WI information would already be present, as would the files and registry data. As you know, WI is reasonably intelligent and wouldn't install stuff which is already present.

In the past, I've used a scripted approach, where the script reads an INI file. It controlled the post-Windows build process for a software house's test servers: SQL Server, XML Parser, IIS, BizTalk (plus arms-full of BT configuration), followed by whichever of their products was to be tested. The beauty of that route is that the script can test the installed state of products using the WindowsInstaller.Installer object's ProductState property. If it's already installed, the script has no work to do and skips to the next product in the list.

You may want to look at something simpler, say, using a stub executable which simply calls the MSIs in sequence.

Edited by VBScab, 19 November 2009 - 12:15.

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.