[wix-devs] Adding support for VS2017

Sat Dec 10 16:46:19 PST 2016

I can confirm, but I believe the MSBuild folks are working on that using the COM APIs. At worst, the EXE would be callable to get the target, much like querying the registry now to find where VC is installed.

Heath Stewart
Visual Studio, Microsoft
http://blogs.msdn.microsoft.com/heaths

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Bob Arnson
Sent: Saturday, December 10, 2016 9:25 AM
To: Heath Stewart <heaths at outlook.com>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Adding support for VS2017

We have the additional problem of multitargeting, assuming that we want to build DUtil with Dev15 and/or a v3 VSIX...

From: Heath Stewart [mailto:heaths at outlook.com]
Sent: Saturday, 10 December, 2016 09:52
To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Adding support for VS2017

Sort of. MSBuild is now under the VS directory so all its relative paths work. It still looks in shared folders so WiX targets would still work.

I've been working with our cmake partners and am writing an exe that can output different formats to easily use in build scripts. The exe will be redistributable. In fact, I want to see about it going open source as a more practical sample over my current sample in GitHub and MSDN.

- Heath via Nine<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.9folders.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=Ih8GdGB%2B0AahiVPNWpYKIgxvriXhMNPgpbUE%2B2tjPuo%3D&reserved=0> on Android ________________________________
From: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com>>
Sent: Dec 8, 2016 8:47 PM
To: WiX Toolset Developer Mailing List; Heath Stewart
Subject: RE: [wix-devs] Adding support for VS2017

BTW, are the COM APIs the only way for a build system to detect Dev15 and to choose which instance(s) to use?

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Bob Arnson
Sent: Wednesday, 7 December, 2016 22:38
To: Heath Stewart <heaths at outlook.com<mailto:heaths at outlook.com>>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
Subject: Re: [wix-devs] Adding support for VS2017

This sender failed our fraud detection checks and may not be who they appear to be. Learn about spoofing at https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Faka.ms%2FLearnAboutSpoofing&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=CaIotDm7fWXi9Ie1AWgXF2moHvOZ58B6DNrt2lXXjIg%3D&reserved=0

To be clear, I wasn't suggesting that the engine should store its data in the registry. I was suggesting that it would be POLITE for the engine to provide the data in a more easily consumable manner than COM objects.

WIP feedback:

* Proposal
  * Remove VS15.wxs unless there's something useful in what exists today. Maintaining two copies is a useless tax.
* Properties
  * How does "highest constrained" work? Major? Major.minor? Other?
  * Can more than one edition be installed? If so, which one wins?
* VsixPackage
  * "nw" typo
  * It's not clear whether your proposal supports instance selection in "base feature work." If an ISV wrote the code to implement instance selection in their BA, could they use anything in the WIP to call VsixInstaller.exe appropriately?
* Considerations
  * Am I understanding your comments correctly that VsixInstaller.exe will try to install workloads specified as dependencies in a v3 VSIX? And that you have to actively prevent that behavior? If so, an all-instances installation seems like a bad default.
  * Instead of a message, why not a function in DUtil (VSUtil?)? That way, both a BA and a BA functions DLL could use it/them.

From: Heath Stewart [mailto:heaths at outlook.com]
Sent: Sunday, 4 December, 2016 11:44
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>>
Subject: RE: [wix-devs] Adding support for VS2017

As noted, we have and will continue to - as needed - change the storage mechanism. Exposing the raw data can prevent that while maintaining compatibility. We also store a lot of data that Windows doesn't want us to keep putting in the registry. VS itself now detours all registry - the original goal of pkgdefs finally realized. The only thing we install to the registry now is for shell registration. There were other reasons for getting out of the registry that will become apparent eventually.

Besides, you don't need to - and shouldn't - redist the DLL. We install it when an instance is installed. As the WIP describes, REGDB_E_CLASSNOTREG means no supported instances are installed. That entry point is old when we ere planning that people would redist. Now its mainly for testing on systems with another version installed.

I'm also working on a simple exe that can produce results in multiple formats to extract information for scripts to use.

Are there any comments on the WIP itself? I'd like to get started soon.

