How to modify the default install path in an MSI-based setup based on a registry value

I got a question from a customer this week asking how they could modify the default installation path in their MSI-based setup package based on a value they wanted to retrieve from the registry.  Typically this kind of modification is desired if your setup shares files/components with another MSI, and that other MSI can be installed to non-default locations by another setup package.  The steps to accomplish this are roughly the following.  Please note that I am basing this algorithm on how we accomplish this inside of Visual Studio setup (I also described what happens behind the scenes in VS setup in more detail here).  There may be alternative ways to accomplish the same result.

  1. Create a new entry in the AppSearch table that contains the Signature_ you want to search for and a specific Property name that will store the data you retrieve
  2. Create an entry in the RegLocator table that has a Signature_ column name that matches the Signature_ column name you added to the AppSearch table in step 1 above and that contains the key/value you want to retrieve and use if it exists on the user's system
  3. Create an entry in the CustomAction table that has a Target value that matches the Property column name you added to the AppSearch table in step 1 above (and is in square brackets since this is an MSI property and it needs to be referenced in square brackets to resolve correctly here), and has a Source name that matches the name of the directory in the Directory table that you want to change the default installation path for
  4. Add an entry to the InstallExecuteSequence table that has an Action column name that matches the name of the custom action added in step 3 above and has a Condition column name that matches the Property column name you added to the AppSearch table in step 1 above.  This will ensure that you will only try to change the installation directory if the registry value you are searching for exists on the user's system, and your MSI will use the default installation directory if the registry value is missing.


Comments (6)

  1. davcamer says:

    Hi Aaron!

    That’s some powerful MSI magic you’ve got going!

    I’d like to do what you describe, but it sounds as if I would have to manually modify the MSI file that my .vdproj creates, each time. Is there a way to automate the process? Alternatively, is it possible to set this stuff up inside VS’s installer project?

    Or, am I totally misguided? If so, please enlighten me 🙂

  2. Hi Davcamer – There are several types of actions that cannot be done in the UI for the Visual Studio setup/deployment project.  You can use the Windows Installer object model and write some script code that can be launched as a post-build step to automate MSI modifications for this type of task.  There is a forum post at that demonstrates an example of how to do this (albeit for a different scenario, but conceptually this is similar to what you’ll need to do here).

    Hope this helps!

  3. Question:

    I am using the Visual Studio setup/deployment project to create an MSI to install my application. …

  4. Mailbag: How can I customize an MSI in the Visual Studio setup/deployment project? Aaron Stebner’s WebLog

  5. owaits says:

    I thought it might be worth pointing out that you can do this in Visual Studio without having to use Orca or creating custom build actions.

    All you have to do is create a registry file search in the launch conditions with a property name e.g. "MYINSTALLPATH". You then go to the file system browser and select the application folder and change the DefaultLocation to "MYINSTALLPATH".

    You can also delete the Install Folder user interface to prevent the user changing the folder.

  6. Hi Owaits – You are correct, this can be done in Visual Studio if you are using a Visual Studio setup/deployment project to create your MSI.  The steps that happen behind the scenes in the MSI created by Visual Studio when you install it are essentially the same as what I described in this blog post.

Skip to main content