[wix-devs] Selection of compatible VS instances

Heath Stewart heaths at outlook.com
Fri Jan 27 09:45:14 PST 2017


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>; WiX Toolset Developer Mailing List <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>
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/


More information about the wix-devs mailing list