[wix-devs] Selection of compatible VS instances

Heath Stewart heaths at outlook.com
Fri Feb 10 18:15:47 PST 2017


If your extension reports it can target VS2017 or newer (say, [10.0,)) then, yes, it must be built by the VS2017 SDK. So this goes for v1 and v2. VS2012 SDK through VS2015 SDK can produce v2s that can go on the Marketplace so long as they don’t target VS2017, but still can’t produce v1s. That statement you found was to explicitly call out that if people were still using VS2010 SDK to produce an extension for VS2010 (since VS2012 SDK deprecated build support), there’s no possible way you could go on the Marketplace. But since VS2017 SDK can produce valid v2s (that are also v3s), you can still use VS2017 to build extensions for VS2012 and above.

If developers are installing extensions via MSI and since, as I understand, MSI-based VS extensions can go in the Marketplace, I don’t think there would be an issue of wanting to install the same extension they put on the Marketplace and, even if so, really isn’t compounded by VSIXInstaller.exe itself but, rather, Marketplace. I.e. this isn’t an installer concern.

From: Bob Arnson<mailto:bob at firegiant.com>
Sent: Friday, February 10, 2017 6:05 PM
To: Heath Stewart<mailto:heaths at outlook.com>; WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>; Sean Hall<mailto:r.sean.hall at gmail.com>
Subject: RE: [wix-devs] Selection of compatible VS instances

But Marketplace won’t allow a v1 VSIX and requires a v3 VSIX for VS2017?

From: Heath Stewart [mailto:heaths at outlook.com]
Sent: Friday, 10 February, 2017 20:56
To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>; Sean Hall <r.sean.hall at gmail.com>
Subject: RE: [wix-devs] Selection of compatible VS instances


Correct.



From: Bob Arnson<mailto:bob at firegiant.com>
Sent: Friday, February 10, 2017 5:47 PM
To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>; Sean Hall<mailto:r.sean.hall at gmail.com>
Subject: Re: [wix-devs] Selection of compatible VS instances


So I can supply a VSIX v1 and it will install into VS2010, VS2012, VS2015, and VS2017?

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Heath Stewart
Sent: Friday, 10 February, 2017 20:25
To: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
Subject: Re: [wix-devs] Selection of compatible VS instances

I mentioned before this will continue to work. The query API is used to find it initially, then we start falling back to registry searches just like before. I've been maintaining those registry searches for several releases now, and this is additive to how we find VSIXInstaller.exe. We'd have to do it for a new element anyway, but why make authors create a separate element? The new VSIXInstaller.exe is backward compatible. It is a tested scenario to install both a v1 and v2 into VS2017, and v3s can install as v2s since the manifest are merely additive. As long as there is an extension.vsixmanifest, it will work just like a v2 on VS2015 and older.



From: Sean Hall<mailto:r.sean.hall at gmail.com>
Sent: Friday, February 10, 2017 3:30 PM
To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Selection of compatible VS instances



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<mailto: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<mailto: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<mailto: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<mailto: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><mailto:wix-devs-bounces at lists.wixtoolset.org%0b%3e%20%3cwix-devs-bounces at lists.wixtoolset.org%3e>] On Behalf
> > Of Heath Stewart
> > Sent: Friday, 10 February, 2017 17:21
> > To: Sean Hall <r.sean.hall at gmail.com<mailto:r.sean.hall at gmail.com>>; WiX Toolset Developer Mailing
> List
> > <wix-devs at lists.wixtoolset.org<mailto: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
<mailto:r.sean.hall at gmail.com%20%0b>> > <r.sean.hall at gmail.com<mailto: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
<mailto:wix-devs at lists.wix%20%0b>> > 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<mailto: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
<mailto:heaths at outlook.com%20%0b>> > > <heaths at outlook.com<mailto:heaths at outlook.com>>>
> > > Sent: Friday, February 3, 2017 10:12 PM
> > > To: Rob Mensching<mailto:rob at firegiant.com <rob at firegiant.com<mailto:rob at firegiant.com%20%3crob at firegiant.com>>>;
> > > WiX
> Toolset Developer
> > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
<mailto:wix-devs at lists.wixtoolset.org%0b>> <wix-devs at lists.wixtoolset.org<mailto: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<mailto: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><mailto:heaths at outlook.com%20%0b%3e%20%3e%20%3e%20%3cheaths at outlook.com%3e>]
> > > Sent: Thursday, February 2, 2017 1:32 PM
> > > To: Rob Mensching <rob at firegiant.com<mailto:rob at firegiant.com>>; WiX Toolset Developer
> > > Mailing List <wix-devs at lists.wixtoolset.org<mailto: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<mailto:rob at firegiant.com%20%3crob at firegiant.com>>>
> > > Sent: Thursday, February 2, 2017 10:36 AM
> > > To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.
<mailto:wix-devs at lists.%0b>> > > 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><mailto:wix-devs-bounces at lists.wixtoolset.org%0b%3e%20%3cwix-devs-bounces at lists.wixtoolset.org%3e>] 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%20%0b>> > > <mailto:wix-devs at lists.wixtoolset.org
<mailto:wix-devs at lists.wixtoolset.org%20%0b>> > > <wix-devs at lists.wixtoolset.org<mailto: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/
>
____________________________________________________________________
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/


More information about the wix-devs mailing list