Visual Studio Merge Modules vs. InstallShield Merge Modules

[Holger_G]

Hi.

What is the recommended method to create merge modules for shared components to use with Basic MSI projects?

We have a lot of shared DLL and filter files (halfway COM) that must be shared between different products. So we have to create a lot of merge modules to share those components between Basic MSI projects.

How should we create those merge modules?
Using Macrovision or using Visual Studio (using the Setup Package project type for existing projects).


Please let me know your experience and suggestions.

Thanks,
-Nick

[Holger_G]

What do you think?

[#3]

Being 100% fully bias, I would always suggest InstallShield over other products 😛

But to be honest, you can avoid a whole realm of compatibility issues and bugs by creating your merge modules within InstallShield.

[Christopher_Pai]

I have a ton of experience in this area, and there actually are some things that VDPROJ does well, but mostly it just sucks.

The thing it does nice is the ability to bulk import a directory tree and make every file a keyfile. This can be useful when you have a tree of non-versioned files ( think website or support files ) and you want to be sure each one will be properly upgraded during a minor upgrade without worrying about which one is the `key` file. Unfortunatly there is no way to turn this off because VDPROJ doesn't express the concept of `component`. For example, every registry key becomes it's own key resource of it's own component. I won't even mention how many times I have been pulled into an integration lab with people staring at the `please wait while App repairs itself...` screen. Ugly.

Then there is the problem of not being able to tell VDPROJ to NOT scan for .NET dependencies of assemblies. You have to open it up on your dev box, hope all of the dependencies were found and manually exclude them. Then you have to hope no other dependencies are found on your build box otherwise they get included as module dependencies. We actually wrote a program that automated this process on the build box, deperatly trying to get around the problem.

Then there is the problem that VDPROJ can't actually do alot... Define and start a Service? No. Create Non-Advertised Shortcuts? No.... IIS Websites? No.... XML Changes? No..... But it does do Installer Class Custom Actions!!!! ( YUCK )

Did I mention that VS2005 VDPROJ won't even author the directory table correctly? It's missing the .: before Module Retargatable folder. Even if you tell IS to associate Module Retarget to INSTALLDIR it still won't work without some preprocessing of your MSM's to resolve this problem.

Then there is the fact that .VDPROJ isn't even a fricking MSBuild file. So if you are using TFS/MSBuild it won't work. You'll have to install VS2005 on your build box. Then there is the problem that VDPROJ is really, really slow at building.

I know I'm forgetting a lot, so I'll just say coming from someone who did `Asset Based Product Line Development` ( which is a fancy way of saying I know a whole lot about code reuse via source control, build automation and installs 😞

Friends Don't Let Friends VDPROJ

Unfortunatly, there isn't an ideal tool out there yet. But as it currently stands, IS Basic MSI and IS Merge Module is the best. But you'll have to do advanced techniques like use cutom table data in your MSM and enterprise CA patterns in your Basic MSI to really get the flexibily you need. For some reason InstallShield just refuses to do certain things in their MSM like IIS configuration.

[Holger_G]

Thank you guys, especially Christopher 🙂

[Christopher_Pai]

Oh ya, I forgot to mention.... VDPROJ deferred CA's automatically ( and exclusively ) use Impersonation.... so forget about them working on Vista with UAC unless you write yet another post-build massage script like this:

http://blogs.msdn.com/astebner/archive/2007/05/28/2958062.aspx

[chrisselnes]

Thanks for sharing your knowledge with us Christopher. You mentioned that vdproj deals well with a tree of unversioned files and I was hoping that you could share with us what the best way to deal with this scenario using an InstallShield basic msi project.

Our doc team went to this type of technology for our all of our help files and I have just found out about it. When I first started doing installers I used dynamic file linking (on a much smaller scale than I am now faced with) but dynamically linked file had definate issues with patching. The last couple of years I have just been creating dummy exe key files for components and then adding the non versioned files to the component. This seems to have solved the issue of files not getting updated correctly.

Now I am faced with literally about 70 different levels in all with hundreds of files so I can see I need to find a new way of dealing with this to make sure all files are updated when using a patch. Thanks for anything you can offer.

[Christopher_Pai]

All I can share with you is a user story that I've shared with Macrovision, InstallAware and the community in general:

http://blog.deploymentengineering.com/2007/06/dealing-with-very-large-number-of-files.html

Currently, there really isn't a perfect tool for describing what we need. Sorry.

[chrisselnes]

Thanks Christopher. I completely agree with your conclusion and right now I am really feeling Allan's pain. For anybody else who might read this, Allan talks about the fact that it was suggested that each file have it's own component and obviously the file would be the key file for that component. This works great if you have all versioned files but it gets really tricky when you are working with non-versioned files, like is the case in most of these scenarios.

I received this same suggestion from InstallShield a few years ago and unfortunately learned a very hard lesson about how non-versioned files get updated in the update process. Our app has a large number of xml and other non versioned files and the one file, one component suggestion I received seemed to be a good solution, if not a little tiresome. I felt very comfortable because the suggestion came from InstallShield so I didn't feel I needed to investigate it any further. I paid a pretty big price for that assumption.

Well, we sell different localized versions of our software, as many people do. Our two different sales channels are retail stores and direct web site sales. It is not uncommon for our users to have two different localized versions installed and of coarse, many non-versioned core files were shared.

The problem occured when a newer version of one of the products was bought from the website and installed and then a different localized copy was bought later through the retail channels. The retail channel is significantly slower in getting new boxes on the shelf because they want to sell the old boxes first. I know, how unreasonable!

Anyway, what happened was, our developers were copying the old xml file, pasting it into a new file, changing a few things, saving the file with the old name and then checking that file in. This left the created and modified dates of the new file the same.

After the first install, an older localized version was installed and because of the non-versioned file updating rules (http://msdn2.microsoft.com/en-us/library/aa370531.aspx) the new file would actually be replaced by the old file because of the fact that the new xml file's created and modified dates were the same. And as you can image, all sorts of fun things started to happen.

Sorry, that was a long explanation but I was just trying to emphasize how tricky this every file as a component notion can become and to second Christopher's idea that we really need a tool to deal with this issue. Thanks again for your input Christopher.

[Christopher_Pai]

I don't know if I blame this on 1:1 keyfiles though....... companion files probably wouldn't have helped a whole lot unless you did something like have fake DLL's to act as tracking agents and had all other files as companions. It's really a problem with an interaction of costing and sharing resources/components across multiple products. Maybe some sort of AppSearch/LaunchCondition would have been helpful in restricting the transaction to known compatible packages.