[wix-devs] Selection of compatible VS instances

Sat Jan 28 18:04:02 PST 2017

Up until now, extension authors have been able to install their extension
in a naked MSI.  Returning an error code at runtime is pretty useless and
forces them to completely change how they deliver their extension.  I would
hope Microsoft would care more than this for the people extending VS.

On Jan 28, 2017 7:57 PM, "Heath Stewart" <heaths at outlook.com> wrote:

> As stated previously, if they author or harvest dependent workloads or
> components, we will eventually (probably post-RTW given our current plans)
> return an error code we can map to a more useful error message. We cannot
> eliminate all nested MSIs at this time (some are legacy, but we are working
> to reduce them; but many are third-party).
>
>
>
> Also called out in the WIP and further below, extension developers could
> install via an ExePackage in Burn.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Sean Hall <r.sean.hall at gmail.com>
> *Sent: *Saturday, January 28, 2017 5:52 PM
> *To: *WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> *Subject: *Re: [wix-devs] Selection of compatible VS instances
>
>
> I'm going to have to agree with Bob here, installing an extension for
> VS2017 from an MSI is seriously broken as currently designed. Based on the
> modular nature VS2017, extension authors are not going to be able to assume
> that their required components are installed and they will have no idea
> whether their required components are delivered by MSI.  This means that
> there is no way for them or WiX to know at compile time whether their
> extension has any chance of getting installed by shipping a naked MSI.  I
> can think of the following solutions:
>
> 1) Microsoft eliminates the nested MSI install problem by requiring
> optional VS components to be non-MSI.
> 2) Microsoft adds the functionality in VSIXInstaller.exe and VS to be able
> to accept an install request during an MSI install, and complete the
> install at a later time.
>
> The last resort would be for WiX to emit a warning at compile time saying
> that installing VS extensions inside of an MSI may fail due to requiring
> nested MSI installs.
>
> On Sat, Jan 28, 2017 at 3:32 PM, Bob Arnson <bob at firegiant.com> wrote:
>
> > #alternativefacts. For my install of RC3 Pro with C++ and desktop .NET,
> > it's 246 VSIX packages and 37 MSI packages.
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org
> <wix-devs-bounces at lists.wixtoolset.org>] On Behalf
> > Of Sean Hall
> > Sent: Saturday, 28 January, 2017 16:13
> > To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
> > Subject: Re: [wix-devs] Selection of compatible VS instances
> >
> > Can you give an example of a component or workload that is installed by
> > MSI?  I thought all parts of the Visual Studio install have been migrated
> > away from MSI.
> >
> > On Sat, Jan 28, 2017 at 1:17 PM, Heath Stewart <heaths at outlook.com>
> wrote:
> >
> > > VSIX v3 are backward compatible. They are still valid v2s that work
> > > downlevel. I’m not sure what makes it a v1, but if v2s are backward
> > > compatible with v1s then that will continue to work. I worked closely
> > > with the Extensibility team to ensure backward compatibility long ago
> > > (hence extending the formats – unlike what VSTS and VSCode use as
> > “.vsix” files).
> > >
> > > I’m not suggesting that WiX doesn’t include harvesting support. I’m
> > > saying that the initial feature will be used by a few internal and
> > > external partner that we’ve already instructed to author dependencies.
> > >
> > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> > > Windows 10
> > >
> > > From: Bob Arnson<mailto:bob at firegiant.com <bob at firegiant.com>>
> > > Sent: Saturday, January 28, 2017 11:04 AM
> > > To: Heath Stewart<mailto:heaths at outlook.com <heaths at outlook.com>>;
> WiX Toolset Developer
> > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> <wix-devs at lists.wixtoolset.org>>; Rob
> > Mensching<mailto:
> > > rob at firegiant.com>
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > > I'm not a fan of fail-by-default: If you don't author the dependency
> > > data, the user runs the risk of failure and undesirable behavior. I'm
> > > willing to consider that I'm being paranoid and if we document it, we
> > > can wash our hands of the results. Rob? Sean? Anybody else?
> > >
> > > The WIP doesn't describe what I imagine to be a common scenario
> > > (including WiX, if we use this solution): a VSIX v3 for Dev15/14 and
> > > v1 for everything else (until we drop VS2010 support).
> > >
> > > From: Heath Stewart [mailto:heaths at outlook.com <heaths at outlook.com>]
> > > Sent: Friday, 27 January, 2017 17:42
> > > To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing List
> > > < wix-devs at lists.wixtoolset.org>; Rob Mensching <rob at firegiant.com>
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > > That we can’t nest MSIs that way, yes, an unfortunate bug but just how
> > > MSI works. The install-on-demand is because VS2017 is much lighter
> > > weight. The default install is small and quick (roughly equivalent to
> > > VSCode). That extensions can install features they need was a
> > > desirable feature almost from the start.
> > >
> > > I could do a warning if there are no dependencies authored, but we’d
> > > have to know during build time it’s a VSIX v3 – in which case, we may
> > > as well harvest the dependencies. I’m certainly open to doing that,
> > > but may not be in the first merge (we have a few partners – internal
> > > and external – that need unblocked). We certainly wouldn’t want to
> > > warn for VSIX v2s, which I imagine – for now – most VSIX packages will
> > > be. Or are you suggesting that in the interim? I have another of other
> > > projects related to this on the docket (like vswhere.exe for batch
> > > support, like cmake), so while harvesting IDs is important someone
> > > else could also jump in with that if we need to get it done sooner.
> > >
> > > The error case isn’t great, but it’s also not horrible. If the package
> > > was marked non-vital and didn’t fail the third-party install, when VS
> > > is started it will find that the installation didn’t not complete and
> > > prompt to repair it, which would put the product into the originally
> > > requested state. We considered this when thinking about possibilities,
> > > but decided the perception was bad. It is, but VS will prompt to put
> the
> > product right.
> > >
> > > The WIP does actually call this out how downlevel is supported. The
> > > /instanceIds switch is only added if we found instances (which means
> > > it’s
> > > Dev15+) and will overwrite the VSIX path variable that is otherwise
> > > Dev15+still
> > > set by AppSearch for Dev14-. VSIXInstaller.exe itself will install to
> > > multiple versions. I’ve worked with their team to get
> > > VSIXInstaller.exe doing as much as the work as possible, which is why
> > > we can leave the existing VSIX CAs almost entirely as-is. Prior ideas
> > > including scheduling the batch of typical CAs (install, rollback,
> > > uninstall) per-package per-version but would be far more expensive to
> > > develop, more prone to error, slower to install, and less declarative.
> > >
> > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> > > Windows 10
> > >
> > > From: Bob Arnson<mailto:bob at firegiant.com <bob at firegiant.com>>
> > > Sent: Friday, January 27, 2017 2:29 PM
> > > To: Heath Stewart<mailto:heaths at outlook.com <heaths at outlook.com>>;
> WiX Toolset Developer
> > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> <wix-devs at lists.wixtoolset.org>>; Rob
> > Mensching<mailto:
> > > rob at firegiant.com>
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > > Ah, I see. It’s not a bug, it’s an “alternative feature.” :)
> > >
> > > Today, for VS2015, a package or bundle can do a registry search and
> > > use the results in a launch condition, feature condition, or package
> > > InstallCondition. The equivalent for VS2017 would be to detect whether
> > > there are any compatible (with all necessary components and workloads)
> > > instances installed. That ensures that there won’t be failures for
> > > known reasons.
> > >
> > > As long as the immediate custom action (shared as a BA function) can
> > > safely run early enough for launch conditions, feature conditions, and
> > > install conditions, and the deferred CA only invokes VSIXinstaller for
> > > compatible instances, then I’m +1. I think we need a warning (probably
> > > an
> > > error) if dependencies aren’t specified/harvested; it’s unacceptable
> > > that you can end up in a scenario where stuff is accidentally
> > > installed or that would fail because of a nested install.
> > >
> > > The WIP should describe how VsixPackage should be authored to support
> > > multiple versions of VS, downlevel and 15+.
> > >
> > > From: Heath Stewart [mailto:heaths at outlook.com <heaths at outlook.com>]
> > > Sent: Friday, 27 January, 2017 12:45
> > > To: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>; WiX
> > > Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:
> > > wix-devs at lists.wixtoolset.org>>; Rob Mensching <rob at firegiant.com
> > <mailto:
> > > rob at firegiant.com>>
> > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > > No, the install-on-demand feature is entirely intentional. When
> > > installing from the Visual Studio gallery / extension manager – our
> > > primary use case – everything works as designed. Are you saying that
> > > if I do the work to support installing VSIX packages for VS2017 you
> > > would not merge it into the shipping code?
> > >
> > >
> > >
> > > As a reminder called out in the WIP, if they author dependent workload
> > > and/or components IDs (or they are otherwise harvested during build)
> > > this “nested install” scenario won’t happen.
> > >
> > >
> > >
> > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> > > Windows 10
> > >
> > >
> > >
> > > From: Bob Arnson<mailto:bob at firegiant.com <bob at firegiant.com>>
> > > Sent: Thursday, January 26, 2017 7:32 PM
> > > To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.
> > > wixtoolset.org>; Rob Mensching<mailto:rob at firegiant.com
> <rob at firegiant.com>>
> > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > > Merged.
> > >
> > > So, clearly, installing anything during the installation of an
> > > extension was/is a bad idea. Has this issue now raised it to a design
> > > bug that will be fixed for RTW? If not, I'm -1 on adding any MSI
> > > support for VSIX packages to WiX, until it is fixed.
> > >
> > > For WiX itself, the ExePackage will suffice. The Chain element isn't
> > > currently extensible but we could take a change for that, if someone
> > > wanted to add VsixPackage for bundles.
> > >
> > > -----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: Thursday, 26 January, 2017 19:02
> > > 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
> > >
> > > I've pushed another commit after we realized another a problem that
> > > results in nested MSI installs (and across processes, so
> > > MsiJoinTransaction can't work). We are discussing timing of a fix to
> > > fail fast without machine changes, but for now I included a description
> > in future considerations.
> > > I'll be working from this WIP commit if no other feedback about the
> > > implementation.
> > >
> > >
> > >
> > > One idea to mitigate potential nested MSI installs would be to allow
> > > the compiler to parse extension elements for packages, with the intent
> > > those are only transpilers. For example, the WixVSExtension could
> > > support a vs:VsixPackage that just transpiles to an ExePackage, and
> > > we'd ship (either next to WixVSExtension, or as an embedded resource
> > > if we want to remain a single file) a small EXE that just finds the
> > > VS2017+ VSIXInstaller.exe and forwards the command line. Seems this
> > > could be generally useful to support other EXE installs for class of
> > > installers and would require no changes to Burn. Things like progress
> > > type could be automatically emitted if supported (it's feasible -
> > > though no promises - our progress events could be adapted to the burn
> > protocol).
> > >
> > >
> > >
> > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> > > Windows 10
> > >
> > >
> > >
> > > From: Heath Stewart<mailto:heaths at outlook.com <heaths at outlook.com>>
> > > Sent: Wednesday, January 25, 2017 10:21 AM
> > > 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
> > >
> > >
> > >
> > > If they don't author workloads or components, that's what would happen.
> > > However, as the WIP calls out, VSIXInstaller.exe will actually install
> > > all dependent workloads and components authored into the VSIX v3,
> > > which probably won't make many end users happy. But, yes, it's
> > > supported. I can emphasize that more and make sure I get that into the
> > > documentation for the VsixDependency element.
> > >
> > >
> > >
> > > The default install of VS is very small and fast (actually, ever since
> > > we dropped almost all MSIs even a nearly full install on my machine
> > > took only about 20-30 minutes yesterday), so this change in behavior
> > > for dependencies was necessary for a more ala carte model. The thing
> > > to emphasize is the impact of NOT authoring (or harvesting - either
> > > via heat and/or bind-time discovery like with file version info and
> > size) dependencies.
> > >
> > >
> > >
> > > 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: Wednesday, January 25, 2017 6:07 AM
> > > To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.
> > > wixtoolset.org>
> > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > >
> > > Is there a way to have the easy solution that was kind of in the
> > > original version where one just says, "Install my extension in all
> > > Visual Studio
> > > 2017 instances"?
> > >
> > > It might still be there but lost in the details.
> > >
> > >
> > > -----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, January 25, 2017 1:22 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
> > >
> > > Updated the WIP based on the design below:
> > >
> > >
> > >
> > > https://github.com/wixtoolset/web/pull/22
> > > ____________________________________________________________________
> > > 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/
>