I have been searching the internet for an answer on this registry search issue.
I have a bigger wix file but i could not get multiple features working and its the conditioning of the features so I have created a basic test wix document to understand the features of wix but can not get the result i required.
The code is as follows:
<Property Id="BASICTEST" Secure="yes" >
<RegistrySearch Id="_Regsearch_Basic" Root="HKLM"
Key="SOFTWARE\TGSL\BasicInstaller" Name="BASIC1" Type="raw" >
</RegistrySearch>
</Property>
<Property Id="BASICTEST1" Secure="yes" >
<RegistrySearch Id="_Regsearch_Test" Root="HKLM"
Key="SOFTWARE\TGSL\BasicInstaller" Name="TEST1" Type="raw" >
</RegistrySearch>
</Property>
<Feature Id="BasicFeature" Title="BasicFeat" Level="0">
<Condition Level="1">NOT (BASICTEST="0")</Condition>
<ComponentRef Id="BasicTest"/>
</Feature>
<Feature Id="TestFeature" Title="TestFeat" Level="0" >
<Condition Level="1">NOT (BASICTEST1="0") </Condition>
<ComponentRef Id="BasicTest1"/>
</Feature>
I have set up four registry entries, all values are 1 (BASIC1=1 and TEST1=1) to test which registry it is using (either 2 in SOFTWARE\TGSL\BasicInstaller for 64bit or 2 in SOFTWARE\TGSL\BasicInstaller for 32bit)
I know it defaults to 32bit unless otherwise stated but still nothing. I was using process monitor to test to see if my .msi file was reading the registry...which it isnt.
I created a log file when installing the .msi and i get a error code when reading the registry:
AppSearch: Property: BARRIETEST, Signature: _Regsearch_BarrieTest1
Note: 1: 2262 2: Signature 3: -2147287038
Note: 1: 1402 2: HKEY_LOCAL_MACHINE32\SOFTWARE\TGSL\BasicInstaller 3: 2
The error code is not finding the file but it looks like it is looking in a directory that doesnt exist and when i change it to win64="yes" it takes away the 32 after the HKEY_LOCAL_MACHINE.
I have tried building this test script in wix 2.0 and it searches the registry fine and it changes the property to the value of the registry key "1" so i am in a quandary as to what im doing wrong??
Is there a difference between the registry search parameters between wix 2.0 and wix 3.5?
Can anyone suggest a possible fix or how i can get these features working?
Please help...thank in advance
For closure, as indicated in the question comments, this was a permissions issue where the user running the setup installer did not have enough privileges to access HKEY_LOCAL_MACHINE.
Related
I have a wix project and inside it I am checking whether c++ redist 2015 is installed or not as followings:
<Property Id="CPP2015REDISTX64">
<RegistrySearch Id="CPP2015RedistX64_RegKey" Type="raw" Root="HKLM"
Key="SOFTWARE\Microsoft\VisualStudio\14.0\VC\VCRedist\x64"
Name="Installed"
Win64="yes"/>
</Property>
<Condition Message='[Error Message]'>
CPP2015REDISTX64
</Condition>
When I try to install the package it shows me an error,but when I check my computer registries I can see it installed
I am wondering what's wrong with my code (I know that if the value of the Installed key is found it will proceed with the installation process and the condition will evaluate to true)
According to MSDN page Redistributing Visual C++ Files, the correct registry key to check is:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\14.0\VC\Runtimes\x64
That matches what I see on my machine using regedit.exe.
So replace "VCRedist" by "Runtime". Also make sure that you specify -arch x64 on the candle.exe command-line (alternatively set Package/#Platform="x64", but the docs state that "use of this attribute is discouraged").
I'm trying to optionally install a virtual directory if IIS is installed. If it's not installed, then just skip it.
I've got this check:
<Fragment>
<Property Id="IIS_MAJOR_VERSION">
<RegistrySearch Id="CheckIISVersion"
Root="HKLM"
Key="SOFTWARE\Microsoft\InetStp"
Name="MajorVersion"
Type="raw" />
</Property>
<iis:WebSite Id='DefaultWebSite' Description='Default Web Site' Directory='INSTALLFOLDER'>
<iis:WebAddress Id="AllUnassigned" Port="80" />
</iis:WebSite>
</Fragment>
and based on the IIS_MAJOR_VERSION being present, I install the feature:
<Feature Id="ProductFeature2" Title="Setup" Level="1">
<ComponentRef Id="AppIIS" />
<Condition Level="0">NOT IIS_MAJOR_VERSION</Condition>
</Feature>
This part seems to work, however, the iis:WebSite node is causing issues. I only want to locate it if IIS_MAJOR_VERSION is present as well.
If I move the iis:WebSite node into the component group it works, but then iis:WebSite is not in 'locator' mode and gets installed and uninstalled (which is bad).
Is there a way I can conditionally run the check for iis:WebSite?
When you add any element from IIS extension (like <iis:WebSite>), a special custom action called ConfigureIIs is added to the InstallExecuteSequence table. This custom action is a so-called entry point to everything related to IIS management with the help of WiX IIS extension.
Fortunately, ConfigureIIs custom action is conditioned by default the way to skip it if need be. If you open the resulting MSI package with Orca and navigate to InstallExecuteSequence table on the left pane, you'll see the condition uses SKIPCONFIGUREIIS property. Thus, the idea is to set it to something (e.g. 1) in case you don't need to perform any IIS related activities.
It can be done with SetProperty element:
<SetProperty Id="SKIPCONFIGUREIIS" Value="1">NOT IIS_MAJOR_VERSION</SetProperty>
How can I have a Feature depend on a system dependency (e.g. powershell), but still indicate to users that this feature is available in the installer.
Currently features are listed as follows (screenshot):
Feature List
My current idea is to put a condition on the feature:
<Property Id="POWERSHELL_3_INSTALLED">
<RegistrySearch Id="Powershell3Installed"
Root="HKLM"
Key="SOFTWARE\Microsoft\PowerShell\3"
Type="raw"
Name="Install" />
</Property>
<Feature Id="TestFeature"
Title="Test Feature"
Description="Test Feature Description. Note: This feature requires Powershell 3 or higher."
Level="1"
Absent="allow"
InstallDefault="local"
AllowAdvertise="no">
<Condition Level="0">
<![CDATA[(POWERSHELL_3_INSTALLED <> "#1") AND NOT REMOVE]]>
</Condition>
</Feature>
This does hide TestFeature for users without powershell installed, preventing them to install it, but this way users are not aware that this extra feature would be available if they would install powershell.
Any ideas how to achieve this?
The SelectionTree control in Windows Installer does not support showing disabled features. You would have to reimplement that -- for example, using checkboxes.
I'm trying to do an installer using wix 3.8. I can use custom properties to store my own input, but I'd like to use values that where inputs on a previously installed msi.
Is there a way to accomplish such thing?.
To get you in the right direction add this (of course adapt it to your needs first) in your fist MSI:
<DirectoryRef Id="INSTALLDIR">
<Component Id="RegistryEntries" Guid="{0AC76129-F8E2-47D3-B9FD-09B1E10A8541}">
<RegistryKey Root="HKLM" Key="Software\Company123\App123" Action="create">
<RegistryValue Type="integer" Name="SomeIntegerValue" Value="1" KeyPath="yes"/>
<RegistryValue Type="string" Name="UserInput" Value="[USERINPUT]" />
</RegistryKey>
</Component>
</DirectoryRef>
Don't forget reference the component in your <Feature> <ComponentRef Id="RegistryEntries" />
When you install assign a value to the property [USERINPUT] e.g. msiexec /i your.msi /qb+ USERINPUT="the value to be saved in registry"
Then in the second MSI add something like this:
<Property Id="READREGISTRY">
<RegistrySearch Id="USERINPUT_Value" Root="HKLM" Key="Software\Company123\App123" Name="UserInput" Type="raw" />
</Property>
The value/string you entered during installation USERINPUT= will be stored in your second MSI in the property READREGISTRY
Here a piece of log in my second msi:
PROPERTY CHANGE: Adding READREGISTRY property. Its value is 'testing registry wef wef wef w'.
Based on your installation where it might be Per User or Per Machine you may adjust the Root to HKCU for PerUser installs or leave it to HKLM for PerMachine.
For more information please refer to Wix documentation, hints: "How To: Write a Registry Entry During Installation" and "How To: Read a Registry Entry During Installation".
Generally, no. There is no requirement for a Windows Installer package to record the input it takes from the user. Some do record some information in the registry and you might choose to rely on finding it there.
As an alternative, you might find that the other installer can be run without a UI and can be sufficiently controlled with properties passed into it. If so, you can write your own UI (one way would be a custom WiX Bootrapper Application [example]) to gather the inputs before running the installer.
Create a custom action within the MSI which gets installed first, then either write the values/user entries that you want into a file or registry. Within your final MSI read the values from registry/file and use it.
Here is an example of how you can read a value from the user and update the your app.config, this is not an apple to apple scenario, but this will guide you through it.
http://bensnose.blogspot.com/2013/03/more-custom-actions-with-wix.html
Disclaimer: I havent tried out what is mentioned in this blog post, but I have done things very similar and found that it has good explanation, thats why I posted the link to it.
Can anyone tell me why this is not working please?
I have two registry checks to check if Visual C++ Redistributables are installed:
<Property Id="REGDBKEYEXISTX64">
<RegistrySearch Id="REGDBKEYEXISTX64" Root="HKLM" Key="Software\Microsoft\Windows\CurrentVersion\Uninstall\{837b34e3-7c30-493c-8f6a-2b0f04e2912c}" Name="Version" Type="raw" Win64="yes" />
</Property>
<!--Checking if Microsoft Visual C++ Redistributables are installed on a 32-bit system-->
<Property Id="REGDBKEYEXIST">
<RegistrySearch Id="REGDBKEYEXIST" Root="HKLM" Key="Software\Microsoft\Windows\CurrentVersion\Uninstall\{837b34e3-7c30-493c-8f6a-2b0f04e2912c}" Name="Version" Type="raw" Win64="no" />
</Property>
I then run a custom action if they are not installed:
<Custom Action="InstallRedistributables" After="GetVariantName">Installed OR REGDBKEYEXISTX64 OR REGDBKEYEXIST</Custom>
However when the redistributables are installed it still runs the custom action which is what i do not want. I know it detects it as this is my log file:
Property: REGDBKEYEXIST, Signature: REGDBKEYEXIST
MSI (c) (4C:44) [12:19:04:989]: PROPERTY CHANGE: Adding REGDBKEYEXIST property. Its value is '#134276921'.
So what could be the problem? I have this done on another custom action and it works perfectly so i really don't know the solution.
It appears your condition is reversed. The REGDBKEYEXIST properties will be set if the registry key exists, and thus true when the search indicates the redistributable is present. So what you probably want is more like NOT REGDBKEYEXIST You also probably only want to run this on first time install (hence your reference to Installed). So I would suggest changing your condition to something more like the following:
NOT(Installed or REGDBKEYEXIST or REGDBKEYEXISTX64)