Deploying shared components
I have some problems with deploying shared components with MSI-packages.
I have several applications that use the same dll files. At the moment these files are unversioned. Each application has it's own setup project and as a result of this each shared component has several components codes (GUID:s). This causes each application to
uppdate the component with it's own version of the file. Sometimes components are updated backwards (BAD).
My first ideas to sove this:
1) Introduce a merge module which includes all the common components.
+ same component code for all files with same name and version
- Don't know how the file location is determined? Can I still control where the files are installed with variable.
2) Introduce additional MSI-package for common components
+ One project, one component code for each file version
- Could cause deployment problems if users don't remember to install this package.
3) Manipulate MSI packages with a VBScript after compile to have same GUID:s for each common component.
- Possible breaks self healing function and check sum that is calculated for each package.
- Not sure if this works.
Any suggestions or ideas how to solve this problem elegantly? Thank you.
I have several applications that use the same dll files. At the moment these files are unversioned. Each application has it's own setup project and as a result of this each shared component has several components codes (GUID:s). This causes each application to
uppdate the component with it's own version of the file. Sometimes components are updated backwards (BAD).
My first ideas to sove this:
1) Introduce a merge module which includes all the common components.
+ same component code for all files with same name and version
- Don't know how the file location is determined? Can I still control where the files are installed with variable.
2) Introduce additional MSI-package for common components
+ One project, one component code for each file version
- Could cause deployment problems if users don't remember to install this package.
3) Manipulate MSI packages with a VBScript after compile to have same GUID:s for each common component.
- Possible breaks self healing function and check sum that is calculated for each package.
- Not sure if this works.
Any suggestions or ideas how to solve this problem elegantly? Thank you.
0 Comments
[ + ] Show comments
Answers (5)
Please log in to answer
Posted by:
aogilmor
20 years ago
This applies to Wise for Windows Installer (WFWI) but if you're using something else same basic principa applies.
This is a pretty complex question, but if you're repackaging an application you can go to the system32 directory on the local computer (or wherever the dlls are) remove and re-add them to the project, and WFWI will prompt you to use the merge module if there is one available.
If an application insists on its own (unversioned) dll then it should go in its own directory, not in a common directory.
The WFWI/Windows installer SDK help files contain versioning and file replacement rules, one of them being that any version will overwrite an unversioned file, no matter the file date.
This is a pretty complex question, but if you're repackaging an application you can go to the system32 directory on the local computer (or wherever the dlls are) remove and re-add them to the project, and WFWI will prompt you to use the merge module if there is one available.
If an application insists on its own (unversioned) dll then it should go in its own directory, not in a common directory.
The WFWI/Windows installer SDK help files contain versioning and file replacement rules, one of them being that any version will overwrite an unversioned file, no matter the file date.
Posted by:
VikingLoki
20 years ago
Using a merge module is best if the common element is a group of library components, runtime elements, etc. VBScript common dialog libraries are a classic example of the stuff of merge modules. It is called by numerous other applications, but it is not an app in and of itself. You can't run the VBScript common dialog. Many apps use it, but you don't run it.
Using a separate MSI is best if the common element is a seperate, complimenting application or utility. If it is a descrete group containing one or more .exe and possibly complimenting libraries, then it's it own app. It doesn't matter if it is useless on its own, so long as it can be launched and will at least produce some sort of Garbage-in/Garbage-out output.
Using a separate MSI is best if the common element is a seperate, complimenting application or utility. If it is a descrete group containing one or more .exe and possibly complimenting libraries, then it's it own app. It doesn't matter if it is useless on its own, so long as it can be launched and will at least produce some sort of Garbage-in/Garbage-out output.
Posted by:
VikingLoki
20 years ago
Oh, and scrap the VBScript idea (#3). Take that route when you have failed at all others. That's like painting your house with a portrait painter's 1/8 inch detail brush when you have a professional paint sprayer in the garage. The tiny detail brush is necessary sometimes, but it should not be used everywhere.
Posted by:
mickman
19 years ago
In my opinion the use of mergemodules comes in most handy in this case.
I did the same with some ocx's and dll's which are used by several applications.
B.e.
If you have your components separated in your wsi/msi you can use the function 'Move components to merge module' to use a merge module for the chosen components.
When you do your future scans Wise will detect the components and will use the mergemodule automatically.
I did the same with some ocx's and dll's which are used by several applications.
B.e.
If you have your components separated in your wsi/msi you can use the function 'Move components to merge module' to use a merge module for the chosen components.
When you do your future scans Wise will detect the components and will use the mergemodule automatically.
Posted by:
MSIMaker
19 years ago
My only fear here is that you will have to manage Merge Modules from here on in. In a large scale deployment this could become a large task.
You might like to try to place all shared components in the app folder ie C:\Program Files\[Yourapp] and add .local files and see if the app runs correctly.
You might like to try to place all shared components in the app folder ie C:\Program Files\[Yourapp] and add .local files and see if the app runs correctly.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
