[wix-devs] Testing late-bound properties

Ron Martin cpuwzd at comcast.net
Sat Apr 17 20:31:50 PDT 2021


Sean, I must correct one sentence in my previous message: "It does not 
generate an error or a warning, but it remains in its unresolved state." 
I should have said: Each failed resolution generates an 
UnresolvedBindReferenceError(298). Depending on whether or not I check 
for previous errors before before checking for duplicate CacheId's, I 
either see the UnresolvedBindReference errors or I see my duplicate 
CacheId error (because "!(bind.ProductCode.test.msi)" matches itself 
literally). Conceptually, if I were to replace test.msi with test1.msi 
and test2.msi, both having the same content as test.msi, the resolved 
variables would match, but the unresolved variables would not, 
demonstrating that the resolution was successful. I'm not sure where I 
saw bind.ProductCode or if I just imagined it. It might be useful if 
some or all of the properties of the msi file were accessible this way, 
but I haven't used Wix enough to know if I would ever use such a 
feature. I've replaced bind.ProductCode with bind.fileVersion in my code 
now. The results are still the same. Your original failing test was 
insufficient for testing the detection of duplicate CacheId's after late 
resolution because the late resolution code was not executed before the 
end of the test. I found and fixed a bug that caused an endless loop 
outputting the same error message over and over when an 
UnresolvedBindReference was found. The failing path did not move the 
source pointer past the point of failure before looping to find the next 
occurrence, which was then the same occurrence. I'm going to save this 
message as a draft while I look at issue 6431. I decided to try to 
remove file properties from my test by using Wix variables as follows: 
<Fragment> <WixVariable Id="WixVariable1" Value="The same old thing" /> 
<WixVariable Id="WixVariable2" Value="The same old thing" /> 
<PackageGroup Id="BundlePackages"> <ExePackage Id="Manual1" 
SourceFile="test.msi" Name="manual1\test.msi" DetectCondition="anything" 
CacheId="!(bind.WixVariable1)" /> <ExePackage Id="Manual2" 
SourceFile="test.msi" Name="manual2\test.msi" DetectCondition="anything" 
CacheId="!(bind.WixVariable2)" /> </PackageGroup> </Fragment> The errors 
remain the same as before, but its easier to find my way through the 
code now. I worked my way from Resolver.cs to ResolveFieldsCommand.cs, 
where I saw code collecting data from custom table cells. I saw code 
coming close to, but avoiding the variables and values established by my 
WixVariable statements. Unfortunately, none of these values get into 
variableCache. variableCache is conditionally created in 
BindBundleCommand.cs if there are any blanks to be filled in. The wix 
variables and their values, could be added at this point, but what if 
they need to be changed? The code that follows the comment: // resolve 
localization and wix variables seems to imply that Wix variables need an 
initial definition before that code is reached and a final definition 
before the delayed resolution takes place. I'm not sure how to sort out 
the chickens from the eggs. What's the last place that a Wix variable's 
value can be changed? Can it be done in an extension. What's the first 
place that such a value can be expected/demanded? Can Wix variables 
depend on other Wix variables? (This last seems very unlikely.) Should 
the code to pass along the initial values of Wix variables be outside 
all of the field-filling code? I'm done for the night. Ron

--------------------------------------------


On 4/17/2021 10:17 AM, Sean Hall via wix-devs wrote:
> Sorry if I confused you. I pointed them out to explain why the collision
> detection needs to be done later, you don't have to actually test them.
> Those are broken right now: https://github.com/wixtoolset/issues/issues/6431
>
> I'm not sure if ProductCode is a supported package bind variable. That
> might be a separate issue if it's really not generating any warning or
> errors and staying unresolved.
>
> On Sat, Apr 17, 2021 at 12:45 AM Ron Martin via wix-devs <
> wix-devs at lists.wixtoolset.org> wrote:
>
>> I'm having trouble coming up with a good scenario for testing late-bound
>> "properties". I'm trying to come up with an expression that requires
>> late binding to complete the definition of a CacheId. At the moment, I'm
>> using:
>>
>> <?xml version="1.0" encoding="utf-8"?>
>> <Wix xmlns="http://wixtoolset.org/schemas/v4/wxs">
>>       <Fragment>
>>           <PackageGroup Id="BundlePackages">
>>               <ExePackage Id="Manual1" SourceFile="test.msi"
>> Name="manual1\test.msi" DetectCondition="anything"
>> CacheId="!(bind.ProductCode.test.msi)" />
>>               <ExePackage Id="Manual2" SourceFile="test.msi"
>> Name="manual2\test.msi" DetectCondition="anything"
>> CacheId="!(bind.ProductCode.test.msi)" />
>>           </PackageGroup>
>>       </Fragment>
>> </Wix>
>>
>> This is late bound, but the symbol resolution fails. It does not
>> generate an error or a warning, but it remains in its unresolved state.
>> The test.msi file appears to be referenced, but not opened, according to
>> ProcMon.
>>
>> I can send more code if that will help. If my approach is wrong, I'd
>> appreciate your suggestions. There really is a paucity of good examples
>> that I can find via Google.
>>
>> Thanks.
>>
>> Ron
>>
>> ____________________________________________________________________
>> WiX Toolset Developer Mailing List provided by FireGiant
>> http://www.firegiant.com/
>>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/



More information about the wix-devs mailing list