[wix-devs] Redesign RemotePayload

[Sean Hall]

In our meeting today, we decided to keep DownloadUrl at the package level
as well as SourceFile. At that point, we're only removing two attributes at
the package level - Compressed and Name (EnableSignatureVerification is
getting completely removed). After thinking about it, I'm not sure they're
worth removing at that point because we've already failed to address the
confusion of attributes applying only to the single payload that's getting
magically created behind the scenes and not to all the payloads inside of
the package.

On Mon, Dec 28, 2020 at 7:50 PM Bob Arnson <bob at firegiant.com> wrote:

> 1. ProductCode, UpgradeCode, Upgrade table, ... Harvest-able but wouldn't
> want to write it by hand...
> 2. I'm 108% OK with moving easily-misused attributes off (see
> Package/SumInfo). (IntelliSense is evil.) *Package/@SourceFile should work
> (and be illegal with *PackagePayload). (IMO).
>
> -----Original Message-----
> From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of Sean
> Hall via wix-devs
> Sent: Monday, 28 December, 2020 20:37
> To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> Cc: Sean Hall <r.sean.hall at gmail.com>
> Subject: Re: [wix-devs] Redesign RemotePayload
>
> I'm not trying to fully design the feature request for a source-less
> MsiPackage here. But I'm basically suggesting that it could be implemented
> by adding some attributes onto the new MsiPackagePayload element. Isn't
> most of the harvesting to support bind-time variables? I would hope people
> wanting this feature would realize they can't use those without the source
> file.
>
> I went back and forth on proposing to leave SourceFile (but not Name,
> Compressed, DownloadFile, or EnableSignatureVerification) on the package
> elements as syntactic sugar for the "common use case". But what is the
> common use case? A cursory GitHub search showed most people using some of
> the other payload attributes. Although, most of those were either
> specifying the Name with the exact same thing as the SourceFile or
> specifying Compressed="yes" on all packages instead of the Bundle element.
>
>
> On Mon, Dec 28, 2020 at 7:24 PM Bob Arnson <bob at firegiant.com> wrote:
>
> > The binder grabs a bunch of data from MSIs in the chain, so you're not
> > addressing a source-less RemotePayload implementation for MsiPackage
> > here, right?
> >
> > I'm -1 on requiring two elements for the most common use cases that
> > today require one. I'm +1 on supporting the separation to allow for
> > the mix you discuss for NetFx. ("Simple things should be simple,
> > complex things should be possible.")
> >
> > -----Original Message-----
> > From: wix-devs <wix-devs-bounces at lists.wixtoolset.org> On Behalf Of
> > Sean Hall via wix-devs
> > Sent: Monday, 28 December, 2020 17:53
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Cc: Sean Hall <r.sean.hall at gmail.com>
> > Subject: [wix-devs] Redesign RemotePayload
> >
> > I created a WIP to redesign RemotePayload at
> > https://wixtoolset.org/development/wips/4183-redesign-remote-payload.
> > It also gets rid of the magic behavior of using the first payload for
> > the package payload if neither SourceFile nor RemotePayload is
> > specified. I associated it with 4183 (Allow separation of package and
> > payload in chain) since that's how I'm proposing to change it, but
> > that's not really what I'm interested in if we want to do this
> differently. Any feedback?
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>