[wix-devs] https://github.com/wixtoolset/issues/issues/4628

[Ron Martin]

I have much to learn about bundles. I assume that a  bundle is an entire 
payload,
separate from the code installed by the BAL. Bundles are used to 
coordinate the
installation of multiple separate packages that need to be installed 
together before
any individual package runs for the first time. Is that correct?

I've run across such code in your repos quite a few times now and I'm 
getting
fairly comfortable with it. You're right: the "when to use" philosophy 
does not
come through. I've been watching for patterns to see whether new code should
stand under an existing tent or have its own. It means that you are 
likely to see
all errors of same kind reported in a single build, but you won't see 
errors of
mixed kinds reported unless they share the same tent.

When you *do* ignore errors, do you get into problems with later phases 
not being
prepared to handle the consequences of allowing forbidden semantics to slip
through?

Is there anything special I should know about creating translatable 
strings for
use in error messages? What triggers the (presumably human) act of 
translation?
Is there anything special about the order of these strings? I did notice 
an important
ordering when I worked on the "$" to "!" translation. I inserted what I 
hope was
a helpful comment at that point.

On 4/5/2021 6:23 PM, Sean Hall via wix-devs wrote:
> There's never multiple bundles being built at the same time.
>
> Errors being ignored and errors being downgraded are things you shouldn't
> have to worry about because they are abstracted away in the IMessaging
> interface.
>
> I don't know if there's a coherent philosophy for when to use this code:
>
>              if (this.Messaging.EncounteredError)
>              {
>                  return;
>              }
>
> On Mon, Apr 5, 2021 at 5:00 PM cpuwzd <notifications at github.com> wrote:
>
>> OK, so I'm just trying to prevent the burn pass from running when there
>> is a CacheId collision within the same bundle. The feature request is
>> going to require more planning and discussion. I don't think that I'm
>> ready to take on a chunk of work that large at this time. There's still
>> a lot of code for me to absorb. I'm still trying to learn all of the
>> phases that the processing goes through (including the general
>> responsibilities of each phase) and to sort out the history of names and
>> naming conventions.
>>
>> I should be able to use a suitable collection, initialized for each
>> bundle, to hold a set of unique cache id's. I'd use the messaging system
>> to report the error, which would terminate the operation unless errors
>> are being ignored.
>>
>> Should this error ever be downgraded to a warning? Does/should
>> processing generally continue to the end of a phase (in an effort to
>> report as many errors as possible in a single build) or end when the
>> first error/warning is discovered?
>>
>> On 4/5/2021 10:44 AM, Sean Hall wrote:
>>> It is valid for multiple bundles to have a package with the same
>>> |CacheId|. Reusing a |CacheId| like that has restrictions, but we
>>> can't enforce those since we only build one bundle at a time.
>>>
>>> Auto-generated |CacheId|s are generated at bind time. The Symbol
>>> mechanism takes place at link time, which is too early.
>
> On Mon, Apr 5, 2021 at 10:05 AM Sean Hall <r.sean.hall at gmail.com> wrote:
>
>> https://www.youtube.com/watch?v=M0aPovmED8I (starts at 4:50)
>>
>> There's actually two separate issues in #4628. The test is for the issue
>> that has a clear solution - there can't be multiple packages with the same
>> CacheId. As explained in the issue, the Burn engine can't handle that at
>> runtime.
>>
>> The other issue is a feature request to be able to have multiple
>> ExePackages in the chain with the same .exe. This probably should be a
>> separate feature request, though, because that will require designing how
>> that's supposed to work. Right now the auto-generated CacheIds are the same
>> because the CacheId is the hash of the .exe.
>>
>> On Sun, Apr 4, 2021 at 8:57 PM Ron Martin via wix-devs <
>> wix-devs at lists.wixtoolset.org> wrote:
>>
>>> Please see my comment on
>>> https://github.com/wixtoolset/issues/issues/4628
>>> <https://github.com/wixtoolset/issues/issues/4628>.
>>>
>>> ____________________________________________________________________
>>> WiX Toolset Developer Mailing List provided by FireGiant
>>> http://www.firegiant.com/
>>>
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/