Sign Up

Sign Up to our social questions and Answers Engine to ask questions, answer people’s questions, and connect with other people.

Have an account? Sign In

Have an account? Sign In Now

Sign In

Login to our social questions & Answers Engine to ask questions answer people’s questions & connect with other people.

Sign Up Here

Forgot Password?

Don't have account, Sign Up Here

Forgot Password

Lost your password? Please enter your email address. You will receive a link and will create a new password via email.

Have an account? Sign In Now

You must login to ask a question.

Forgot Password?

Need An Account, Sign Up Here

Please briefly explain why you feel this question should be reported.

Please briefly explain why you feel this answer should be reported.

Please briefly explain why you feel this user should be reported.

Sign InSign Up

The Archive Base

The Archive Base Logo The Archive Base Logo

The Archive Base Navigation

  • SEARCH
  • Home
  • About Us
  • Blog
  • Contact Us
Search
Ask A Question

Mobile menu

Close
Ask a Question
  • Home
  • Add group
  • Groups page
  • Feed
  • User Profile
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Buy Points
  • Users
  • Help
  • Buy Theme
  • SEARCH
Home/ Questions/Q 6569075
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Editorial Team
Asked: May 25, 20262026-05-25T14:34:53+00:00 2026-05-25T14:34:53+00:00

The short version is that I am building an installer package, and I want

  • 0

The short version is that I am building an installer package, and I want the “Next” button of my welcome screen to change its behavior based on whether or not a specific registry key exists. It seems like I should be able to modify the conditions of the next button’s actions to get this behavior, but so far no luck. I always either get behavior A or behavior B, I have not gotten behavior that is sensitive to the registry value.

I should note that I can remove the UI completely and run the package via command line to get the desired results, but I am trying to be a little more user friendly by adding the install path dialog when appropriate.

In a bit more detail…

I am working on installers for a series of independent, but related, class libraries. If we install a library on a clean box I want the installer to prompt the user for an install path, and then write this path off to the registry during the install process. However if we install a library on a box which already has one of the other libraries present, I want the installer to read the registry and use the same path as the previous install.

My thought process was to modify the standard WixUI_InstallDir interface to check for the registry search result and skip the InstallDirDlg if it is set. However this does not appear to be working. Here are some snips from the XML:

<Property Id="FOOPATH">
  <RegistrySearch Id="PathSet" Type="directory" Root="HKLM" Key="Software\Foo" Name="InstallPath"></RegistrySearch>
</Property>
<Property Id="PATHSET">
  <RegistrySearch Id="PathSet" Type="directory" Root="HKLM" Key="Software\Foo" Name="InstallPath"></RegistrySearch>
</Property>

<Directory Id="FOOPATH" Name="Foo">
  <Component Id="FooPathReg" Guid="Some Guid">
    <RegistryKey Root="HKLM" Key="Software\Foo" Action="createAndRemoveOnUninstall">
      <RegistryValue Name="InstallPath" Type="string" Value="[FOOPATH]" KeyPath="yes"></RegistryValue>
    </RegistryKey>
  </Component>
</Directory>

<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="InstallDirDlg">NOT Installed AND NOT PATHSET</Publish>
<Publish Dialog="WelcomeDlg" Control="Next" Event="NewDialog" Value="VerifyReadyDlg">NOT Installed AND PATHSET</Publish>

If my publish conditions are using the PATHSET property (as shown) then I always get the install directory dialog, if I switch them to use the FOOPATH property then I never get the dialog. I have also tried playing with the InstallUISequence and it does not seem to matter how early I schedule the AppSearch action, I still get the same result.

Is there something simple I am missing? Or do I need to take another approach on this?

  • 1 1 Answer
  • 0 Views
  • 0 Followers
  • 0
Share
  • Facebook
  • Report

Leave an answer
Cancel reply

You must login to add an answer.

Forgot Password?

Need An Account, Sign Up Here

1 Answer

  • Voted
  • Oldest
  • Recent
  • Random
  1. Editorial Team
    Editorial Team
    2026-05-25T14:34:53+00:00Added an answer on May 25, 2026 at 2:34 pm

    Ok this turned out to be one of those brain dead moments where I missed something in my testing process. I am filling in the details of why it was failing in the hope that it saves someone else some of the frustration I have experienced while working on it.

    First it is important to know that I was not actually testing multiple packages, I was trying to get my base structure worked out with the first package, then apply it to the rest when I thought I had it fairly close, this was to help reduce the number of changes I needed to replicate across the group of packages. To do this I was manually adding the registry entry in question, prior to running the package, there by simulating a prior install.

    What I neglected to do was actually create the directory referenced by the registry entry. I was walking through the process with a co-worker, and in the course of explaining it I noticed this section of the log:

    Action start 8:26:16: AppSearch.
    MSI (c) (BC:D4) [08:26:16:505]: Note: 1: 2262 2: Signature 3: -2147287038 
    MSI (c) (BC:D4) [08:26:16:506]: Note: 1: 2262 2: Signature 3: -2147287038 
    MSI (c) (BC:D4) [08:26:16:507]: Note: 1: 2262 2: Signature 3: -2147287038 
    MSI (c) (BC:D4) [08:26:16:507]: PROPERTY CHANGE: Adding NETFRAMEWORK35 property. Its value is '#1'.
    Action ended 8:26:16: AppSearch. Return value 1.
    

    And it occurred to me to try creating the directory referenced by the registry value as well as the registry value itself. Once the directory was there, everything started working properly.

    Apparently when you tell the RegistrySearcher that the value is a directory, it only sets the value into the property when said directory actually exists. This detail never came up in my searches on the topic, and is not clear in the documentation I have found, though in retrospect I can see where it is implied.

    • 0
    • Reply
    • Share
      Share
      • Share on Facebook
      • Share on Twitter
      • Share on LinkedIn
      • Share on WhatsApp
      • Report

Sidebar

Related Questions

Short Version: What are the chances that a site's various sub-pages' page-ranks will suffer
Short version question : Is there navigator.mozIsLocallyAvailable equivalent function that works on all browsers,
Short version: Why does Visual Studio tell me that the code has thrown a
I have a short version of the question: I start a thread like that:
Here is the short version. I have a Bonus Activity that has 25 image
The short version is that I've turned the brightness way down on my monitor
The short version is that I have a protocol which has an optional parameter.
Ok, the short version is that I have a Linq entity from a LinqDataSourceUpdateEventArgs
Short version : VB.Net Windows forms feature controls that are often dragged from the
Short Version: I have a WinForms app that uses a .NET 4.0 WebBrowser control

Explore

  • Home
  • Add group
  • Groups page
  • Communities
  • Questions
    • New Questions
    • Trending Questions
    • Must read Questions
    • Hot Questions
  • Polls
  • Tags
  • Badges
  • Users
  • Help
  • SEARCH

Footer

© 2021 The Archive Base. All Rights Reserved
With Love by The Archive Base

Insert/edit link

Enter the destination URL

Or link to existing content

    No search term specified. Showing recent items. Search or use up and down arrow keys to select an item.