[wix-devs] Selection of compatible VS instances

Sat Jan 28 13:13:02 PST 2017

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