[wix-devs] Selection of compatible VS instances

Rob Mensching rob at firegiant.com
Fri Feb 3 21:33:06 PST 2017


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]
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>
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] 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>>
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/


More information about the wix-devs mailing list