Component destination folders using custom properties in the path?

[BrHartmann]

In looking at the "Component Settings" page in IS help, under General - Destination, my impression is that we can use custom (ALL CAPS) properties in the destination path:

"In Basic MSI, InstallScript MSI, MSI Database, and Transform projects, if you want the destination to be configurable at run time, the destination folder that you select must be a public property (containing all uppercase letters). "

I had hoped to overhaul some of my IS-MSI projects and set up paths which start with something like this:
[CommonAppDataFolder][COMPANY][PRODUCTFOLDER]morepaths

(where i can then easily override the "PRODUCTFOLDER" property for instance in script for an offshoot product that is created from the same IS project)

This worked fine using these properties in registry entries, but failed spectacularly for file destinations (only [CommonAppDataFolder] was translated at install time, the rest were used literally). I checked in the Direct Editor to see if the brackets were being escaped (an old issue with imported reg entries which has been fixed in IS 2012), but this does not appear to be the case.

Does this simply not work? Is there a slightly different way I should be doing this (i.e. <> brackets or {} braces instead)?

Of course many of the components can be handled by changing INSTALLDIR at in script, but we have a lot of files in [CommonAppDataFolder], [CommonFilesFolder], and for the x64 project, [ProgramFilesFolder] (since Installdir uses [ProgramFiles64Folder] ), so I hope there is a not-too-painful way to accomplish this.

[BrHartmann]

I found an old post that has a method for setting destination folders dynamically in script:

http://community.installshield.com/showthread.php?t=188811


I was hoping perhaps in IS 2012 there might be a simpler solution?

[skolte]

I have used FeatureSetTarget() to change the destination directory of a feature .
You can find more about it here.

Perhaps that might be helpful in your case.

[BrHartmann]

Thanks for the reference. This seems to be what I need, but it's not quite working yet.

Many of my components make use of 2 different directory identifiers. I had hoped to just run FeatureSetTarget (near the beginning of OnFirstUIBefore, IS-MSI project) 5 times, as I need to change 1 dir ID that is a child of INSTALLDIR, 2 which are child/grandchild of CommonFilesFolder, and 2 which are child/grandchild of CommonAppDataFolder.

I generated a verbose log to investigate further. Apparently the change to the child folder in the latter 2 cases is taking effect for all the other subfolders below, but the grandchild folder is NOT being changed (though the log clearly shows that dir ID being fixed just before reporting on all the other subfolders).

To clarify, I have
[CommonFilesFolder]/A/B/otherfolders
...
I run FeatureSetTarget on separate lines to fix A and B (since these are stored as separate Directory Identifiers in the Directory table). All the otherfolders get updated afterwards, but only A changes in the longer paths, not B.

Any advice on this?

Thanks.

[skolte]

Top of my mind, I can't think of a reason why... Is there a sample that you can share? or portion of the log file perhaps?

What does the log show? Does it show the grandchild directory or the variable name for the folder?

Whenever I got stuck with dynamic mods, I tried to build simple samples with just text files to try out the configurations, that usually helps as you take away the other complexities.

[BrHartmann]

It seems like there's an Installshield bug in here, though maybe I can workaround it by instead using a CA at just the right spot in the execute sequence (?). The KB article suggested that putting the code in OnFirstUIBefore() would be fine, and it is as long as you are only changing one section of the path (or course the KB article also specifies Basic MSI, which shouldn't even have that event, so where there's one flaw, why not two).

To recap, in my script in OnFirstUIBefore() (and i tried moving these to the end of the function to clear the other contents of the function of any wrongdoing), I have:

FeatureSetTarget(MEDIA, '', CommonAppDataFolder ^ IFX_COMPANY_NAME ^ PROD_NAME);
FeatureSetTarget(MEDIA, '', CommonAppDataFolder ^ IFX_COMPANY_NAME ^ PROD_NAME ^ VIEWER_NO_EXE);

(PROD_NAME and VIEWER_NO_EXE are #define'd string constants which are inside a #ifdef / #else / #endif block at the top so I can set them per product using preprocessor defines in the product configuration screen)

The verbose log shows something running immediately after OnFirstUIBefore() (or at least it's the next event that shows up in the log)

after several lines like this:

MSI (c) (30:08) [11:10:19:751]: PROPERTY CHANGE: Modifying VIEWER_PATH_CADF property. Its current value is 'C:\ProgramData\MyCompany\MyProduct\ProductShort\'. Its new value: 'C:\ProgramData\MyCompany\MyOtherProduct\OtherProductShort'.
...
(I substituted the true path names to protect the innocent 😉

the next "event" (aka, the "culprit") is a series of these:

MSI (c) (30:08) [11:10:40:500]: PROPERTY CHANGE: Modifying VIEWER_PATH_CADF property. Its current value is 'C:\ProgramData\MyCompany\MyOtherProduct\OtherProductShort'. Its new value: 'C:\ProgramData\MyCompany\MyOtherProduct\ProductShort\'.
...

Note it correctly keeps "MyOtherProduct", yet incorrectly reverts back to "ProductShort", the original path defined in the Directory table (instead of using generic variable names to set for every product, I hardcoded the dominant product's paths, and just override with new values when building the secondary product)

For context, the very next logged item after all these substitutions is this:
1: Ready to launch MsiInstallProduct, Command line : ...


Also, just for kicks I tried ComponentSetTarget() in place of FeatureSetTarget(), but there was no change in behavior.

[BrHartmann]

I confirmed that if I skip setting , the setting of works correctly ... so it's definitely an issue with setting more than one directory identifier with FeatureSetTarget() used in the same path(s).


I can workaround this for now by duplicating some components, but if there's a cleaner workaround (or a planned fix for SP1 perhaps?), I'd appreciate any suggestions.

Thanks.