Hello all,

Ok...so I have noticed that there are some files (dll's and .NET Assemblies) that our application development team has been including in different packages that install or that multiple packages utilize. The problem is they are very sporadic in their inclusion in every package and when they do they do not keep component GUID's the same.

So clearly there are issues when package A gets removed and Package B, which needs a file or 2 from package A, is now broken.

My question is, do I make a Merge Module out of these files and reg keys and include them in all these packages, or simple match the component GUIDs. The files, unfortunately, are not installing to System32 or Windows. They are installing to a path in Program Files.

Thoughts?
0 Comments   [ + ] Show Comments

Comments

Please log in to comment

Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

Answers

0
I think the standard and the best way would be to go with Merge Modules so that you have consistent GUIDs for a set of files in all your applications.

Right now I Admin Studio and that process of replacing a file with its merge modules is kind of automated in the Admin Studio. But in my earlier project we did create merge Modules for our applications. We in fact built a repository of a large number of Merge Modules which we were using everyday in our applications. I have to say that process can be quite tedious because every time you get a new version of a particular DLL file, you had to create a new Merge Module, not sure if it makes sense, but I feel automation is the best way to go about it.

With regards to criteria, we checked for files that belonged to a vendor other than the vendor of your Application. For example if you are packaging a Nortel Application and you got DLLs from Microsoft. We would look for such DLLs that get installed other than the Application directory (C:\Program Files\Nortel). The most common locations where we would look for these DLLs were C:\Program Files\Common Files, C:\Windows, C:\Windows\System32 and C:\Windows\System. Then we would check if these DLLs are already present on your packaging image, and if they got updated. Things like that, and then we went ahead with the process of creating Merge Modules.

Hope this helps.
Answered 09/13/2009 by: ghosh.kunal
Senior Yellow Belt

Please log in to comment
0
My question is, do I make a Merge Module out of these files and reg keys and include them in all these packagesYes. A no-brainer.
Answered 09/14/2009 by: VBScab
Red Belt

Please log in to comment
0
So no need to worry that these files are not being installed to a "common" directory....???
Answered 09/14/2009 by: happyphunn
Senior Yellow Belt

Please log in to comment
0
It doesn't matter where they're targetted. If they're common to a bunch of your applications, a MM makes perfect sense. You see this quite a lot in vendor MSIs.
Answered 09/14/2009 by: VBScab
Red Belt

Please log in to comment
0
awesome!!! Thanks!!! This will make life soo much easier.
Answered 09/14/2009 by: happyphunn
Senior Yellow Belt

Please log in to comment
Answer this question or Comment on this question for clarity