Visual Studio 2010 Ultimate: Setup Project - Merge Modules?

I found out (through the grapevine) that I needed to build a Setup Project for my application, and in the process of putting all the pieces together I discovered something called  a "Merge Module" described by Visual Studio 2010 as "an install module for shared components".

Interesting.  My project contains no fewer than four shared modules: a database connectivity module, a cryptographic module, an external machine interface module, and a custom control.  By their very nature they can be included in more than one project, and are considered (by that definition) as 'Shared Components'.  But would I need to somehow build MSM files for each of them and (somehow, I'm not really sure yet) add them to my final Setup for this application?

Or am I reading too much into all of this?

You see - I figure that as time goes by, the Machine Interface Module will most definitely grow, yet remain backward-compatible if for no other reason than that's how I operate.  So it is distinctly possible that another install may utilize a higher version of that Module and install it [in place of]/[over] the previous version --- which is okay for our purposes.

Or will it?  Will it install a local copy for the application and move forward?  I'm not sure, and I don't want to shortcut the process "in the now" causing heavier complexity to other (installed) projects "in the future".  (Does that make sense?  I sure hope so...)

I envision the installation of each of these modules as re-usable library (or in one case Control) types, openly accessible to other projects as well.  But I'm not quite "getting it" where constructing Merge Modules and installing shared components is concerned.

Am I over-complicating matters, or is this something that I should "take the bull by the horns" and learn for the sanctity of further projects down the road, even before they are developed/realized?

Thanks for your views, understanding and guidance,

- The Lurking LongFist
Who is Participating?
Jacques Bourgeois (James Burger)PresidentCommented:
It depends on what your "shared modules" needs as far as installation is concerned. And shared modules do not install separately. They install as a subinstallation inside of a setup project, so they are useless for standalone installation of an updated dll.

A merge module is also useless if your modules compile as a single .dll or .exe file and not not use any extras that are not already part of the framework.

I think that the best example of the usefullness of merge modules is the framework itself.

In the first years of .NET, when the framework was not installed along the operating system, users needed to install the framework prior to using a program developed in .NET. The user thus had to perform 2 setups, one for the framework and then the setup for the application.

So Microsoft provided us with a merge module of the framework. This was simply the whole setup of the framework, in a merge module format. If you wanted to install the framework at the same time that you installed an application, you simply included the Merge module in your application Setup project, and both the framework and the application were installed from a single setup as far as the user was concerned.

The only time I needed to create a merge module for one of my own assemblies in my 13 years of working with .NET was for a dll that needed to be deployed with an Access .mdb file. When programmers used the dll to in their own application, they most often forgot or did not know that they needed to install the .mdb alongside the dll. Or they did not install the .mdb in the proper directory and the dll did not find it upon execution. By providing a merge module, we insured that both the dll and the database were installed, and in the correct locations.

Also, be aware that the Setup system used in Visual Studio 2010 is no longer supported in 2012. Since you work like a pro and think beforehand of the future of your assemblies, you might consider using an InstallShield LE setup project instead of the Visual Studio Installer. InstallShield is the only one provided with VS2012. Because I have moved all my deployments to ClickOnce, I have not used it and cannot say what InstallShield is worth or whether it supports merge modules. But I am told that its use is very similar to the VS setup mechanism. And upgrading to the full version of InstallShield should be very easy should you ever need to do so.
LongFistAuthor Commented:
So we've abandoned the "shared component" ideal - which worked, by the way - and returned to the DOS methodology of dumping all the source and supporting files into the same installation folder, and keeping insular copies of everything.  Good thing drive space is inexpensive.

Looking into various installer options before we move (eventually) to VS2012 - thanks for the heads-up.

Thanks again for your time and patience!
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.