[wix-devs] Selection of compatible VS instances

Fri Feb 10 14:11:13 PST 2017

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>
> Sent: Friday, February 3, 2017 10:12 PM
> To: Rob Mensching<mailto:rob at firegiant.com>; WiX Toolset Developer
> Mailing List<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>
> 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]
> 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/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
> ____________________________________________________________________
> WiX Toolset Developer Mailing List provided by FireGiant
> http://www.firegiant.com/
>