[wix-devs] Selection of compatible VS instances
Bob Arnson
bob at firegiant.com
Sat Jan 28 13:32:25 PST 2017
#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] 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>
> 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
> 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>
> 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/
>
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/
More information about the wix-devs
mailing list