I am trying to switch our huge setup program into manageable, resuable merge
modules. After doing a little reading and a little experimentation, I am
still confused as to the best approach.

Consider this organization. I have some core standalone merge modules M1,
M2, M3 (most are managed assemblies that get deployed to the GAC, some are
native DLLS. I also have some "middle level" merge modules MA, MB, MC that
depend on M1, M2, M3 and add a little more. Finally there are different
product packagings for which I want to create different setup programs: S1
= MA+ MB, S2=MA+M3, S3=MB+M3, etc.

Here are some of my questions:
1. If merge module MA depends on merge module M1, should I aggregate M1
into MA or just bring the necessary modules together in the top-level setup
programs?

2. If a setup program includes two merge modules MA and MB that both include
the same version of the same managed assembly, will it install and uninstall
cleanly in the file system and the GAC, or is there potential for conflicts
and confusion?

3. If two different setup programs (for different products) include the same
merge module M1, will both install and uninstall cleanly in the file system
and the GAC, or is there potential for conflicts and confusion?

4. If I have built an installer class with some custom actions required for
merge module M1, can I put the installer and custom actions into the merge
module M1 or should I always do this at the top level?

5. Is deployment support in VS.NET changing significantly in Whidbey?

Thanks!!!

[quoted text, click to view]

Thank you for you answers,, which were very helpful. I think I was not
clear on what I meant by "aggregate" in Question #1. I do have multiple
merge modules MA, MB that require the assemblies in module M1. When I
create my deployment project in MA, should I explicitly add M1 to the
deployment project for MA? Or should I just specify both MA and M1 in the
top level setup project S1?

Thanks,

Steve

Hi Stephen Walch,

Currently I am looking for some resource to help you on this issue. We will
reply here with more information as soon as possible.
If you have any more concerns on it, please feel free to post here.


Thanks for your understanding!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Stephen,

[quoted text, click to view]

This depends. If there are other merge modules that depend on M1, we may
separate MA and M1.


[quoted text, click to view]

I don't think there will be conflicts or confusions. Generally speaking, we
may avoid this scenario if possible.


[quoted text, click to view]

There should be no conflicts or confusions under normal situations.


[quoted text, click to view]

There are many existing merge modules with their own custom actions. I
think it is OK for you to put custom actions in merge modules. However, the
conditioning of the custom actions in the merge modules may be a more
complex subject.


[quoted text, click to view]

From the current preview version of the product, there are no significant
changes. However, we shall see the final release of the product.


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.

Hi Steve,

[quoted text, click to view]

Just specify both MA and M1 in the top level setup project S1 is OK to your
scenario.


Thanks!

Best regards,

Gary Chang
Microsoft Community Support
--------------------
Get Secure! ¡§C www.microsoft.com/security
Register to Access MSDN Managed Newsgroups!
http://support.microsoft.com/default.aspx?scid=/servicedesks/msdn/nospam.asp
&SD=msdn

This posting is provided "AS IS" with no warranties, and confers no rights.