8 replies to this topic

[ianmw7]

I have to make various install packages relating to a single product, many of which use the same components. With anything up to 80 components, I don't want to recreate each one from scratch, so I do a save as, and then adjust. GUIDs ( not changed by a save as). Obviously I change package, product etc - but does anyone know if component GUIDs all need to be changed as well? If they are the same across different packages, is this going to mess up uninstall/repair etc?

[Barbara]

If you do not change the component GUIDS MSI treats themas shared components. This will make You problems if  the contet of the components is not the same or not compatible.
Example: Setup1 and Setup2 contain both Component1 with the same GUID. In Setup2 this component contains one file more. If You install both setups on the same computer and then deinstall, this file could be left on the computer. Using the same component code for not compatible components will definitely mess up Your installations iIf You use upgrades and repairs.

[Scott Williams]

Question, why do you need to make several different packages revolving around the same product?

I have not looked at Transforms at all, but maybe you are in more need of those than authoring several different MSI files.

[Ian Blake]

I am a little concerned by Barbera's suggestion.  I believe you must keep the same GUID.  One keyfile one guid forever.  The guid and key file are essential to the uninstall and upgrade processes.

The case Barbara outlined  with additonal or alternate files being added in one install and not another.  Such files should have their own component.  (some files may need a registry key as 'keyfile')

Keeping the same GUID allows MSI to manage the component.

If you change the GUID and your component is for example a COM object you will create an auto repair war between two instances of the same component.  Package A will not accept Package B as properly installed and vice versa.

You can really leverage the power of window installer here.  A full understaning of components, GUIDs and the Upgrade Table will allow you to perform magic here.

If the packages are likely to be installed on the same machine and the components can not share a directory you may need to read about Isolated Components to allow seperate instances..

[ianmw7]

Thanks for your replies. According to an IS trainer, as long as the compnents are identical, the same GUID is fine, as they are reference counted. This is more or less what I thought, though I was unsure if this could be relied on across different packages, but apparently it can. Isolated components (imho!) are a recipe for disaster, and make a nonsense of everything MS has been trying to get us to do for years - but I guess that's par for the course.

[Dave I]

As a slight side track, what if I have two products which require exactly the same file/component but in a different directory is a new GUID required for the component?  Surely when the component is registered it is directory specific in order to repair it later, but if two components with the same file are in different directories how does this work?

The two products can be installed simultaneously but can also be stand alone, so you can see why this is necessary.

Any helps would be appreciated with this component conundrum .

[Ian Blake]

Dave - The isolated components table allows components to be installed in individual places.  I can not say more because I have never needed it.

[ianmw7]

Now you've got me worried again. Maybe I didn;t make myself clear enough when I asked the IS trainer about this - but it is across different directories that I wanted to know about - same situation as Dave. Isolated componenets don't matter since the install dirs are going to be different, and the DLLs go to INSTALLDIR. I guess what we should do is have a common files directory.

[Ian Blake]

Firstly the reason I mention the isolated components table is because that is how you tell msi to install a component in more than one directory.

I would agree that using a common files directory is one of the better ways of sharing components.

Create an entry in the directory table using the power editor derived from CommonFilesFolder
eg.

Directory:   OurCommonFiles
Directory_Parent:    CommonFilesFolder
DefaultDir:   LongCo~1|LongCompanyName

If your company name is 'short' the DefaulDir would just be 'short' no need for the '|'

From the advanced view, components section set the Destination to [OurCommonFiles] for the shared components.  You will need to type this in, ISWI is not bright enough to use the directory table in the drop down list.

Some of your apps may need help in finding where an unregistered dll is.  Give the app programmer the GUID  of the component and tell him to use MsiLocateComponent. I think this is a much better  way of finding files than some of the others. Of course if your apps do this it would not matter where anything was installed.