This website uses cookies. By clicking Accept, you consent to the use of cookies. Click Here to learn more about how we use cookies.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
- Revenera Community
- :
- InstallShield
- :
- InstallShield Forum
- :
- Basic MSI: InstallDir Variable not set correctly on Minor Update???
Subscribe
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Subscribe
- Mute
- Printer Friendly Page
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2014
02:39 AM
Basic MSI: InstallDir Variable not set correctly on Minor Update???
Hi!
I'm using the INSTALLDIR variable in my Basic MSI setup for some Custom Actions. In general this works fine, but recently I noticed that this variable is not being set correctly for minor updates. In that case the variable is set to its default (usually "C:\ProgramFiles\ProductName"), which works fine if the application already was installed to the default location. But if the appliaction was installed to a different drive or folder, then the update fails because the Custom Actions that are using the INSTALLDIR property are referring to a wrong path (the rest of the setup is installed/updated correctly).
Any ideas what is going on? Is my setup somehow spoilt, or is that the default behavior?
Regards
Ralf
I'm using the INSTALLDIR variable in my Basic MSI setup for some Custom Actions. In general this works fine, but recently I noticed that this variable is not being set correctly for minor updates. In that case the variable is set to its default (usually "C:\ProgramFiles\ProductName"), which works fine if the application already was installed to the default location. But if the appliaction was installed to a different drive or folder, then the update fails because the Custom Actions that are using the INSTALLDIR property are referring to a wrong path (the rest of the setup is installed/updated correctly).
Any ideas what is going on? Is my setup somehow spoilt, or is that the default behavior?
Regards
Ralf
(6) Replies
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 23, 2014
08:06 AM
Typically if a directory table entry isn't correct during maintenance, it's because no components (or at least no files) are installed directly to that directory. For directories with associated installed components, Windows Installer will automatically remember the location. Could this cause what you're seeing?
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2014
02:35 AM
Hi MichaelU,
it is true that no files are directly installed into the INSTALLDIR, a subfolder is always added that keeps the files. I noticed that these subfolders (the Destination property of the components) automatically get their own variables in the Directory table. These variables get updated, hence I started to rewrite my setup to use these variables instead of the INSTALLDIR variable, but as a result I noticed that even the InstallLocation key in the registry is wrong after a minor update. Of course I can handle all that, but it seems very odd to me.
I'll try to reproduce the said issue with other MSI setups that I have now... I wonder if this is a general issue or the result of a screwed setup project.
Regards
Ralf
it is true that no files are directly installed into the INSTALLDIR, a subfolder is always added that keeps the files. I noticed that these subfolders (the Destination property of the components) automatically get their own variables in the Directory table. These variables get updated, hence I started to rewrite my setup to use these variables instead of the INSTALLDIR variable, but as a result I noticed that even the InstallLocation key in the registry is wrong after a minor update. Of course I can handle all that, but it seems very odd to me.
I'll try to reproduce the said issue with other MSI setups that I have now... I wonder if this is a general issue or the result of a screwed setup project.
Regards
Ralf
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2014
03:21 AM
Hi MichaelU,
you were right and I find that kinda scary... Here's what I tested:
1. I created two new basic MSI setups. Both setups only have one feature with one component which installs one dummy file.
2. While the first setup installs its dummy file directly to [INSTALLDIR] the second setup deploys its dummy file to [INSTALLDIR]SubFolder.
3. I then used a new Virtual Machine (Win 8 64bit) with two drives.
4. I installed both setups to the said virtual machine, but changed the target dir from the default to the second drive (e:\Setup1 and e:\Setup2).
5. I checked the registry under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for the installed setups. The information there was OK (especially the InstallLocation key).
6. I rebuild the two setups with an increased version number in order to achieve a minor update.
7. I updated the setups on the virtual machine.
8. I checked the registry under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for the installed setups...
While the first setup that directly installed to INSTALLDIR was had still valid informtion the registry key InstallLocation for the second setup was wrong now => it was pointing to the default install location which in that case just did not exist.
I would consider this as a bug and I wonder if I'm the first one who discovered this (seriously: I am the only one with a setup that does not directly install to INSTALLDIR?). Shouldn't that be reported to Microsoft?
Regards
Ralf
you were right and I find that kinda scary... Here's what I tested:
1. I created two new basic MSI setups. Both setups only have one feature with one component which installs one dummy file.
2. While the first setup installs its dummy file directly to [INSTALLDIR] the second setup deploys its dummy file to [INSTALLDIR]SubFolder.
3. I then used a new Virtual Machine (Win 8 64bit) with two drives.
4. I installed both setups to the said virtual machine, but changed the target dir from the default to the second drive (e:\Setup1 and e:\Setup2).
5. I checked the registry under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for the installed setups. The information there was OK (especially the InstallLocation key).
6. I rebuild the two setups with an increased version number in order to achieve a minor update.
7. I updated the setups on the virtual machine.
8. I checked the registry under HKLM\Software\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall for the installed setups...
While the first setup that directly installed to INSTALLDIR was had still valid informtion the registry key InstallLocation for the second setup was wrong now => it was pointing to the default install location which in that case just did not exist.
I would consider this as a bug and I wonder if I'm the first one who discovered this (seriously: I am the only one with a setup that does not directly install to INSTALLDIR?). Shouldn't that be reported to Microsoft?
Regards
Ralf
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 24, 2014
08:59 AM
I don't think this is an outright design bug in Windows Installer. While I'm not sure I agree with the design choice, it's an unfortunate thing that happens in some relatively unusual cases, and may be exacerbated by how we designed our Basic MSI template. But either way it's not new, and it's not too hard to work around:
First, I suspect adding a component with a key path of INSTALLDIR, even without files, can fix this. If so, that's a pretty trivial step to take. Second, even if that doesn't fix it, it should be feasible to wire up a system search or custom action to retrieve the location of INSTALLDIR in maintenance scenarios in order to fix this. (Or, alternately, to tweak the condition on the SetARPINSTALLLOCATION action we provide you so that it won't overwrite things in this case. By default it runs unconditionally.)
First, I suspect adding a component with a key path of INSTALLDIR, even without files, can fix this. If so, that's a pretty trivial step to take. Second, even if that doesn't fix it, it should be feasible to wire up a system search or custom action to retrieve the location of INSTALLDIR in maintenance scenarios in order to fix this. (Or, alternately, to tweak the condition on the SetARPINSTALLLOCATION action we provide you so that it won't overwrite things in this case. By default it runs unconditionally.)
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 27, 2014
04:44 AM
Hi MichaelU,
I'll give it a try to add an empty component that targets the InstallDir-Directory directly - that's something I did not think of...
Regards
Ralf
I'll give it a try to add an empty component that targets the InstallDir-Directory directly - that's something I did not think of...
Regards
Ralf
- Mark as New
- Subscribe
- Mute
- Permalink
- Report Inappropriate Content
‎Oct 27, 2014
03:12 PM
Ran into this a few months ago.
Created a Component named INSTALLDIR_Reg. No files, just a benign Registry entry.
In the Comments field set myself a reminder: There MUST be at least one Component with Destination of [INSTALLDIR] to help when non-default directory is chosen.
Created a Component named INSTALLDIR_Reg. No files, just a benign Registry entry.
In the Comments field set myself a reminder: There MUST be at least one Component with Destination of [INSTALLDIR] to help when non-default directory is chosen.
![](/skins/images/8CE4FAD0DE6F3A6F9D0567434D2D2DAE/responsive_peak/images/icon_anonymous_message.png)