I have a variable="name" in my userInputSpec.xml . I use it to create the directory inside installation. $INSTALL_PATH/${name}
I want to remove the spaces supplied in the name before it triggers the installpanel.
I do not want to restrict the user to enter the spaces.
In IzPack 5.0, you might use dynamic variables with a regexp filter for it, see http://docs.codehaus.org/display/IZPACK/Dynamic+Variables:
<conditions>
<condition id="nameIsSet" type="exists">
<variable>name</variable>
</condition>
</conditions>
<dynamicvariables>
<variable name="name.nospace" value="${name}" checkonce="true" condition="nameIsSet">
<filters>
<regex regexp="\s+"
replace=""
defaultValue="${name}"
global="true"/>
</filters>
</variable>
</dynamicvariables>
In this case, ${name.nospace} might be the variable to reuse, which would be set once the ${name} variable is set (and never changed after that).
Related
For a build script, part of my process is to deploy files using an in-house executable. We call this with a number of parameters.
On an application I'm working on, it turns out we need to add a parameter. This isn't something that retroactively applies to anything else I've previously worked on, so the idea is that I would only include the new argument if the corresponding property is not null or empty.
Relevant NAnt Call:
<property name="deploy.NewArg" value="" />
<echo message="deploy.NewArg = ${deploy.NewArg}" />
<exec program="C:\Deploy\MyAwesomeDeployProgram.exe">
<arg value="AppTitle=${deploy.AppTitle}" />
<arg value="Environment=${deploy.Environment}" />
<!-- Here's the problem argument... -->
<arg value="MyNewProperty=${deploy.NewArg}" if="${deploy.NewArg}" />
</exec>
The reason what I have is not working, is because of the if clause on the new <arg> tag - the deploy.NewArg string doesn't convert to a boolean statement.
Question: In what way can I perform an "Is Null or Empty" check on an <arg if> parameter? As noted above, I want the MyNewProperty=... argument added if deploy.NewArg is anything but nothing or an empty string.
I checked a number of other StackOverflow questions, as well as the official NAnt arg tag documentation, but could not find how to do this.
It turns out, I needed to get back to the basics, and check out some of my fundamentals and functions. The way to do an 'is empty' check on a property is as below:
<exec program="C:\Deploy\MyAwesomeDeployProgram.exe">
<!-- Other args... -->
<arg value="MyNewProperty=${deploy.NewArg}" if=${string::get-length(deploy.NewArg) > 0}" />
</exec>
For someone who hasn't yet done the research, if only works with a boolean. That being said, booleans can be generated in one of two ways: either an explicit true or false, or by using an expression. Expressions are always contained in ${} brackets. The use of string::get-length() should be obvious.
Bring it all together, and you only include an argument if it's specified.
In my Bundle code, I'm trying to use the result of a registry search to set Variable to be used in my Custom Boostrapper:
<util:RegistrySearch
Id="ThirdPartyInstallDirSearch"
Variable="THIRDPARTY_INSTALL_DIR"
Root="HKLM"
Key="SYSTEM\CurrentControlSet\Control\Session Manager\Environment"
Value="OceanSoftDir"
Result="exists"
/>
<Variable Name="THIRDPARTY_INSTALL_DIR" Type="string" Value="$(var.THIRDPARTY_INSTALL_DIR)"/>
But this would give an error:
Undefined preprocessor variable '$(var.THIRDPARTY_INSTALL_DIR)'
Basically, I want to pass the result of registry search to my custom bootstrapper application.
Thanks
As the error says, $(var.<NAME>) is a preprocessor define from either a wxi file or from the project file <DefineConstants>name=value</DefineConstants> or from a <?define?>. You can read more about the preprocessor here.
For your issue, the registry search itself should be defining the variable. I do something similar to what you want in a bootstrapper.
<Fragment>
<util:RegistrySearch
Id="ClientInstalledCheck"
Root="HKLM"
Key="SOFTWARE\Client"
Value="ClientPath"
Result="value"
Variable="ClientInstalled"/>
<util:DirectorySearch
Path='[ClientInstalled]'
Variable='InstallFolder'
After='ClientInstalledCheck'
Condition='ClientInstalled' />
</Fragment>
And then in the products installed by the bootstrapper I will pass in the "InstallFolder" value to these installs.
<MsiProperty Name="INSTALLDIR" Value="[InstallFolder]"/>
This way if the user has installed in a non-default install location, we pick up the custom location they chose and use that instead. If the registry key did not exist, we use the default location.
I also have the InstallFolder variable defined with a default location (since my use case is slightly different than yours) as
<Variable Name="InstallFolder" Type="string" Value="[ProgramFilesFolder]$(var.CompanyInstallDir)\" bal:Overridable="yes" Persisted="yes"/>
Where CompanyInstallDir is defined as a preprocessor variable through <DefineConstants> which is originally defined somewhere in an MSBuild properties file.
So to explain your issue, you are mixing preprocessor directives and Variables. In your registry search, you're using Result="exists" which will set the variable THIRDPARTY_INSTALL_DIR to '0' or '1'. You want to use Result="value". This will put the registry location's value in the variable you define in the Variable="" attribute.
If you do the registry search + directory search with condition, you can properly set a variable if and only if the registry exists AND the directory is actually present on the machine and properly handle cases where it isn't but the registry still exists.
Some things you may do differently since the use case is slightly different but hopefully this sets you on the right path for doing what you need to do.
Given the following...
<Property Id="TESTSEARCH">
<RegistrySearch Id="LookingForKeyExists"
Root="HKLM"
Key="Software\Classes\.ext"
Type="raw" />
</Property>
... I can get one of three conditions.
The key is not present
The key is present but not set
The key is present and has a value
I would like to be able to tell the difference between the following conditions.
<Condition Message="The extension .ext is missing">
???
</Condition>
<Condition Message="The extension .ext has no default value">
???
</Condition>
But all I've been able to find/figure out is the OR of the two.
<Condition Message="The extension .ext is either missing or does not have a default value">
TESTSEARCH
</Condition>
Can the two separate conditions be distinguished without writing an extension? If so, how?
I don't think it is possible and it looks like Windows Installer limitation, rather than WiX toolset. This original article on MSDN states that explicitly:
Note that it is not possible to use the RegLocator table to check only
for the presence of the key. However, you can search for the default
value of a key and retrieve its value if it is not empty.
I have a WiX installer project that I'm creating where I'd like the installer to check to see if another application is already installed on the user's machine. If it is, then I'd like to set the install level of one of the features to "1", otherwise it should remain hidden (i.e. install level = 0). To find out where the application is installed, I first do a registry search:
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'/>
</Property>
You'll notice that the registry value that I end up getting is actually the directory of the installed application including the actual program name with extension (let's say myapp.exe). So, once I get the full path of the installed application, I check to see if the file exists:
<Property Id="MYAPPINSTALLED">
<DirectorySearch Id="CheckFileDir" Path="[MYAPPINSTALLFOLDER]" AssignToProperty="yes">
<FileSearch Id="CheckFile" Name="myapp.exe" />
</DirectorySearch>
</Property>
Now, what I would expect to see is that if the file actually exists in that location, then the Property called "MYAPPINSTALLED" would be set to 1, otherwise it would be 0. Then, when I setup my features I use something like this:
<Feature Id="ThirdPartyPlugins" Title="Third Party Plugins" Level="0">
<Condition Level="1">MYAPPINSTALLED</Condition>
<ComponentGroupRef Id="MyAppPlugin" />
</Feature>
However, when I run my installer the third party plugin feature is always hidden. I've enabled msi datalogging by setting the property like this:
<Property Id="MsiLogging" Value="voicewarmupx"/>
And when I check the log file I can definitely see that the MYAPPINSTALLFOLDER property gets changed to the correct file path when it does the registry search. However, if I search the log for the property MYAPPINSTALLED, then I can see the following:
AppSearch: Property: MYAPPINSTALLED, Signature: CheckFileDir
Action ended 15:55:06: AppSearch. Return value 1.
So, it looks like it worked, however it doesn't seem to ever set the Property to equal the search value. Am I doing something wrong? Can someone explain why my feature install level never gets set to 1 even though the application file exists?
Edit
Ok, after more debugging... I think the issue is that the directory search is trying to use a path that includes the file name and extension (i.e. C:/Program Files/MyApp/myapp.exe") instead of just the directory where the file comes from. This is because the registry search has the full path including the file name stored (but not just the install directory). If I do a directory search just using the correct absolute directory (not using the registry search) then the process works. So, my follow up question is... my Property MYAPPINSTALLFOLDER contains the full path with file name and extension. Is there a way to strip the file name and extension from this property so that I just have the proper directory name to search for?
You're checking to see if another application is installed but that's rather a long way around. Also, the file search returns a path, not zero or 1, but either way a full verbose log should tell you if the properties are being set. It might help if you could post the entire log somewhere rather than the parts you think are the only relevant ones. e.g. There's probably an AppSearch in the execute sequence for silent installs.
It's requently easier to do a single search for other applications that were installed with MSI packages in these ways:
If you know the other product's UpgradeCode (and version ranges if applicable) then add Upgrade/UpgradeVersion elements with onlydetect set to yes, and that search will set a property if the product is detected.
If you know (or can find out) the Component id of any of the relevant components from that other product, then you can use them in a WiX ComponentSearch. If you get the target property set then that component is installed. This post contains a couple of ways to find out component guids:
How to find out which application requires a certain assembly from GAC?
It's also puzzling that the AppSearch log extract you posted only refers to one property. The Directory/FileSearch is also an AppSearch, so if the MSI actually contains two searches in AppSearch there should be references to all the properties being set. Again, that's a reason to post the entire log and look in the MSI file for those searches. The RegLocator search is documnented to occur before the DRLocator, so why is there no MYAPPINSTALLFOLDER property in the AppSearch log entry? You're not on a 32-bit system are you? (noticing the win64 search).
Per the WiX documentation:
Use the AssignToProperty attribute to search for a file but set the outer property to the directory containing the file. When this attribute is set to yes, you may only nest a FileSearch element with a unique Id or define no child element [of the DirectorySearch].
I added the text in the brackets to make it more clear.
So, after reading this sentence a few times and cross referencing your WiX XML, I think I see what the problem is with your current WiX XML. You perform a separate registry search from the directory search. Instead, you should nest these. There are two ways to perform the search, depending on what you want to do. One way is to simply retrieve the registry value from the registry, and if the value exists, then you make the assumption that the feature's required application is installed, at which point you appropriately set a property that would enable hiding/showing the feature within your installer's feature selection tree. The other way is to actually find the file you're interested in, using the results of the registry search as the basis for the file search.
Below is the XML for just a registry search, which doesn't check that the file actually exists on disk. You're making the assumption that if this registry value exists, the file is installed and available.
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'/>
</Property>
<Property Id="SHOW_APP_FEATURE" Value="hidden" />
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<!-- If MYAPPINSTALLFOLDER is defined and contains any non-empty value, this
evaluates to TRUE; otherwise, it evaluates to FALSE.
-->
MYAPPINSTALLFOLDER
</SetProperty>
<!-- You could also be more explicit:
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<![CDATA[MYAPPINSTALLFOLDER <> ""]]>
</SetProperty>
-->
<Feature Id="MyAwesomeFeature" Title="My Awesome App Feature"
Display="[SHOW_APP_FEATURE]">
... <!-- Component/ComponentRefs go here -->
</Feature>
If you want to ensure that, even if the registry value exists in the registry, that the file it points to is 1) actually a file path; and 2) that the file actually exists on disk, then you need to perform a nested file search within a directory search, which itself is nested within a registry search. You would again need to use a SetProperty custom action to set a property that would enable the hiding/showing of the feature within your installer's feature selection tree. Here's the XML for this search:
<!-- Performing a FileSearch nested within a DirectorySearch,
which is itself nested within a RegistrySearch
This search twill ensure that the file exists on disk, and
if so, assign the full filename and path to the
MYAPPINSTALLFOLDER property.
-->
<Property Id="MYAPPINSTALLFOLDER">
<RegistrySearch Id='InstallPathRegistry'
Type='raw'
Root='HKLM'
Key='SOFTWARE\SomeLongAppPath' Name='FileName'
Win64='yes'>
<DirectorySearch Id='InstallPathDirectory' AssignToProperty='yes'>
<FileSearch Id='InstallPathFile' Name='myapp.exe' />
</DirectorySearch>
</RegistrySearch>
</Property>
<Property Id="SHOW_APP_FEATURE" Value="hidden" />
<SetProperty Id="SHOW_APP_FEATURE" Value="collapse" Sequence="both" After="CostFinalize">
<!-- If MYAPPINSTALLFOLDER is defined and contains any non-empty value, this
evaluates to TRUE; otherwise, it evaluates to FALSE.
-->
MYAPPINSTALLFOLDER
</SetProperty>
<Feature Id="MyAwesomeFeature" Title="My Awesome App Feature"
Display="[SHOW_APP_FEATURE]">
... <!-- Component/ComponentRefs go here -->
</Feature>
This should allow you to accomplish what you're trying to achieve.
I am trying to edit an XML file with Wix. I am using the WixUtilExtension bundled with Wix 3.7. The xml file is a settings file created in Visual Studio 2010 for a C# application. In this file, I am using an element which is used to store multiple string values in an array. This is the content of the unaltered settings file:
<configuration>
<applicationSettings>
<AppName.Properties.Settings>
<setting name="StringArray" serializeAs="Xml">
<value>
<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
</ArrayOfString>
</value>
</setting>
</AppName.Properties.Settings>
</applicationSettings>
</configuration>
I want to add <string> elements to the <ArrayOfString> element in this file. One way to do this is by using an <XmlConfig> element from the wix/UtilExtension namespace. I have added this element to the component which holds the config file like this:
<Component Id="ProductComponent" Guid="$(var.ConfigGuid)">
<File Source="SettingsFile.exe.config" KeyPath="yes" Id="FILE_config" />
<util:XmlConfig
Name="string"
Value="My value"
File="[INSTALLFOLDER]SettingsFile.exe.config"
Id="String1"
On="install"
Action="create"
Node="element"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="100"
/>
</Component>
This results in the addition of one <string> element to the <ArrayOfString> element. To add another <string> element to the settings file, another XmlConfig element has to be added to the <Component> element of the setup project with a different Id attribute and a higher value for the Sequence attribute like this:
<util:XmlConfig
Name="string"
Value="My second value"
File="[INSTALLFOLDER]SettingsFile.exe.config"
Id="String2"
On="install"
Action="create"
Node="element"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="101"
/>
After installation of the msi, the <ArrayOfString> element in the settings file looks like this:
<ArrayOfString xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:xsd="http://www.w3.org/2001/XMLSchema">
<string>My value</string><string>My second value</string></ArrayOfString>
I have found out that it is possible to set the Value attribute of an <XmlConfig> attribute to the value of a property like this:
<Property Id="STRING1VALUE" Value="My value" />
<util:XmlConfig Value="[STRING1VALUE]" ... />
This is good. I would like the user to be able to add multiple values in the installation process dynamically so that a variable amount of <string> elements can be added to the settings file.
My first approach was to use a <?foreach?> statement like this:
<?define values="My value;My second value"?>
<?foreach value in $(var.values)?>
<util:XmlConfig
Name="string"
Value="$(var.value)"
File="[INSTALLFOLDER]SettingsFile.exe.config"
Id="String$(var.value)"
On="install"
Action="create"
Node="element"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="101"
/>
<?endforeach?>
There are a few problems with this approach:
The foreach statement uses a preprocessor variable which cannot be set to the value of a property.
The value of the Sequence attribute stays the same.
I would like the user to store the values for the string elements in a Property which separates the values by semicolons and then parse them in a foreach statement like this:
<Property Id="VALUES" Value="My value;My second value" />
<?foreach value in [VALUES]?>
<util:XmlConfig
Name="string"
Value="$(var.value)"
File="[INSTALLFOLDER]SettingsFile.exe.config"
Id="String$(var.value)"
On="install"
Action="create"
Node="element"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="101"
/>
<?endforeach?>
This throws the following error:
The util:XmlConfig/#Id attribute's value, 'String[VALUES]', is not a legal identifier.
Identifiers may contain ASCII characters A-Z, a-z, digits, underscores (_), or periods (.).
Every identifier must begin with either a letter or an underscore.
Is there any way I can create a variable amount of elements with the XmlFile or the XmlConfig element? Is the only solution to this problem a CustomAction?
Based on Rob's answer, here is my new approach to adding multiple elements to an XML config file with Wix. I did not want to write C++ code, that is why I used DTF in my CustomAction.
I am going to describe how to turn a string containing multiple elements using a delimiter into multiple XML elements.
First there needs to be a property in the setup file containing the delimited string.
<Property Id="STRINGARRAY" Value="string1;string2;string3" />
This property could be populated by the user in a dialog, of course.
Next, a CustomAction has to be written. To make use of the DTF, a reference to the Microsoft.Deployment.WindowsInstaller.dll has to be added to the C# CustomAction project. The namespace Microsoft.Deployment.WindowsInstaller should be included with a using directive in that project. My CustomAction looks like this:
[CustomAction]
public static ActionResult Insert(Session session)
{
string strings = session["STRINGARRAY"];
string[] stringArray = strings.Split(';');
Database db = session.Database;
View view = db.OpenView("select * from `XmlConfig`");
string xpath = "/configuration/applicationSettings/AppName.Properties.Settings/setting[\\[]#name='StringArray'[\\]]/value/ArrayOfString";
for (int i = 0; i < stringArray.Length; i++)
{
string id = String.Format("String{0}", i);
int sequence = 100 + i;
string value = stringArray[i].Trim();
Record rec = new Record(
id,
"[INSTALLFOLDER]SettingsFile.exe.config",
xpath,
null,
"string",
value,
273,
"ProductComponent",
sequence);
view.InsertTemporary(rec);
}
db.Close();
return ActionResult.Success;
}
Here, at first the Property StringArray is read into a local variable which is converted to a string array. The following line establishes a connection to the current database used by the installer. A handle on the table XmlConfig is created, which is the table where the XML elements are added to. To insert the right values into that table, it is best to create an installer file which contains such a table and then take a look at that table in an editor like orca or InstEd.
In the xpath, backslashes have to be escaped by using double backslashes. The id variable holds the name of the temporary record, using a simple string and a number works flawlessly. The sequence has to be incremented for each element. I could not find any documentation on the values of the flags column, but I have found out that its value is set to 273 for elements that are created and 289 for elements that get deleted.
Once the record is filled with the correct values, it gets added to the XmlConfig table by using the InsertTemporary method of the view object. This is done for each element found in the delimited string.
A problem I have come across is that this CustomAction fails, if the XmlConfig table does not exist. To counter this problem I have added the following code to the setup file, which adds an element to the XML file and immediately deletes that element. I guess there could be a cleaner solution, but this was the easiest one for me.
<util:XmlConfig
Name="string"
Value="Dummy"
File="[INSTALLFOLDER]SettingsFile.exe.config"
Id="DummyEntry"
On="install"
Action="create"
Node="element"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="1" />
<util:XmlConfig
On="install"
Action="delete"
Id="DeleteDummyEntry"
Node="element"
File="[INSTALLFOLDER]SettingsFile.exe.config"
VerifyPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString/string"
ElementPath="/configuration/applicationSettings/AppName.Properties.Settings/setting[\[]#name='StringArray'[\]]/value/ArrayOfString"
Sequence="2" />
Finally, the CustomAction has to be added to the setup project. By adding a reference to the CustomAction project in the setup project, the location of the binary can be specified like this:
<Binary Id="XmlCustomActionDLL" SourceFile="$(var.XmlCustomAction.TargetDir)XmlCustomAction.CA.dll" />
The CustomAction has to be executed immediately, otherwise it won't be able to access the session variable:
<CustomAction Id="CA_XmlCustomAction" BinaryKey="XmlCustomActionDLL" DllEntry="Insert" Execute="immediate" Return="check" />
<InstallExecuteSequence>
<Custom Action="CA_XmlCustomAction" Before="RemoveRegistryValues" />
</InstallExecuteSequence>
To determine the right position for the CustomAction in the installation sequence, I relied on this article by Bob Arnson.
Yes, this is possible but if you want to have this determined at install time then the preprocessor is not an option. The preprocessor executes during the build process.
To get what you want, you'll need to write another custom action that takes the arbitrarily long set of user data and adds temporary rows to the XmlConfig table. The WcaAddTempRecord() function in src\ca\wcautil\wcawrap.cpp can do the work. The src\ca\wixca\dll\RemoveFoldersEx.cpp is a pretty good example of using WcaAddTempRecord() to add rows to the RemoveFile table. You'll want to do similarly.