[wix-devs] Adding support for VS2017

[Bob Arnson]

Oh yes, the registry being known as an awful place to store name-value pairs...

Can both native and managed code access instance & location information without linking closed-source code?

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Heath Stewart
Sent: Thursday, 1 December, 2016 00:33
To: wix-devs at lists.wixtoolset.org
Subject: [wix-devs] Adding support for VS2017

I've published a WIP and looking for feedback on http://wixtoolset.org/development/wips/5433-add-support-to-detect-and-install-vsix-packages-into-vs15/.


The inspiration for the new installer were package managers since managing our growing list of dependencies via declarative manifest and conditions was untenable. I designed much of the new system to be purely file-extraction, though we still support installing EXEs, MSIs, and MSUs. At the same time, a big push was made to support VS side-by-side better than previous versions since most content is now simply file-extraction, so a new way to find VSIXInstaller.exe and install extensions was needed.


I wrote the native query API I describe in the WIP (and external resources) to query for these instances. Because of side-by-side support, registry entries as in the past wasn't really viable. I just completed the pre-reqs today, in fact, for the WiX CA I propose to find VSIXInstaller.exe.


Please especially pay attention to the consideration at the bottom. These are concepts we toyed with, and while the query API supports it today, the use cases are particular tricky, though not insurmountable (such as using the Vital bit for VsixPackage to make sure at least one instance was updated).


Thanks,


Heath Stewart
Senior Software Engineer
Visual Studio, Microsoft
http://blogs.msdn.com/heaths
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/