Hi,
I have prepared an installation that was already released in severeal version to our clients.
No I want to prepare another product installation that can be installed separately from the 1st product or as a side-by-side to it.
Both these products will have many common file, which means - they (as I understand) should have the same components (this means, as far as I understand, all the commong components will have the same GUID in the 2 products).
Is there something I should be aware of when creating the 2nd product installation ?
How about pathching these 2 products? should they be done in 2 separate MSPs ?
Does sharing the Components between the 2 product will ensure that if one of the 2 products will be installed side by side and then one of the products will be removed, then the commong file will remain (until the other product will be removed) ?
Thanks.
Igal
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Sharing Components between products?
Started by
elliot
, Mar 17 2005 12:32
5 replies to this topic
Posted 18 March 2005 - 07:05
You should be ok as long as you make sure the second component has the same guid (component ID) as the first one.
Im pretty sure that a patch is product specific so if has to be created for each install anyway.
Im pretty sure that a patch is product specific so if has to be created for each install anyway.
Posted 18 March 2005 - 10:51
If you install those common files to a common (shared) location then you should use the same component code GUID (and the same key file). Windows Installer will then take care of ref counting the components and delete the file only if it's no longer needed by any application.
If however you install these files to separate directories (so the user ends up with two copies) then you should change the component GUID. In this case the will be treated as completely unrelated.
If however you install these files to separate directories (so the user ends up with two copies) then you should change the component GUID. In this case the will be treated as completely unrelated.
Stefan Krüger
InstallSite.org twitter facebook
Posted 21 March 2005 - 12:18
What about patching these 2 products (which have common Components) ?
Can a single patch update 2 different products (which might have different version numbers and will for sure have 2 different Product IDs) ?
Anything I should keep in mind when authoring the 2nd product in order to keep my life simple when I will have to prepare patch(es) for these products ?
Thanks,
Igal
Can a single patch update 2 different products (which might have different version numbers and will for sure have 2 different Product IDs) ?
Anything I should keep in mind when authoring the 2nd product in order to keep my life simple when I will have to prepare patch(es) for these products ?
Thanks,
Igal
Posted 18 June 2005 - 13:10
The general solution for shared files like this is to put them in a merge module, and then add the merge module to both setups. However as communicated above you should be safe as long as you make sure the component guid used in both setups are the same.
I have never tested what happens in patching, but I would assume the patch would update the files if they are found to be older versions than that of the patch, and left alone if they have already been patched. To minimize the chance of errors I would include whole files instead of bit level patches in the patch.
Remember that with patching the same condition that always applies to a file which maintains its GUID between updates: the new file has to be 100% backwards compatible. What this means in reality is that you must be able to patch one of your products and have it update the shared files and the other product must still work even if it has not been patched yet. If this is not the case the solution would generally be to change the file name, assign a new comonent GUID to the new file and then link the new EXE files for your application to use the new file.
I have never tested what happens in patching, but I would assume the patch would update the files if they are found to be older versions than that of the patch, and left alone if they have already been patched. To minimize the chance of errors I would include whole files instead of bit level patches in the patch.
Remember that with patching the same condition that always applies to a file which maintains its GUID between updates: the new file has to be 100% backwards compatible. What this means in reality is that you must be able to patch one of your products and have it update the shared files and the other product must still work even if it has not been patched yet. If this is not the case the solution would generally be to change the file name, assign a new comonent GUID to the new file and then link the new EXE files for your application to use the new file.
Regards
-Stein Åsmul
-Stein Åsmul
Posted 18 June 2005 - 13:17
All this comes down to the fundamental MSI concept: GUIDS are to be globally unique and refer to one file in one location only. If the file name or location changes it is a new file and it needs a new GUID. This means that you should never do the following:
Hope this was an answer to what you actually asked, and not out of scope.
- Never change component guid for a preinstalled file without changing file name or install location
- Never keep the component guid the same for incompatible versions of files
- Never move a file to a new location without changing the GUID (though this is sometimes done to move a file in a major upgrade)
- Etc...
Hope this was an answer to what you actually asked, and not out of scope.
Regards
-Stein Åsmul
-Stein Åsmul