Let's suppose we need to file if a dll is installed on machine. WE can use code
<Property Id="IS_DLL_PRESENT" Secure="yes">
<RegistrySearch Id="ManDMSRegistrySearch" Root="HKCR" Key="CLSID\{***}\InprocServer32" Type="file">
<FileSearch Id="DllFileSearch" Name="appName.dll" MinVersion="1.0.0" />
</RegistrySearch>
</Property>
I'm wondering what is the purpose of Name attribute of FileSearch element? According to WIX documentation (see Remarks section) since FileSearch is inside RegistrySearch it just make RegistrySearch to init full file path instead of parent folder path to IS_DLL_PRESENT property.
Documentation says we need to know the fileName to search for it. But logically we can get fileName from parent RegistrySearch element and just verify it exists. And it looks like it works this way because nothing changes if I change the name in the code above to anything unexisting, like "123.dll", or even the property name "[SomeUndefinedPrivateProperty]" - it simply works in any case (log file proves that property is initialized always to the same correct file path) and that is strange =).
Can anybody explain this odd behavior?
Related
I am creating an installer in Wix.
I need a simple dialog during the installation where the user has to agree something, if they do, I want to create a registry key recording this choice.
This seems the simplest of tasks, but how do I use Wix to create the dialog and conditionally create the registry key based on the user's input?
So far I've tried to find out about custom actions, but it seems that this is not the right tool as Wix contains the ability to create a registry key already.
I just don't know how to tie installation of a feature to the response to a specific dialog.
If the agreement is not given, then the installer should continue as normal, just without this specific registry key.
I'm using Visual Studio.
Some code snippets:
This is at the top of my product, next to the other properties.
<Property Id="STREAMING_ACCEPTED" Secure="yes"/>
Then I have a dialog with the following control element.
<Control Id="StreamingAcceptedCheckBox" Type="CheckBox" X="20" Y="207" Width="330" Height="18" CheckBoxValue="1" Property="STREAMING_ACCEPTED" Text="Accept streaming" />
And finally, I'm trying to hook this up by adding a condition to the component.
<Component Id ="StreamingAcceptanceRegKey" Guid="some-guid" Win64="yes">
<Condition>STREAMING_ACCEPTED</Condition>
<RegistryKey Root="HKLM" Key="SOFTWARE\MyProgram" ForceCreateOnInstall="yes" ForceDeleteOnUninstall="yes">
<RegistryValue Type="string" Name="UsageStats" Value="true" Action="write" KeyPath="yes"/>
</RegistryKey>
</Component>
Am I on the right lines, because it's not writing the registry key? Does this actually record "true" and "false" to the property based on the checkbox state?
The UI control has a property associated with it. Make sure it's a secure custom public property. (All caps and marked secure ).
Describing how feature selection and INSTALLLEVEL works in an MSI takes some time. Since you only have 1 registry value I would instead suggest creating a component to set the registry value and putting a condition on that component that uses the secure custom public property found in the UI.
If you want to support the user going into Programs and Features and changing the original choice then make sure you mark the component as transitive and implement a WiX remember property pattern so that subsequent repairs / transactions keep the choice.
http://robmensching.com/blog/posts/2010/5/2/the-wix-toolsets-remember-property-pattern/
I am a noob in Windows programming, but I have to create a tricky MSI installer that installs a plugin via WiX toolset.
The installer should detect upon running all installed versions of specific software and their plug-ins directories via Windows Registry API. After that it should show all of them on a separate page (dialog) with appropriare checkboxes. A user should choose what versions they want the plugin install into.
I've created a custom action (in C++ and put it into a DLL that is in the MSI database) that interacts registry API then loops over the results and adds temporary records to the database tables:
adds path properites to persist the plugin paths;
adds records to the CheckBox table;
adds properties for them to hold their states;
adds conditions for them than checks their property states and enables/disables them;
adds events to reset path properties according to the state properies.
It runs after AppSearch
<InstallUISequence>
<Custom Action="PopulateVersions" After="AppSearch">Not Installed</Custom>
</InstallUISequence>
Then clicking Next button (I know that it's a wrong place to do such things) performs the custom action that filters off active property paths takes the first of them and performs the SetTargetPath action (it works fine). For the rest of them the action inserts appropriate temporary records into:
the DuplicateFile table, where DestFolder is the property name;
the Component table, copying all field values from the original component, setting the Component_Parent field value to the original;
the Directory table. One record per path property, Direcory_Parent is TARGETDIR;
It installed the plugin only to the first property path refers to (which was passed to the SetTargetPath action).
Fine... I added a few CopyFile elements that refer to my custom properties (I declared a few properies to prevent MSI build error due to unknown properties) to the WiX markup just for testing:
<Property Id="PathProperty0" Value="{}"/>
<Property Id="PathProperty1" Value="{}"/>
<Property Id="PathProperty2" Value="{}"/>
<Directory Id="TARGETDIR" Name="SourceDir">
<Directory Id="ProgramFiles64Folder">
<Directory Id="INSTALLLOCATION" Name="MyPluginDir">
<Component Id="PluginExt" Guid="C112184A-307C-5E15-994F-0DFDA9DD427E">
<File Id="MyPlugin" Name="MyPlugin.dll" Source="MyPlugin.dll" Vital="yes" />
<CopyFile Id="MyPlugin_Copy1" FileId="MyPlugin" DestinationProperty="PathProperty1"/>
<CopyFile Id="MyPlugin_Copy2" FileId="MyPlugin" DestinationProperty="PathProperty2"/>
</Component>
</Directory>
</Directory>
</Directory>
Now the ProgressDialog is saying that "{}" is invalid path, but all of the properties were set to valid paths (I've checked this in debug)! Seems like it forgets or ignores all temporary database changes/property changes after showing elevating UAC prompt that asks for access to the same MSI file. The prompt is raised after clicking the Install button (with a shield icon). Probably it reads the database again and does not find any changes as they were in memory or cache, I don't know.
What am I doing wrong or how to make that installer properly? IMHO my implementation is overcomplicated. I do need your assistance.
I see at least two mistakes:
The properties for paths that you want to change at run time should be PUBLIC properties (that is, their names must not include lower case letters. Furthermore they should probably be listed in the SecureCustomProperties property, which you can ensure by declaring them in your source with or without a value, and specifying the Secure attribute.
The value you are specifying for your directory-related property is literally {}. This is an unusual value, and is only rarely correct. Typically you want an empty string instead. The exception is when you are in a Formatted context and need to specify a non-empty string that results in an empty string value, such as a property-setting ControlEvent. The Property element of your wix source is not such a context.
I'm not certain about the full complexity of the approach you described (I haven't been able to fully think it through), but I do want to encourage the general approach you're taking of programmatically creating table data and letting Windows Installer do the rest. This approach is important enough to have been given a name of sorts: semi-custom action.
Per the guidance on semi-custom actions, you will likely want to schedule your PopulateVersions action in both the InstallUISequence and InstallExecuteSequence (especially once it uses RemoveFile to perform cleanup) in order to ensure that installs, maintenance, and silent removals all get the proper table data added.
I think you are making this over complicated. You could just create an AddIns feature with a bunch of AddInVersionXXXX sub features and use the results of the AppSearch in Feature Conditions then show the Custom Setup dialog.
In my IsWiX I do a similar thing except I always install to every version detected. The trick is CopyFile will gracefully skip over the copy if the directory property doesn't have a value. It's really simple and can be see here:
http://iswix.codeplex.com/SourceControl/latest#main/Source/Installer/IsWiXNewAddInMM/IsWiXNewAddInMM.wxs
I am maintaining an old application in which the users configuration is stored in registry. It is left behind when uninstalling. I am now re-writing the installer in WiX.
The installer should add a default value in the registry if there are none there, otherwise
the existing value should be left alone.
I was thinking on how to do this in WiX. And the solution I came up with is somewhat cumbersome:
<Property Id="MY_PROPERTY">
<RegistrySearch Root="HKLM" Key="SOFTWARE\MyProduct" Name="MyProperty" Type="raw" />
</Property>
<CustomAction Id="ca.SetDefaultValue" Property="MY_PROPERTY" Value="DefaultValue" />
<InstallExecuteSequence>
<Custom After="RegistrySearch" Action="ca.SetDefaultValue">Not MY_PROPERTY</Custom>
</InstallExecuteSequence>
<Component Id="c.Registry">
<RegistryValue Root="HKLM" Key="SOFTWARE\MyProduct" Name="MyProperty" Type="string" Value="[MY_PROPERTY]" />
</Component>
So do a registry search to find old value. If not set, set to default value using a scheduled custom action. Then create the value "as usual".
Anyone who can think up a smoother way to do this?
Note that I cannot use convenient variables like Installed since values might be there, left behind by a previous, now uninstalled, version.
Start with the Wix Remember Property pattern but take it one step farther. After AppSearch runs and the REMEMBERME property does or doesn't get a value, use a SetProperty custom action to assign a default value if REMEMBERME="".
I take it one step farther though. I have a concept I call "property precedence". Basically it's a list of priorities for how a property should get it's value.
Highest to lowest:
properties inputted during the UI
public properties passed in at the command line
Properties found during AppSearch
Default values defined in the Property table
In other words, during a first time silent install with no properties passed at the command line the default value in the property table should be used.
During a second time silent install with no properties passed at the command line, the remembered value should take priority over the default value. (If different)
During a first of second silent install, a property passed at the command line should be considered an override value and take priority over both the default and remembered value.
During an interactive install the above rules take place and the UI should display that value. If the user changes the value then this is the ultimate value.
I'll leave it up to you of how to implement the various custom actions to do this. It generally involves a temp prop and a real prop and a series of Set Property CA's with the right execution scheduling and conditions to do what you want it to do.
You haven't explicitly set keypath=yes on the registry value in your component. However, in that case wix will select the first child item which can serve as the keypath. From the wix component element documentation:
If KeyPath is not set to 'yes' for the Component or for a child Registry value or File, WiX will look at the child elements under the Component in sequential order and try to automatically select one of them as a key path.
Therefore, your registry value is the keypath of the component which installs it. This means that the component will not be installed if the registry value already exists. As far as I can tell, that's the behavior you want.
What I would like to do is this:
<Property Id="LICENSEKEYPATH">
REMOVE~="ALL" AND NOT UPGRADINGPRODUCTCODE
<DirectorySearch Id="ProgramDataSearch" AssignToProperty="yes" Depth="4" Path="[#ProductDirInAppData]">
<FileSearch Id="LicenseFileSearch" Name="lic-conf.enp"/>
</DirectorySearch>
</Property>
When my application is being uninstalled, only then, do I want to search for the license file and get its path. Currently, although the code doesnt give any errors, it still searches for the license file path even when I am installing the file. Because of this, the setup gets delayed by a long time. And more importantly, the wix setup displays in the first screen to the effect that its searching for this property and then it continues with the other screens.
So, how do I search for a file or set the value of a property only during uninstallation?
You can control the setting of a property using the SetProperty element. That is just a shortcut for registering a custom action. You can control when the SetProperty executes using a Conditoin in the text element.
As for AppSearch (XxxSearch elements), you can add a condition like the one above to the AppSearch element so that it only runs during uninstall. Note that the conditioning the AppSearch element will affect all XxxSearch elements. So if you need to have a search working during install and another search only during uninstall, that is not possible.
PS: The condition you want will look something like:
Installed AND REMOVE="ALL"
I want to assert that a certain registry value exists after installation, so I added the following component:
<Component Id="RegistryEntryContextMenuOdt" Guid="4BA5BA24-4F65-4BDF-99EB-CB4B947F31A9" DiskId="1" KeyPath="yes">
<RegistryKey Id="RegKeyOdt" Root="HKCR" Action="create" Key=".odt">
<RegistryValue Type="string" Value="openDocument.WriterDocument.1" />
</RegistryKey>
</Component>
The key/value might already be set before the installation. However, I want that the value is set to my specific value, i.e. that it will be overwritten with my value.
My problem is now that this value is always removed when my product is uninstalled. However, I only want the value to be removed if it was added by my installer. If my installer just modified the value, the previous value should be restored (or, if this is not possible, my value should remain untouched).
Please note that the key itself is not removed on uninstall. This seems to work correctly because I specified Action="create" on the RegistryKey element.
Is there maybe a similar setting for RegistryValue which will create the value but not remove it on install?
UPDATE: Both registry keys under HKCR are machine wide settinge, i.e. they originate from the HKLM\SOFTWARE\Classes branch of the registry.
You can make sure that your component is only installed when the registry entry does not exist by making use of the NeverOverwrite attribute of the Component element. From the wix documentation for NeverOverwrite:
If this attribute is set to 'yes', the
installer does not install or
reinstall the component if a key path
file or a key path registry entry for
the component already exists.
You may also need to set the KeyPath attribute on the Registry element to yes to make it unambiguous that the registry entry is the component key path.
If you do want to set the registry value even if it already exists, but you don't want to remove it on uninstall, then you can use the Permanent attribute of the Component element instead.