Merge Module Creation Criteria?
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?
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
Answers (5)
Please log in to answer
Posted by:
ghosh.kunal
14 years ago
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.
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.
Posted by:
anonymous_9363
14 years ago
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.
Posted by:
happyphunn
14 years ago
So no need to worry that these files are not being installed to a "common" directory....???
Posted by:
anonymous_9363
14 years ago
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.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.