[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