[wix-devs] Selection of compatible VS instances

Fri Feb 10 15:30:13 PST 2017

Whether or not to create a new element is debatable.  Today it is possible
to use the VsixPackage element and install an extension on a machine with
only VS2010.  I want to make sure that this will continue to work.  My
prediction is that the implementation will be much easier to just create a
brand new element for v3 packages.

On Fri, Feb 10, 2017 at 5:09 PM, Heath Stewart <heaths at outlook.com> wrote:

> Bob, VSIX v1s just can’t be posted to the Marketplace (formerly Gallery)
> if they don’t cap supported VS versions at VS2015. They should install just
> fine with the VS2017 VSIXInstaller.exe.
>
>
>
> Sean, most feedback we have received is that extension developers do want
> one package so that their comments and ratings apply. You or anyone are
> certainly welcome to have separate packages if you want. There certainly
> have been some that want separate packages, but I still see no reason for a
> separate element since VSIXInstaller.exe is backward compatible.
>
>
>
> *From: *Sean Hall <r.sean.hall at gmail.com>
> *Sent: *Friday, February 10, 2017 2:46 PM
> *To: *WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> *Subject: *Re: [wix-devs] Selection of compatible VS instances
>
>
> I don't expect for extension authors that were previously shipping a VSIX
> package by MSI to just change their VSIX package to v3 and keep the
> installer the same.  If I were an extension author, I would keep using a v2
> VSIX package in the MSI for VS 2015 and earlier and completely change the
> delivery method for VS 2017 (and later).  I prefer to create installers
> that Just Work, and there are too many scenarios in the current design for
> an extension installed by an MSI to fail.  The original functionality of
> the VsixPackage element is needed to install into VS 2010, and IMO should
> be left alone.  In VS2017, the method of finding VSIXInstaller .exe
> changed, the required arguments changed, the potential target VS instances
> changed, etc.  The extension author needs to think differently about
> deploying v3 packages, and IMO it doesn't help them if we keep using the
> existing VsixPackage element.
>
> On Fri, Feb 10, 2017 at 4:25 PM, Bob Arnson <bob at firegiant.com> wrote:
>
> > Don't forget Dev10. That's why we suggested a separate element, to keep
> > Dev10 support for WiX v3.x.
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org
> <wix-devs-bounces at lists.wixtoolset.org>] On Behalf
> > Of Heath Stewart
> > Sent: Friday, 10 February, 2017 17:21
> > To: Sean Hall <r.sean.hall at gmail.com>; WiX Toolset Developer Mailing
> List
> > <wix-devs at lists.wixtoolset.org>
> > Subject: Re: [wix-devs] Selection of compatible VS instances
> >
> > How would that solve anything? The same VSIXInstaller.exe installs v1s,
> > v2s, and v3s. The recommendation I've made to the VSIXInstaller.exe team
> > would handle the scenario of only apply to applicable SKUs - just like it
> > always have (based on what is authored within the extension and filtered
> by
> > optional command line switches). Seems not *requiring* installers to do
> > anything additional is most beneficial.
> >
> >
> >
> > VSIX v3s are backward compatible so they install into Dev14-. Most
> package
> > developers will not need to build separate packages, nor do they want to
> > (many have been consulted).
> >
> >
> >
> > From: Sean Hall<mailto:r.sean.hall at gmail.com <r.sean.hall at gmail.com>>
> > Sent: Friday, February 10, 2017 2:11 PM
> > To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wix
> > toolset.org>
> > Subject: Re: [wix-devs] Selection of compatible VS instances
> >
> >
> >
> > I think this reinforces the idea of a brand new element, e.g.
> > Vsix3Package, for use with VSIX v3 packages.  The original VsixPackage
> > functionality and the new functionality is just so completely different
> > that I don't think it's worth the effort to try to present it to WiX
> users
> > as if they're the same thing.
> >
> > On Fri, Feb 10, 2017 at 3:19 PM, Heath Stewart <heaths at outlook.com>
> wrote:
> >
> > > I've hit a wall but have a proposed solution to the VSIXInstaller team.
> > >
> > >
> > >
> > > If I pass /instanceIds, the instances we'd install to are limited to
> > > those - no different than passing /skuName and /skuVersion (which are
> > > mutually exclusive with /instanceIds). But if we don't find any
> > > compatible instances and don't pass /instanceIds, the extension would
> > > install to all instances and, therefore, install dependent workloads
> > > and components. So there is no way currently to support both De14- and
> > > Dev15+. The only way would be to schedule all custom actions at
> > > install-time (i.e. don't schedule them - not even for Dev14- - until a
> > CA can determine what's applicable).
> > >
> > >
> > >
> > > This doesn't feel like a great solution. It's complex and shouldn't be
> > > necessary, so I've proposed a solution to the VSIXInstaller team. It
> > > wouldn't be ready by RTW, though; it would have to ship after.
> > >
> > >
> > >
> > > So rather than creating a complex solution for a short time and having
> > > to back it out for a solution that would work for any installer (even
> > > batch
> > > files) by having VSIXInstaller shoulder the burden, I propose waiting
> > > until the change is public and, in the interim, documenting (and even
> > > making the "shortcut" feature I proposed in wix4) the VSIXBootstrapper
> > > workaround now available here:
> > > https://github.com/Microsoft/vsixbootstrapper
> > >
> > >
> > >
> > > From: Heath Stewart<mailto:heaths at outlook.com <heaths at outlook.com>>
> > > Sent: Friday, February 3, 2017 10:12 PM
> > > To: Rob Mensching<mailto:rob at firegiant.com <rob at firegiant.com>>; WiX
> Toolset Developer
> > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> <wix-devs at lists.wixtoolset.org>>
> > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > >
> > > I think we're on the same page. Only VSIX v3s can trigger workloads
> > > and components. VSIX v2s (and v1s, since that affects only marketplace
> > > scenarios as I understand it) work like they did before, so a new
> > > element should not be necessary. It's just that without dependencies
> > > authored into the MSI their install could break and I can at least
> > > emit a warning and refer them to the VSIX bootstrapper in almost done
> > > with (it'll have WiX sample authoring). I'll be posting signed
> > > versions via nuget pages WiX4 can reference to ship it with/in the VS
> > extension (MIT license).
> > >
> > > - Heath via Nine<http://www.9folders.com/> on Android
> > > ________________________________
> > > From: Rob Mensching <rob at firegiant.com>
> > > Sent: Feb 3, 2017 9:33 PM
> > > To: Heath Stewart; WiX Toolset Developer Mailing List
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > > 1. My point is simply that adding support for VS2017 should not break
> > > people using VisxPackage to install a VSIX into VS2010, VS2012,
> > > VS2013,
> > > VS2015 today. If that means we need to introduce a new element (like:
> > > Vsix3Package) so that the old code still works, that's cool. But
> > > someone upgrading from WiX v3.10.3 to WiX v3.11 should not find their
> > > VsixPackage code broken. That's my key concern.
> > >
> > > 3. Yeah, let's not "pollute" WiX with yet another "Platform" concept
> > > anywhere (aka: "Chip). It's already hard enough that we have
> > > "Architecture", "Arch" and "Platform" floating around for the same
> thing.
> > > <smile/>
> > >
> > >
> > > Regards,
> > >
> > >   Rob Mensching
> > >   CEO
> > >   FireGiant
> > > _______________________________________________________________
> > > FireGiant  |  Dedicated support for the WiX toolset  |
> > > http://www.firegiant.com/
> > >
> > > From: Heath Stewart [mailto:heaths at outlook.com <heaths at outlook.com>]
> > > Sent: Thursday, February 2, 2017 1:32 PM
> > > To: Rob Mensching <rob at firegiant.com>; WiX Toolset Developer Mailing
> > > List <wix-devs at lists.wixtoolset.org>
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > >   1.  But therein lies the problem Bob and Sean raised. While a VS2010
> > > SDK-built package should install even on VS2017, a VS2017 SDK-built
> > > package might fail the install because a concurrent MSI may install
> > > because of our on-demand feature. It's for this reason I'm currently
> > > working on finishing and publishing a simple bootstrapper that could
> > > be chained into a bundle that will do the same lookup I am proposing
> > > in the WIP. The impression I got from the thread was that because an
> > > install could fail because of the concurrent, out-of-proc
> > > (unfortunately, or we could solve it) MSI installs that it's too
> > > detrimental. But I think this can be largely mitigated by extensions
> > > only declaring what's needed (for example, the Core Editor workload is
> > > always installed - the default workload and sole source of vital
> > > packages), and even doing pre-checks if required. If there is cause
> > > for concern, they could use the simple bootstrapper and chain the VSIX
> > install with the bundle. So you feel that is sufficient for now?
> > >   2.  Sounds reasonable that new features (i.e. extension support for
> > > Chain) should go only in wix4.
> > >   3.  I can do that at least for authoring. The idea was to keep terms
> > > equivalent, and is "Chip" in the actual ISetupPackageReference
> > definition.
> > > Any strong feelings if the table column name should match authoring or
> > > interfaces? I'm tempted just to go all "Platform" if that's what you'd
> > > prefer for WiX (and is consistent with the Package element).
> > >
> > >
> > >
> > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> > > Windows 10
> > >
> > >
> > >
> > > From: Rob Mensching<mailto:rob at firegiant.com <rob at firegiant.com>>
> > > Sent: Thursday, February 2, 2017 10:36 AM
> > > To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.
> > > wixtoolset.org>
> > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > > Overall, I think this is a great first step. A few things:
> > >
> > > 0. We *cannot* break people using VsixPackage today in WiX v3.x. I
> > > don't see anything in the WIP that says the current behavior will be
> > > broken but the "Deferred custom actions" section seems to touch the
> > > existing custom actions so I was unclear. The goal should be that you
> > > can install to VS2010, VS2012, VS2013, VS2015, VS2017 VSIXs in a
> > > single MSI (even if you may need multiple VSIXs).
> > >
> > > 1. All the work should be contained within the WixVsExtension. The WIP
> > > calls this out so I think this is handled. If we need to add
> > > extensibility points (in Chain element, for example) we can (and
> > > probably should) do that in WiX v4.0.
> > >
> > > 2. Minor nit: "Chip" attribute should be "Platform". "Chip" is a very
> > > unique term I've only seen used in VS setup authoring. <smile/>
> > >
> > >
> > > It will be great to continue to have the properites available in
> > > VS2017.exe and to teach VsixPackage to install VSIX3 just like it
> > > knows how to install VSIX1 and VSIX2 today.
> > >
> > >
> > > -----Original Message-----
> > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org
> <wix-devs-bounces at lists.wixtoolset.org>] On
> > > Behalf Of Heath Stewart
> > > Sent: Wednesday, February 1, 2017 11:02 AM
> > > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org
> > > <mailto:wix-devs at lists.wixtoolset.org <wix-devs at lists.wixtoolset.org>
> >>
> > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > >
> > > I followed up with the Extensibility team. The problem is that
> > > building v1 packages was deprecated in VS2012, but the VS2010 SDK
> > > could still build them in a way that supported v2 and the Gallery (now
> > > Marketplace) would accept them. However, the Marketplace will not
> > > accept packages that target
> > > 15.0 or newer and are missing the 2 files added to the VSIX container.
> > > Since VS2010 can't produce those the scenario is effectively broken.
> > > However, this only affects customers that still need to support VS2010
> > > and ship their VSIXes in both an MSI and on the Marketplace, which
> > > both our telemetry and conversations with partners found to be a very
> > > small set of customers.
> > >
> > >
> > >
> > > What I'm seeing in this thread, however, is a lot of pushback because
> > > we cannot support 100% of customers who use MSIs - a technology being
> > > slowly deprecated by Windows. This is the extensibility model going
> > > forward that has enabled new capabilities for end users (e.g. smaller
> > > initial install footprint and install-on-demand dependencies) and
> > > extension developers alike. We will be making further investments to
> > > improve this. MSI didn't ship with patching support in 1.0. Any feature
> > grows over time.
> > >
> > >
> > >
> > > But I need a commitment from Rob that a merge based on the WIP (plus
> > > your feedback about a warning) would be accepted. We are prepared to
> > > pull the existing VS15.wxs file (as the WIP calls out: it doesn't work
> > > anyway) and publish an open source EXE I eluded to in the WIP with
> > > sample WiX authoring that could run in a Burn bundle (or any chainer).
> > > This EXE would basically do what the CAs do now: try to cocreate the
> > > COM server, and if that fails use registry detection to check for
> > > Dev14 and older, then pass through arguments to VSIXInstaller.exe.
> > > Since it would run outside f an MSI, there's no more of a chance of
> > concurrent MSI packages than normally (i.e.
> > > another install starts, like via Windows Update).
> > >
> > >
> > >
> > > That would certainly work around the issue of possibly installing MSIs
> > > when running within an MSI, but we feel doesn't provide a seamless
> > > experiencing upgrading package authoring for MSIs that install VSIXes
> > > to support VS2017. With workload and/or component IDs authored or
> > > harvested, customers would have the option to fail if no instances are
> > > compatible (default), which is practically no different than not
> > > finding a SKU and/or version the extension supports and, therefore,
> > > not installing anything on-demand.
> > >
> > >
> > >
> > > Can you please confirm whether a merge to support VSIXInstaller.exe in
> > > MSIs will be accepted or declined, or should we simply go with the
> > > external EXE approach?
> > > ____________________________________________________________________
> > > 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/ ______________________________
> > ______________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> >
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>