Deployment using Marge Module

14 במרץ 2010

2 comments

Deployment using Marge Module

 

I was asked by one of Sela’s customer’s the following question:

 

We’ve developed two add-ins, each one has it’s own setup project
ad we’d like to include them in one MSI.

It didn’t take very long to come up with an answer: “Use Merge Module

 

So, What is Merge Module?

Let’s say you have an application that is consists of multiple assemblies (Isn’t 
it the case most of the time?) . Deploying the application by one setup project
is a common scenario and most of the time it will suit you best. But what happens
where more than one assembly is independent and has to perform  some
installation logic?

 

If it wasn’t for Merge Module we would have been forced to do one of the following:

1. create different  Setup project for each assembly and run them all manually or  
automatically by some manager program, or even a batch file.

2. Add all independent assemblies to the output folder and add their custom actions 
    to the various installation events.

However, we can have Merge Module for each assembly. This project has what
regular setup project has minus the user interface and launch conditions, 
It means that we can have your own custom actions for custom actions .

After having  our merge modules ready we can simply add them to our installation
project.

 

OK – But is it better than simply add our project outputs to one deployment project?

Well, Keeping in mind adding the custom actions (if needed) also,
it is technically almost the same. However, the advantage or Merge Module comes
when wishing to reuse it. Packing the same assembly in various setup projects is much
easier in Merge Module than repeating your actions over and over. (Sounds like reasoning
code reuse, isn’t it?)

 

To sum up

Merge Module enables as to encapsulate components installation inside our application setup.
It is also enables us reusing it for various installation packages.It is not in use very often but
it sure can be helpful in many cases, Including our customer’s case.

kick it on DotNetKicks.com

Add comment
facebook linkedin twitter email

כתיבת תגובה

האימייל לא יוצג באתר. (*) שדות חובה מסומנים

תגי HTML מותרים: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>

2 comments

  1. Jasper15 במרץ 2010 ב 10:21

    You should make a 'warning' section on the bottom that you loose all reflection based methods if you merge assemblies. I mean – you will catch an exception if you use GetType() or GetMethod() via reflection of some of your assemblies after merge.

    Just my 2 cents

    להגיב
  2. Ran Wahle15 במרץ 2010 ב 11:34

    Thanks Jasper.
    If "Merge Module" was about merging assemblies you were of course right. However, it does not.
    Assemblies on "Merge Module" project are being put together in a .msm file which is similar to .msi cannot run on it's own.
    This means that like .msi files, it has assemblies (one or more) inside that will be put on the run-time directory separately after installation.
    Therefore, no reflection capability is lost because the assembly structure is kept in tact.
    Note: "Merge Module" is not about adding module files to an assembly. This is something else.

    להגיב