8 replies to this topic

[markbutler]

I am wondering if you can use the Windows Installer to install shared files that are not DLLs.

To clarify, I wish to install the Java RunTime files in at least two different installers. Users are able to install more than one of these on one machine at a time. To save space on the users machine I have put the Java files into a 'Common' directory (the same directory in each installer).

However, doing this means that when the user uninstalls one of the products, then the Java files vanish and so the other products don't work. Is there a way of marking these as shared files so that some sort of ref count is kept in the same way as shared DLLs?

Thanks,
Mark

[Stefan Krueger]

As long as these files are ONLY installed via MSI, and always use the same component GUID (i.e. you use a merge module) this should work, because MSI keeps a reference count based on component GUID.
Otherwise this is not possible because the legacy SharedDllRefCount mechanism only works for DLLs (as far as I know)

[Glytzhkof]

You obviously need to make sure that the Java files installed to Common in both setups refer to the same component GUID. You might want to move these files to a merge module that you then include in your 2 other setups.

[markbutler]

Thanks for the replies, I probably should move them to merge modules as you suggest.

I have managed to get it to work using the SharedDllRefCount mechanism though (which I thought wouldn't work as well, just tried it on the off chance).

Thanks again for your help.
Mark

[Glytzhkof]

Hi Mark. I would strongly recommend going for the merge module anyway. If two different setups refer to the same file with different component GUID's you can run into many exotic problems. Typically you will have files missing after doing major upgrades, or uninstalling one product will remove files for the other product.

If you use a merge module and include it in both setups Windows installer will take care of the reference counting automagically - the component "knows" it is used by different products (it is OK for several products to use the same component, but it is not OK for two products to use the same files, installed to the same folder with different component GUIDs).

If you get your application to obey this simple rule (nothing has two identities/GUIDs) you are well ahead to create a good windows installer setup.

[sjimmerson]

I'd like to add a wrinkle to this scenario. We are currently in a very similar situation with the exception that the shared files may have also been installed with older versions of products using InstallShield 5.5. I like the idea of using a merge module for our common components, but we still have to account for the possiblity (and it is a very good possiblity) that these common components were previously installed by a non-MSI installation. We also want different versions of the same product to be able to coexist on the same PC so we don't want to uninstall the previous version of the product.

Do you have any recommendations on how to handle this situation? We obviously want to be able to install and uninstall each version without breaking another version.

[Glytzhkof]

I believe the best way to deal with this is to use different file names for the new files. One way is to do like Microsoft does for the MFC runtimes, namely include version numbers in the file names mft42.dll etc...

The other alternative would be to use a folder structure:

..\components\4.3\file.dll
..\components\4.4\file.dll

etc...

Edited by Glytzhkof, 18 December 2003 - 07:39.

[sjimmerson]

I should have mentioned that our shared components are Excel and Word Add-ins and COM Add-ins. Loading multiple versions of these Add-ins could be very tricky.

I was excited about your recommendation until I realized this. Do you have any other suggestions.

Here is additional information on this line of products. Each product in this product line consists of a set of Word or Excel templates and a set of core Excel and Word Add-ins and COM Add-ins (as mentioned above). We are currently using IS 5.5 to install each of these products seperately and the core components in each installation are marked as shared so that when one product is uninstalled it does not break any other installed products. Now we are moving to MSI and the products installed with MSI need to coexist with the products installed with IS 5.5.

I appreciate your help.

Thanks,
Shane

[hteichert]

As long as you are already using the SharedDllRefCount for your Excel and Word Add-ins and COM Add-ins, there's a simple solution:

For every component, the windows installer is able to support the SharedDllRefCount. For detailed info please search the Windows installer help file for "msidbComponentAttributesSharedDllRefCount". This is one of the possible Attributes for a component and defined in the component table.