I am trying to create a multi-instance setup and followed this question and answers to make it:
Use WIX to install side by side versions of the same IIS site
So I inserted this to my product.wix file
<InstanceTransforms Property="INSTANCEID">
<Instance Id="I01" ProductCode="{68E8345E-0B22-479C-B7A5-7D1B3DC2F835}" ProductName="My Product 01"/>
<Instance Id="I02" ProductCode="{A0E37B8D-12AB-42A0-8F11-9CB08F54B9DE}" ProductName="My Product 02"/>
</InstanceTransforms>
However, when I build my setup project, I get this error:
Unresolved reference to symbol 'Property:INSTANCEID' in section
'Product:{38EEE9BE-86BF-49FB-813B-953DD945575E}'.
Where 38EEE9BE-86BF-49FB-813B-953DD945575E is my main Product Id.
I could not find any reference to this error in the InstanceTransform scope. What am I doing wrong?
UPDATE:
The first thing I tried when I got this error was of course creating a property inside my product with that is called INSTANCEID and some value. However, the error persisted.
I added the Yan's code from his comment below and it compiled. I am not sure what was wrong with my property.
You need a Property element with the Id of your InstanceTranforms/#Property value.
Related
I am facing issue for RegistrySearch for multistring, where as string search working fine.
Checked in installation logs
Action start 13:40:07: AppSearch. MSI (s) (40:E0) [13:40:07:381]:
PROPERTY CHANGE: Adding MYKEY property. Its value is ''. MSI (s)
(40:E0) [13:40:07:381]: PROPERTY CHANGE: Adding MYSERVICE property.
Its value is 'myvalue2'.
I have trimmed some logs here
Action ended 13:40:51:
ScheduleReboot. Return value 1. Action ended 13:40:51: INSTALL. Return
value 1. You must restart your system for the configuration changes
made to XXXXX to take effect. Click Yes to restart now or No if you
plan to manually restart later. Property(S): UpgradeCode =
{XXXXXX-XXXX-XXX-XXXX-XXXXXXXX}
Property(S): MYKEY = [~]myvalue1[~] Property(S): MYSERVICE = myvalue2
At end of installation it seems it has correctly evaluated the MYKEY but not during AppSearch, resulting in failing my Condition evaluation
<Feature Id="MyFeature" Level="" Display="" Title="" Description="" AllowAdvertise="no" ConfigurableDirectory="INSTALLDIR">
<MergeRef Id="MyFeature" Primary="yes"/>
<Condition Level="0">((MsiNTProductType=1) OR
(MYKEY="[~]MyValue[~]") OR
(MYSERVICE="MyService" AND MYKEY=""))</Condition>
</Condition>
</Feature>
<Property Id="MYKEY" Secure="yes">
<RegistrySearch Id="MyKey"
Root="HKLM"
Key="SYSTEM\CurrentControlSet\Services\MyService"
Name="mykey"
Type="raw" />
</Property>
<Property Id="MYSERVICE" Secure="yes">
<RegistrySearch Id="MYSERVICE"
Root="HKLM"
Key="SYSTEM\CurrentControlSet\Services\MyService"
Name="DisplayName"
Type="raw" />
</Property>
UPDATE: I might have missed you stating it already, but when checking whether the property set by the AppSearch search has any assigned value at all using simply PROPERTYNAME as condition, the condition shows up as true - meaning that "something" exists in the property in question, the text is just not displayed.
Is it sufficient to test just for the presence of a value, or do you need to check the specific value of MYKEY? If the mere presence of a value is enough, then you may be able to use this condition:
((MsiNTProductType=1) OR (MYKEY) OR (MYSERVICE="MyService" AND MYKEY=""))
I guess this answer from Rob Mensching from the WiX-users mailing list answers the question with certainty. Multi-string is simply not supported for AppSearch.
There is no need to doubt the accuracy of this since Rob was on the original MSI team. You need to abandon this approach. Sorry to say. Unless the above workaround that I just added could work (check not the value, but if there is a value at all being retrieved from the registry).
A couple of other, potential workarounds:
You could read the multi-string from a custom action. I just verified that it works with a test VBScript - the forbidden MSI tool :-).
Could you search for a file or directory on disk that would signify the same thing you retrieve from the registry with this multi string?
As my motto goes every now and then: let's obsess over this (as opposed to: "careful, we don't want to learn from this" - which is another motto of mine - which tends to be the better option).
It is truly odd, that I can replicate what you state about your log file. I see a CommandLine entry which shows the multi-sting correctly, albeit with several extra null characters (slightly shortened log entry):
CommandLine: NORMALSTRING="sample regular string" MULTISTRING="[~~~]String 1[~~~]String 2[~~~]String 3[~~~]" INSTALLFOLDER="C:\Program Files (x86)\WiX3_GenericTestProject\" TARGETDIR="C:\" ACTION="INSTALL" EXECUTEACTION="INSTALL" ROOTDRIVE="C:\" INSTALLLEVEL="1" SECONDSEQUENCE="1" ADDLOCAL=Empty,Modules,ProductFeature
and also, later in the log file, after InstallFinalize:
Property(S): MULTISTRING = [~]String 1[~]String 2[~]String 3[~]
I really don't understand how that comes about. Somehow the AppSearch must have really set the property in question even if it didn't look like it did - the property just can't be retrieved correctly (or formatted correctly), and hence doesn't work in (feature) conditions either?
Maybe the underlying data model in Windows Installer has stored the retrieved registry multi string value as a BSTR (the abomination of a COM string format which allows embedded nulls and can be compiled and linked without being properly allocated / constructed via SysAllocateString - "burnt child, smells burnt - and all that...").
Anyway, I suppose AppSearch expectes a regular, null-terminated string buffer and interprets the BSTR as such? Hence stumbling on the first null value which is the first character of the data string section of the BSTR (not the length prefix section - the BSTR pointer points 4 bytes into the allocated BSTR memory) and reports an empty string overall? The property values that show up in the log file must have been read directly from the underlying data model by other means? I would assume the MSI Win32 C++ functions? But wouldn't that also be the case for AppSearch? Something is wrong with how this property string - with embedded nulls - is being displayed and used in conditions.
So in summary: maybe the retrieval of the multi string actually works, but the exposed value via Session.Property("PROP") erroneously reads the potential, native BSTR as a null-terminated string buffer and interprets the leading null as the end of the string buffer? Sort of doesn't make sense considering Session.Property is a COM call and should definitely understand a BSTR? Theories like these are never correct, but maybe they can help create some new ideas at least. What seemed like a missing Windows Installer feature, sort of smells like a bug I think. Or as it is in the real world: a technical problem, not easily fixed and hence seen and accepted as a missing feature.
Let me link together your questions on this issue for reference (and a couple of other answers):
RegistryValue Element of type multiString.
Failing condition wix.
Passing multiString values to installer through command-line.
The aim is that if the value isn't found in the registry then I want to assign a default value and then have that value display as the default value in a field in the installer UI. The default value I actually want to use is [ComputerName] but obviously I can't use [ComputerName] directly in the property value attribute because it will give me errors on compiling, specifically:
warning CNDL1077: The 'MYPROPERTY' Property contains '[ComputerName]'
in its value which is an illegal reference to another property. If
this value is a string literal, not a property reference, please
ignore this warning. To set a property with the value of another
property, use a CustomAction with Property and Value attributes.
I want to get it working with plain text before I even try [ComputerName] but so far I can't even get that working.
In my project I have a Product.wxs file which contains the Product element, lots of custom actions (most of which are running fine but they're all running significantly later) and the following elements which are not cooperating and which are all siblings under the Product element.
Property definition and registry search:
<Property Id="MYPROPERTY" Value="ADefaultValue">
<RegistrySearch Id="MyProperty" Type="raw" Root="HKLM" Win64="$(var.Win64)"
Key="Software\MyCompany\MyApplication" Name="MyProperty" />
</Property>
Custom action definition:
<CustomAction Id="SetMyPropertyDefault" Property="MYPROPERTY" Value="MyCustomValue" Execute="immediate"/>
Custom action execution:
<InstallExecuteSequence>
<Custom Action="SetMyPropertyDefault" After="AppSearch"><![CDATA[MYPROPERTY="ADefaultValue"]]></Custom>
</InstallExecuteSequence>
It just will not work for me at all.
For the custom element content I have tried:
<Custom Action="SetMyPropertyDefault" After="AppSearch"><![CDATA[MYPROPERTY="ADefaultValue"]]></Custom>
<Custom Action="SetMyPropertyDefault" After="AppSearch">1</Custom> // I thought this would always run the custom action.
<Custom Action="SetMyPropertyDefault" After="AppSearch">NOT MYPROPERTY</Custom> // Back when I wasn't using the default value on the property at all.
The result is always the same, I'm still getting "ADefaultValue" showing up in the UI, never the alternate "MyCustomValue".
According to every blog and SO post I've seen I'm doing exactly what I should be doing except clearly I'm missing something.
Any ideas?
UPDATE/Answer:
The piece of information that I was missing which was provided by #sutarmin-anton was that InstallUISequence runs before InstallExecuteSequence (seems counter-intuitive to me but there you go).
But as it happened I didn't need to explicitly duplicate the custom action call in each of the install sequence elements, instead I used the SetProperty element.
So now I've got the following in my Product.wxs as children of the Product element:
<Property Id="MYPROPERTY">
<RegistrySearch Id="MyProperty" Type="raw" Root="HKLM" Win64="$(var.Win64)" Key="Software\MyCompany\MyApplication" Name="MyProperty" />
</Property>
<SetProperty Id="MYPROPERTY" After="AppSearch" Value="[ComputerName]">NOT MYPROPERTY</SetProperty>
It now runs the SetProperty after AppSearch in both InstallUISequence and InstallExecuteSequence, but the second time it runs the NOT MYPROPERTY will come out false so it doesn't get reset, and of course if it's run in quiet mode it'll still work correctly.
When you going through installer UI, installation is in InstallUISequence. InstallExecuteSequence runs after all UI events. This is cause of you have not seen "MyCustomValue". To change your property before UI sequence you should place your custom action in "InstallUISequence".
By the way, why don't you set default value of your property to "MyCustomValue"? Then, if AppSearch wont find value in regisrty, it just leave default value that you are trying to set manually.
You may be overcomplicating things. The MYPROPERTY value will not be set at all if you don't set a default. So then you call your CA to set it if 'NOT MYPROPERTY'
I see that you've tried this, and I'd say it's the correct approach that I'd try to diagnose rather than try something else. A verbose log would be invaluable. Do a:
msiexec /i [path to msi] /l*vx [path to a text log file]
and see what CA is called, what AppSearch does, property values etc.
Your original comment of "I can't use [ComputerName] - if that's the problem why not tell us what happened and maybe there is a solution that doesn't require all this. What's the compile error, for example?
We can get the productversion in wix using !(bind.fileVersion.Product.exe). This returns the version as 3.8.2363.0. How can I get the version up to build version, i.e. 3.8.2363.
I followed Binding WIX FileVersion sub values? this link, but using
"!(bind.property.ProductVersion.Major)" do not solve my problem.
<?define ProductVersion123="!(bind.fileVersion.mainexe_dll)" ?>
<Product Id="{7BDF78BF-95E8-4ABB-8A0F-4A1483D7FDD1}" Name="SpreadsheetConverter !(bind.property.ProductVersion123.Major)" Language="1033" Version="!(bind.property.ProductVersion123.Major)" Manufacturer="ABC" UpgradeCode="$(var.ProductUpgradeCode)" Codepage="1252">
This gives error:
Unresolved bind-time variable Mainexe !(bind.property.ProductVersion123.Major).
Please Help.
Thanks
You have to realize what !(bind.property.X) does. It retrieves the value of the X property from the MSI's Property table. You have not setup a ProductVersion123 property in the MSI, you have created a WiX preprocessor variable ProductVersion123.
So what you have to do is assign the Product's Version attribute to $(var.ProductVersion123) (which sets the ProductVersion property of the MSI). Now you can access that with !(bind.property.ProductVersion), including the !(bind.property.ProductVersion.X) extensions.
One of my goals in creating the bootstrap project is to set a default log location. I would like the location to be based on the local app data folder. I cannot figure out how to reference the builtin Burn variable LocalAppDataFolder. I have found information about how to reference these variables in code, but not in the xml.
The reference to the property looks like this:
<MsiPackage SourceFile="MyInstaller.msi" LogPathVariable="[LogLocation]" />
The property is set like this:
<Variable Name="LogLocation" Value="[LocalAppDataFolder]MyLogFolder\Setup" Type="string"/>
The log output shows:
Initializing string variable 'LogLocation' to value
'[LocalAppDataFolder]MyLogFolder\Setup'
What am I missing to resolve [LocalAppDataFolder] ?
thanks in advance.
It's normal for the log output to show the un-formatted value, so that part looks correct. I think what you are missing is LogPathVariable should be specified without the brackets.
<MsiPackage SourceFile="MyInstaller.msi" LogPathVariable="LogLocation" />
I want to set a property in a custom action and use it in the standard custom action "util:User" afterwards. But no matter where I put the property in my wxs-file, I always get "error LGHT0094 : Unresolved reference to symbol"
Details:
In my setup I want to add a new user by using util:User. The user should be added to the group "Power Users" by using util:GroupRef. No Problem so far. Unfortunately the group names are language dependent. In german "Power Users" is "Hauptbenutzer". So I want to look up the well known SID S-1-5-32-547 in a custom action, set a property in this custom action by calling MsiSetProperty and then use the property for util:GroupRef.
As far as I understand, the property must be declared somewhere in the wxs-file.
In the examples I found, the property was never declared as follows (but I also tried that):
<Property Id="TextSID" Value="Power Users" />
In the examples there always was a custom action to set the property, like:
<CustomAction Id="SetTextSID"
Property="TextSID"
Value="Power Users"
Return="check" />
My problem is, that the creation of the user fails to "compile" because the property "TextSID" is not known:
<Component Id="CreateUser" Guid="Some GUID here in my original wxs file">
<util:User Id="UserUser"
Name="User" Password="Password"
CanNotChangePassword="yes" PasswordNeverExpires="yes">
<util:GroupRef Id="TextSID" />
</util:User>
</Component>
I have never done a custom action before and I'm a new to WiX and MSI, so any idea would be very welcome.
Regards
Ralf
Sorry for wasting your time.
I stared at my XML for hours before I posted this question, just to find the answer immediately after my post :-(
My only problem was, that it is not possible to reference to something that isn't there. In this case the "util:Group" was missing.