SHould we choose Microsoft dlls for merge module ?
Hi ,
I am slightly confused , For an application should we create merge modules for Microsoft supplied COM components which go to shared location ?
In my current project we ignore any file which is a COM component , goes to a shared location and has application vendor as Microsoft . I feel this should not be a case , using the same criterion of COM component , shared location and a valid vendor name we decide to create merege module , but for some reason we do not apply that to Microsoft files .
Any suggestions will be of great help .
Cheers ,
V
I am slightly confused , For an application should we create merge modules for Microsoft supplied COM components which go to shared location ?
In my current project we ignore any file which is a COM component , goes to a shared location and has application vendor as Microsoft . I feel this should not be a case , using the same criterion of COM component , shared location and a valid vendor name we decide to create merege module , but for some reason we do not apply that to Microsoft files .
Any suggestions will be of great help .
Cheers ,
V
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
kkaminsk
18 years ago
What COM components are you creating merge modules for? I generally avoid making merge modules for vendor supplied components. Also Microsoft provides modules for serveral commonly used components.
Posted by:
viv_bhatt1
18 years ago
I am considering only applications which are repackaged .
For e.g: Any application XYZ which has a file MDT2DD.dll which has destination as \\COMMONFILESFOLDER\Microsoft Shared\MSDesigners98\
Now as this file is a COM file and also goes to a shared location is a potential candidate for merge module but as the vendor for this file is Microsoft we remove this file from merge module list .
My question is : Should we include such files also for merge modules as they are no different from other files except they are Microsoft supplied ?
I hope I have made it clear this time .
Cheers ,
V
For e.g: Any application XYZ which has a file MDT2DD.dll which has destination as \\COMMONFILESFOLDER\Microsoft Shared\MSDesigners98\
Now as this file is a COM file and also goes to a shared location is a potential candidate for merge module but as the vendor for this file is Microsoft we remove this file from merge module list .
My question is : Should we include such files also for merge modules as they are no different from other files except they are Microsoft supplied ?
I hope I have made it clear this time .
Cheers ,
V
Posted by:
kkaminsk
18 years ago
Unfortunately that might be a bad example. I think the designer file you are using exists in the VBA SDK. I would confirm it but I don't have the VBA SDK merge modules with me.
But aside from that if you are taking the time to make merge modules from other vendors I don't see how Microsoft supplied shared components should be an exception unless Microsoft supplies a valid merge module.
But aside from that if you are taking the time to make merge modules from other vendors I don't see how Microsoft supplied shared components should be an exception unless Microsoft supplies a valid merge module.
Posted by:
viv_bhatt1
18 years ago
Are there any links available where Microsoft updates the latest merge module release ?
OR
How do I find if the there is any merge module available for Microsoft COM component .
Our exisiting baseline merge module library is not comprehensive .
Cheers ,
V
OR
How do I find if the there is any merge module available for Microsoft COM component .
Our exisiting baseline merge module library is not comprehensive .
Cheers ,
V
Posted by:
kkaminsk
18 years ago
http://www.installsite.org/pages/en/msi/msm.htm is a good starting point but honestly I've used Google to try and find vendor merge modules.
Posted by:
viv_bhatt1
18 years ago
Thanks . I could locate a couple missing from our library .
Cheers ,
V
Cheers ,
V
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.