Sent from Mail<https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgo.microsoft.com%2Ffwlink%2F%3FLinkId%3D550986&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=tG6SvQKjALaVP%2FoWUV4VUfZAUhnAXKGFnM0Qd3HpVUo%3D&reserved=0> for Windows 10

From: Bob Arnson<mailto:bob at firegiant.com>
Sent: Saturday, December 3, 2016 1:20 PM
To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Adding support for VS2017

My point was that you *could*, given that you have an installed engine doing the work, maintain stable and useful configuration in a way that's easier to consume. A custom action (or enhanced Burn search functionality) to enumerate registry keys and values (for example -- hell, it could probably nicely in an .ini file) is a teeny bit easier than a COM API. It's also more generally useful than requiring every ISV that needs it to develop it themselves. It also wouldn't require the use of proprietary code, for those who are sensitive to that.

Speaking of proprietary code...I of course have no objection to import libraries for DLLs installed on the system (either because they come with the OS like msi.dll or are installed by a required component like VS). But code like GetSetupConfiguration is a different story; using it would mean shipping closed-source bits. I assume it's trivial to replace, however. And I assume the managed interop assemblies are just interop.

BTW, at least one ISV is already using the registry key that lets them avoid all this...Like the Internet, ISVs route around damage. :)

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Heath Stewart
Sent: Friday, 2 December, 2016 12:11
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.org>>>
Subject: Re: [wix-devs] Adding support for VS2017

It's also fair to point out that WiX had always depended on closed source libraries like MSI.dll and, IIRC for v1 msidb.exe (which in turn used MSI.dll).

The main reason is to abstract away the details so we can protect callers from underlying changes. We also, by default, only enumerate instances that are currently launchable (usable, at least in part: installed with warnings, basically). There's quite a few calculations that go into that (more probably in even the next week or two) that all callers shouldn't have to do themselves, right?

- Heath via Nine<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.9folders.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=Ih8GdGB%2B0AahiVPNWpYKIgxvriXhMNPgpbUE%2B2tjPuo%3D&reserved=0> on Android ________________________________
From: Heath Stewart
Sent: Dec 2, 2016 8:42 AM
To: WiX Toolset Developer Mailing List
Subject: Re: [wix-devs] Adding support for VS2017

We are not currently documenting the storage mechanism, which is why the COM APIs exist. This also provides the abstraction necessary to change the underlying storage to support new features and perf goals. Another change is likely on the horizon to that storage mechanism but the COM API will remain unchanged.

Reducing use of the registry was done to better enable side-by-side instances. Even if we did use it, you'd still need a custom action to enumerate subkeys for instances since MSI doesn't support that.

- Heath via Nine<https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.9folders.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=Ih8GdGB%2B0AahiVPNWpYKIgxvriXhMNPgpbUE%2B2tjPuo%3D&reserved=0> on Android ________________________________
From: Bob Arnson <bob at firegiant.com<mailto:bob at firegiant.com<mailto:bob at firegiant.com%3cmailto:bob at firegiant.com>>>
Sent: Dec 1, 2016 7:17 PM
To: WiX Toolset Developer Mailing List
Subject: Re: [wix-devs] Adding support for VS2017

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<mailto:wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtoolset.org>>
Subject: [wix-devs] Adding support for VS2017

I've published a WIP and looking for feedback on https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwixtoolset.org%2Fdevelopment%2Fwips%2F5433-add-support-to-detect-and-install-vsix-packages-into-vs15%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=Sci%2F29WjUXAB%2FnaZKl7Du%2BDkdtphwecXCQ9eoZ8tebo%3D&reserved=0.

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
https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fblogs.msdn.com%2Fheaths&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=CRS9j5K34GKQdql7Pfqy%2FftmsSBdxfIQKgXcJZC71CY%3D&reserved=0
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0 ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0 ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0 ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0 ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0 ____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant https://na01.safelinks.protection.outlook.com/?url=http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.Stewart%40microsoft.com%7Cda3d54a626204cef280808d421216b81%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636169874814522781&sdata=%2F%2BCANjk1zjOZjWI%2BR08a8ZMaZ7n7P%2Bm1mlRKyG9Tcdo%3D&reserved=0