[wix-devs] Testing late-bound properties

[Ron Martin]

Sean,

I've put the test where it needs to be to allow the substitutions to 
take place
within the purview of the test.

I haven't checked whether !(loc.xxx) variables have the same issue that 
I just fixed
for !(bind.xxx) Wix variables, but it's worth checking.

Ron

On 4/17/2021 11:51 PM, Sean Hall via wix-devs wrote:
>> 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/
>>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/