[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