[wix-devs] Selection of compatible VS instances

Sun Jan 29 18:51:28 PST 2017

According to Bob's link
<https://github.com/Microsoft/visualstudio-docs/blob/master/docs/extensibility/faq-2017.md>,
"The new VSIX v3 format does not support Visual 2010 and earlier". This
implies that the v3 format is not backwards compatible, but you are saying
that it is backwards compatible. If it is backwards compatible, why is that
documentation recommending "To support Visual Studio 2010 onward, you will
need to create a separate extension (with a separate VSIX ID). As Visual
Studio 2010 is now a small percentage of the user base, we recommend that
you use the existing VSIX ID for the extension that supports Visual Studio
2012 or later, and assign a new VSIX ID to the Visual Studio 2010 version."?

On Sun, Jan 29, 2017 at 8:00 PM, Heath Stewart <heaths at outlook.com> wrote:

> VSIX v3 is backward compatible. 2 additional files were added. They get
> ignored using older VSIXInstaller versions. Rather than extending the
> existing schema in incompatible it constraining ways, we kept what was
> there and layered a new schema atop it.
>
> - Heath via Nine<http://www.9folders.com/> on Android
> ________________________________
> From: Bob Arnson <bob at firegiant.com>
> Sent: Jan 29, 2017 11:41 AM
> To: Heath Stewart; WiX Toolset Developer Mailing List; Rob Mensching
> Subject: RE: [wix-devs] Selection of compatible VS instances
>
> Today, an .msi can install a VSIX into VS2010, VS2012, VS2013, and VS2015,
> using a single VSIX. It appears that it would not be possible to also
> support VS2017, given the VS2017 requirement of a v3 VSIX.
>
> From: Heath Stewart [mailto:heaths at outlook.com]
> Sent: Sunday, 29 January, 2017 13:32
> 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
>
> Then it's not a regression if VSIXInstaller didn't before, right?
>
> - Heath via Nine<http://www.9folders.com/> on Android
> ________________________________
> From: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>
> Sent: Jan 29, 2017 10:22 AM
> To: Heath Stewart; WiX Toolset Developer Mailing List; Rob Mensching
> Subject: RE: [wix-devs] Selection of compatible VS instances
>
> But it can’t; it can only install v1 VSIXes.
>
> From: Heath Stewart [mailto:heaths at outlook.com]
> Sent: Sunday, 29 January, 2017 12:55
> 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
>
> If Dev10’s VSIXInstaller could install v2s, it can install v3s. The format
> change was additive (apart from temporarily removing the ability to have
> nested VSIXes - we will bring that back). The original
> extension.vsixmanifest is still there and unchanged.
>
> - Heath via Nine<http://www.9folders.com/> on Android
> ________________________________
> From: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>
> Sent: Jan 29, 2017 9:13 AM
> To: Heath Stewart; WiX Toolset Developer Mailing List; Rob Mensching
> Subject: RE: [wix-devs] Selection of compatible VS instances
>
> VSIXInstaller.exe v10 can’t install a v3 VSIX, no? So to support VS2010 on
> a machine with only VS2010, for example, you need to pass a v1 VSIX to
> VSIXInstaller.exe v10. To also support VS2017, you must supply a v3 VSIX.
> So that’s two VSIXes. VS2017 is the first release that requires a newer
> VSIX format, so it’s the first time we’re running into this requirement.
>
> From: Heath Stewart [mailto:heaths at outlook.com]
> Sent: Saturday, 28 January, 2017 18:04
> 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
>
> That doesn’t mean VSIXInstaller.exe can’t install them. All the original
> code base is there. If the format does not indicate a VSIX v3, it won’t
> install for VS2017 anyway. I see no problem here.
>
> Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
> From: Bob Arnson<mailto:bob at firegiant.com>
> Sent: Saturday, January 28, 2017 1:19 PM
> To: Heath Stewart<mailto:heaths at outlook.com>; WiX Toolset Developer
> Mailing List<mailto:wix-devs at lists.wixtoolset.org>; Rob Mensching<mailto:
> rob at firegiant.com>
> Subject: RE: [wix-devs] Selection of compatible VS instances
>
> They’re not backward compatible enough: https://github.com/Microsoft/
> visualstudio-docs/blob/master/docs/extensibility/faq-2017.md
>
>
> From: Heath Stewart [mailto:heaths at outlook.com]
> Sent: Saturday, 28 January, 2017 14:17
> 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
>
> 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>
> Sent: Saturday, January 28, 2017 11:04 AM
> To: Heath Stewart<mailto:heaths at outlook.com>; WiX Toolset Developer
> Mailing List<mailto: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]
> Sent: Friday, 27 January, 2017 17:42
> 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
>
> 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 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>
> Sent: Friday, January 27, 2017 2:29 PM
> To: Heath Stewart<mailto:heaths at outlook.com>; WiX Toolset Developer
> Mailing List<mailto: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]
> 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>
> 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>
> 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] 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>
> Sent: Wednesday, January 25, 2017 10:21 AM
> 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
>
>
>
> 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>
> 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] 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>>
> 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/
>