When I add a Condition within a Feature to assure that IIS is installed, it is working as expected (it searches installed IIS, when feature is selected. No check, when feature is not selected):
<Feature Id="feat.WebApplication"
Title="Web Application"
Level="1"
ConfigurableDirectory="DIR.WEBAPP">
<Condition Level="0">
<![CDATA[Installed OR (IISMAJORVERSION AND IISMAJORVERSION >= "#7")]]>
</Condition>
<!-- ... -->
</Feature>
But - as documented in Condition Element - it is not allowed to have a message within the condition. So the installation silently fails, whereas it shows a message when the condition is placed directly in the Product node.
How can I show a message also for conditions within features?
As I understand the Condition node, after reading about the Level attribute of the Feature Element,
Sets the install level of this feature. A value of 0 will disable the feature. Processing the Condition Table can modify the level value (this is set via the Condition child element). The default value is "1".
by using Condition within feature you get the ability to disable or enable features depending on its own value for Level, because you can override it if the condition matches with the value of the Level attribute of the condition.
So the best would be to add some text about the precondition to the feature Description.
Related
I'm a novice WiX user, converting over several existing installations from a no longer maintained (.MSI-producing) commercial product.
As part of that I'm restructuring the original feature/component arrangements to take advantage of some of the new options WiX has opened up. One of these is adding Conditions at Feature rather than Component level, and as part of that I've tried specifying a conditional Feature like this (demo/test items throughout):
<Feature Id="Feature1" Title="Test Only" Level="0">
<Component Id="C1" Guid="*" Directory="SomeDir">
<File Id="File1" KeyPath="yes" Checksum="yes" Name="Test file.txt" Source="D:\xxx.dat" />
</Component>
<Condition Level="1"><![CDATA[INSTALLTYPE <> 1]]></Condition>
</Feature>
Where INSTALLTYPE is a Property defined at <Product> level and subsequently set to 0, 1 or 2 by the user via a RadioButtonGroup in the UI sequence.
Summarising what I've found after a day or so of trying different options and head-scratching:
With an initial Level=0, set to 1 by the condition (as in the sample above), the Feature is never installed.
With an initial Level=1, set to 0 by the condition, the Feature is installed when the condition is satisfied as long as an = test is used in the condition. If a INSTALLTYPE <> 1 is used, or Not (INSTALLTYPE = 1), the feature is never installed.
If a pre-defined Property (such as INSTALLLEVEL) is used in the test rather than my INSTALLTYPE, everything works correctly/as expected.
If equivalent tests are applied at Component, rather than Feature, level, everything works as expected for all Propertys and test operators.
Something seems to be going wrong with INSTALLTYPE but I can't for the life of me work out what. I've tried firing a VBScript custom action (MsgBox("INSTALLTYPE=" & Session.Property("INSTALLTYPE"))) in the Execute sequence to check the value of the Property, and as far as I can see this does display the value I'd expect it to have from the UI setting.
In principle I could get Features installing the way I want using the subset of settings I've found to work (e.g. INSTALLTYPE = 0 OR INSTALLTYPE = 2 rather than INSTALLTYPE <> 1), but my bafflement over apparently simple things not behaving as expected suggests I'm missing something fundamental...so I'm wary of just shrugging and applying workarounds.
If anyone has any thoughts on what I might be doing wrong with the items above, I'd be very happy to hear them!
I am trying to check two conditions during installation, but need to check it in series: if condition A is false - show error A, do not check condition B.
In details: I have to conditions checks
My app is installed
Version of database schema
If my app is not installed - I need to show an error message and do not check database schema, which leads to unknown error during install.
<Property Id="MYAPPINSTALLED">
<RegistrySearch Id="MyAppInstalledSearch"
Name="MyAppInstalled"
Root="HKLM"
Key="Software\MyApp\Installed"
Type="raw"
Win64="no" />
</Property>
<Condition Message="!(loc.RequireMyApp)">
<![CDATA[(MYAPPINSTALLED="1")]]>
</Condition>
<PropertyRef Id="GETSCHEMAVERSION"/>
GETSCHEMAVERSION is a Custom Action used in other components, which tries to connect to the Database and fails if MyApp is not present on the machine.
How can I check GETSCHEMAVERSION property only in case MYAPPINSTALLED condition pass?
Updated:
GETSCHEMAVERSION Custom Action is used in some other helper applications.
The second custom action, which checks for DB schema, should be conditioned to run only if the app is installed:
<Custom Action="CheckDbSchema">MYAPPINSTALLED="1"</Custom>
That custom action should set another property, as far as I understand, e.g. DBSCHEMAISOK to 1.
Then the components that depends on the schema to be available can be conditioned with MYAPPINSTALLED="1" And DBSCHEMAISOK="1".
I might be missing the syntax details, but you should get the idea.
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 install the features based on the condition. Initially i set the feature level to 1 and place a condition inside the feature to modify the feature level.
I am unable to modify the feature level and it is always set to 1 only irrespective of condition.
<Feature
Id = "AddinsFeature"
Title = "InstallAddin"
Level = "1"
Absent="allow">
<ComponentRef Id = "AddInComp"/>
<Condition Level="0">
<![CDATA[FALSE]]>
</Condition>
</Feature>
How to use WiX feature conditions is essentially explained here:
https://www.firegiant.com/wix/tutorial/getting-started/conditional-installation/
For a feature to be set to the level specified by your condition, the condition has to evaluate to true. You can force it to be true by setting it to 1:
<Feature Id="AddinsFeature" Title="InstallAddin" Level="1" Absent="allow">
<!-- Force condition to be true, which sets the feature to the Level attribute value -->
<Condition Level="0">1</Condition>
<ComponentRef Id = "AddInComp"/>
</Feature>
Above we force the feature's install level to 0 because its condition of 1 is true (the number 1 is true in MSI logic - by definition - as in boolean). In the real world the condition would be something much more complicated - of course.
Every setup has an overall INSTALLLEVEL - and it acts as a high water mark as explained here by Chris Painter. Every feature which evaluates to a feature level below or at the INSTALLLEVEL gets installed by default.
Note: When you set the Feature level to 0 in your WiX source, the feature is not show in the setup GUI and it is not
going to be installed by default either (more details in link below).
Feature manipulation can be very involved. A few links:
How to install feature based on the property set in custom action?
Unselected Feature Being Installed (over the top detailed)
Failing condition wix (Level=0 hides feature from GUI)
http://www.joyofsetup.com/2008/04/09/feature-states-in-component-conditions/
https://www.joyofsetup.com/2008/05/16/make-sure-features-are-always-enabled-so-they-can-be-removed/
You can ship the components present inside the feature by setting the condition 'True' like below. Whenever the property 'SAMPLEFEATURE_UNLOCKED' sets to true, the feature is unlocked.
I have an installer that deploys a website as either a SSL or non-SSL IIS site depending on whether a property is set or not. I've been asked to add the option to set the port, which isn't a problem, but I'd like to set the port to the default values (80 or 443) if the value isn't set.
I tried something like:
<SetProperty Id="OUTPORT" Before="InstallFiles" Value="80"><![CDATA[SSL=0]]></SetProperty>
<SetProperty Id="OUTPORT" Before="InstallFiles" Value="443"><![CDATA[SSL=1]]></SetProperty>
But, obviously, WiX complains about the custom action having the duplicate ID SetOUTPORT.
Am I jumping down another WiX-shaped rabbit hole here?
The accepted answer is not correct in needing to convert to writing out in full the custom action and sequencing (no longer?).
As per documentation for WiX 3, SetProperty Element
Without setting SetProperty\#Action
<SetProperty Id="OUTPORT" Before="InstallFiles" Value="80"><![CDATA[SSL=0]]></SetProperty>
<SetProperty Id="OUTPORT" Before="InstallFiles" Value="443"><![CDATA[SSL=1]]></SetProperty>
Duplicate symbol 'CustomAction:SetInstallFiles' found
Action. String. By default, the action is "Set" + Id attribute's value. This optional attribute can override the action name in the case where multiple SetProperty elements target the same Id (probably with mutually exclusive conditions).
The following works without having to change to writing out custom actions.
<SetProperty Action="SetInstallFiles0" Id="OUTPORT" Before="InstallFiles" Value="80"><![CDATA[SSL=0]]></SetProperty>
<SetProperty Action="SetInstallFiles1" Id="OUTPORT" Before="InstallFiles" Value="443"><![CDATA[SSL=1]]></SetProperty>
It works in WiX 3.7, and I am not sure about which first version it is available from.
SetProperty now supports the Action attribute to let you specify custom action ids when you want to have multiple SetProperty elements for the same property with different conditions.