[wix-devs] Testing late-bound properties

Sat Apr 17 20:51:14 PDT 2021

> 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.

WiX has a very large surface area. The test I wrote for #4628 is sufficient
to test that duplicate CacheIds are detected. It doesn't test that it is
put in the right place, but that's OK. If you really want to write a test
for that, then just wait for Rob to fix #6431. It's assigned to him and in
Preview Zero. You can add that test later. But right now, you can put the
code in the right place and then we can close #4628. I wrote that test
because it is technically a breaking change and therefore I would prefer
that it gets into Preview Zero.

On Sat, Apr 17, 2021 at 10:31 PM Ron Martin via wix-devs <
wix-devs at lists.wixtoolset.org> wrote:

> 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/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>