7 replies to this topic

[RobIsUpside]

I have an installscript/msi project that has a number of features and components. We regularly do minor upgrades on the main setup and have added components to existing features with existing directory paths successfully. The issue now is that I need to add a new directory to an existing feature set with a new file on a minor upgrade.

I think I might have found a bug - the issue is that if I install the first time to a directory other than the default (C:\Progam files\myapp), on minor upgrade the new component (and the new directory) is installed to the default directory, NOT the same directory where the feature is deployed. If I add new components to the same feature but select an existing directory path, the new file is deployed properly to the non-default location. It's just when selecting a new directory destination that the file (and folder) get deployed to the default INSTALLDIR directory on minor upgrade.

I checked msi logfiles and it shows the new component association with the feature - (business_layer), then does a directory dump and sees that BIN components have a different path than the default but doesn't set XML (the new directory table key) to have the new path - any ideas of what I can do here? Appreciate your input.

MSI (s) (E8:30): SELMGR: New components have been added to feature 'Business_Layer'

MSI (s) (E8:30): SELMGR: Component 'xml' is a new component added to feature 'Business_Layer'

MSI (s) (E8:30): Target path resolution complete. Dumping Directory table...

MSI (s) (E8:30): Dir (target): Key: XML , Object: C:\Program Files\myapp\xml\

MSI (s) (E8:30): Dir (target): Key: BIN , Object: D:\myapp\bin\

[RobIsUpside]

One other piece of this puzzle is in the installlocation property in the uninstall section of the registry - SetARPINSTALLLOCATION works first time during setup. On minor upgrade the key value is overwritten with an empty string - even though the msi log shows

MSI (s) (DC:E8): Skipping action: SetARPINSTALLLOCATION (condition is false)

which is right because the condition is (not installed) and this is a minor upgrade. Why is the key being overwritten?

[Stefan Krueger]

Please post the Directory table rows for XML and BIN.

[RobIsUpside]

Please see attached screenshot of the directory table -

Attached Images

• 

[Stefan Krueger]

Apparently your INSTALLDIR doesn't keep its value. Do you have any component that installs to INSTALLDIR? Otherwise I believe the value won't be retained.

[RobIsUpside]

yes, we have several that install to INSTALLDIR directly - on a side note, we had MS investigate and they are convinced it's something that the installshield wrapper is doing because they cannot reproduce the issue with pure msi projects.

If you were going to suggest that I use MsiGetComponentPath in the resumeui before event on minor upgrade to get the path, I thought of that, only that particular function is not declared and available with installscript/msi projects.

Do you have any advice as to how we can get the path, particularly since the InstallLocation path is reset to en empty string on the first minor upgrade?

[Stefan Krueger]

InstallScript MSI projects tend to be a pain in general. I'd perfer Basic MSI.
[$ComponentName] should give you the install directory, you could use this in a custom action to set INSTALLDIR (I think, didn't try)

[RobIsUpside]

Your workaround works perfectly - unfortunately for us there is a circumstance where users can install particular features without components containing a root directory reference to INSTALLDIR.

In this instance I may attempt to get the path from INSTALL_LOCATION property and if empty prompt the user for the path in the resumeui event, validate by if existsdir or file (something we expect to find at that location) and then set INSTALLDIR. This should be a onetime event as setting installdir will set the registry key value properly from that point forward.

Thanks for your advise Stefan.