Dynamic File Linking and (non)random Component GUIDs

[JohanNyvaller]

I'm currently maintaining a rather large install project that contains ~9000 files and makes heavy use of dynamic file linking (for obvious reasons...)

I know that dynamic file linking (at least in the past) has been a common problem for upgrade scenarios due to component IDs being automatically generated, but right now I'm facing the opposite problem.

For a while now we've seen reports that our product leaves empty folders behind when uninstalled, and I finally managed to track down the issue to different versions of the product installing components with the same GUID.

We treat each build of the installer as a separate product with a different installation path, and take great care to update productcodes and static component GUIDs etc. between builds. Dynamic components have not been a problem in the past since we always got new GUIDs generated for those, HOWEVER, it seems that since we upgraded to IS 2008 we're getting the same GUIDs generated for our dynamic components, without having any kind of reference to a previous .msi package! This is true even for installers built on completely separate computers where we have no references whatsoever to any of the old product builds.:eek:

After doing some experimenting it looks like InstallShield is using some kind of GUID algorithm based on the path used for the dynamic components since I was able to get a new set GUIDs generated by renaming one of the Path Variables that's part of the component source path.

Having to rename our path variables for each build is a real pain-in-the-%&"#workaround though, so could anyone tell me if it's possible to revert to the old behaviour, i.e getting a random GUID generated for each dynamically created component?

[GetExp]

Months past I faced a similar problem and atlast I Managed to get around this problem outside the InstallShield. I changed the component GUID's to the new one by reading the MSI. A small script does this job at the end of the build and still we are living with it

[JohanNyvaller]

This is probably the route I'll end up going as well. As far as I can tell from the Windows Installer documentation it should be safe to change the ComponentId without breaking any references after the MSI has been built.

Altough I can understand that the current behaviour is what most people want with dynamic file links it also means that you're in now in deep trouble for the reverse scenario, for example if try to create a new side-by-side product version by just copying your old installer project and change some properties (not that uncommon I would guess?)

[kirann_hegde]

Hello Johan,

You mentioned that you could get new component GUIDs generated by renaming of the path variables.

Test 1
1)Pointed my dynamic component to a particular folder.
2)Built the msi
3)Modified the msi to point to the same directory structure in an entirely **different** path.
4)Built the msi

Results:
1)Compared the msi's and found out that the old component in msi 1 was deleted and a new component was created with a different GUID


Test2:
1)Pointed my dynamic component to a particular folder.
2)Built the msi
3)Modified the msi to point to the same directory structure in the same path.
However this time i ensured that the path variable used for the dynamic link was different than what was used in test 1, eventhough the source files were in the same location as used in step 1
4)Built the msi

Results:
1)Compared the msi's and found out that the only thing which changed was the Directory_ and Keypath columns.

Question:
How did you manage to get the component GUID's changed by just changing the path variable?

I am pretty stuck on this. Any help would be very much appreciated.

Thanks,
Kiran Hegde

[JohanNyvaller]

Hi Kiran

It's been a while since I struggled with this so I can't remember exactly what I did back then, but I did a quick test today:

Using InstallShiled 2008 Premier Edition:

• Created a new Basic MSI project
  
• Created a new component "NewComponent1"
  
• Created a new Path Variable "PathVar1" and pointed it to some random filestructure on my disk.
  
• Added a dynamic file link to "NewComponent1" to the folder pointed to by
  
• Built the MSI.
  

My filestructure had one subfolder, so I got 2 components in the MSI, "NewComponent1" with the static GUID {6BFEEDB1-EF8B-46A4-9CD6-1163D1D2C6BF} as defined in the project and an automatically generated component "_C8B965A23FDEC8E3F1B626B12D7B2C36" with GUID {C8B965A2-23FD-EC8E-3F1B-626B12D7B2C3}

• Back to the project, renamed "PathVar1" to "PathVar2" and acknowledged the warning about broken file links.
  
• In "NewComponent1", brought up the dynamic link dialog and modified the link to use instead of
  
• Built the MSI.
  

The generated component now has a new name and GUID {D610A0B7-7262-2964-8577-775A277D61E2}

Using the steps above to rename the variable back to changes the GUID back to the original {C8B965A2-23FD-EC8E-3F1B-626B12D7B2C3}

So it seems that the name of the variable is a factor when the GUIDs are being generated, but there could of course be other things involved as well - are you using a Basic MSI or an InstallScript project for example?

In my case I ultimately solved the problem by writing a small application that generated random GUIDS and modified the .MSI after it has been built. Another possible solution might be to save the project in XML format and use some kind of Search/Replace to rename the path variables before building.

What I've would really have liked to see is an option in InstallShield to control this behaviour, but I guess we're stuck with using workarounds.

[kirann_hegde]

Hello Johan,

Firstly, thanks for responding back.
I apologize for the delayed response. I thought i would also get in touch with InstallShield. I am posting below my questions and the response i got from InstallShield. Hopefully people should benefit from this.

Question

Hello,

We are using:

Install Shield Premier Edition 2008
Basic msi project
All flavors of windows targeted.
We use a single setup.exe for both fresh install and minor upgrades (service packs)


Our project uses a large number of files.
As part of our project, we use multiple components with dynamic file linking setup. These components even have subfolders linked dynamically.
I have done my fair amount of research on the web and each and every single post I have read states that the Component GUIDs change between every build of your product, if you do **not** point to your previous msi package(Releases view) when the installer built.

However we have released several versions of our product without referencing our previous msi package. If all these posts were true, then the component GUIDs should have changed across releases and all our upgrades should have failed. Upon doing a MSI package diff of the msi's released across several versions, I observe the following:
i) None of the component GUIDs has changed.
ii) What has consistently changed is the Directory_ and Keypath column.

So here are my questions:
1) For dynamic file linking, under what circumstances does the Component GUID change between installer builds?
2) What is the algorithm used by Install Shield to generate component GUIDs for dynamic file links?
3) What is the effect of Directory_ and Keypath column values changing across releases on upgrades? Remember we have **never** pointed our package to the previous msi package in any of our release and still the upgrades continue to work.
How is this possible as the keypaths have changed?
4) This is the most important question of all
We support upgrades from the last two versions: 4.5 and 4.6. We are currently at 5.0
Should i now start pointing my current version of my package to the last released msi, which is 4.6? What is the recommended approach here? Remember, i have not pointed either of 4.5 or 4.6 to their respective previous packages when they were built.

I have just 3 more days to get answers to all of this. Any help would be very much appreciated.

Response from InstallShield
Thank You for contacting Flexera Software Technical Support.

My name is Alpesh and I will be assisting you with this support incident.

I understand that you have some questions about the Dynamic File Links.

Please find answers to your questions here --
1.) The Component GUID changes when you change the dynamic file link to point to a different folder. Ideally, during subsequent builds, the file keys for the files changes. But if you use the Previous Package field, then it will keep the file keys also in sync with the previous release.
2.) This would be Intellectual Property, but IS generates a different component for every PE file and subfolders.
3.) The Directory identifiers and File Keys are changing, but they are pointing to the same directory and same file. Hence, it is not causing the upgrade to fail.
4.) Ideally each package should point to a previous package. But if you are starting now, point to the latest package that is out right now.

Also the Dynamic File link functionality has been improved upon with every IS release.

I hope the information helps you.



This is inline with what your observations have been.

Thanks,
Kiran Hegde