[wix-devs] WIP 5433

Fri Jun 2 18:30:00 PDT 2017

I actually talked with management and will work on cleaning up the XML doc comments for our OM library and get it published on NuGet which will help with parsing the dependencies.

From: Rob Mensching<mailto:rob at firegiant.com>
Sent: Friday, June 2, 2017 10:38 AM
To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>; Bob Arnson<mailto:bob at firegiant.com>
Subject: Re: [wix-devs] WIP 5433

This thread seemed to stall so some thoughts:

1. "For end users before 15.2, you can't support both 15+ and 14- simultaneously without scheduling multiple sets of custom actions at install time. Not sure whether you'd just send an error or warning message through the pipe or stop with an error. My plan was to log a warning and continue."

I think the situation should be logged clearly and the Vital bit should control whether it is an error or warning.

2. "If you don't want to take advantage of this undocumented schema, probably just have them author it in a new table as I called out in the WIP."

I'm torn on this one. Automatically calculating the dependencies is really nice but explicit authoring seems a reasonable trade off if it helps get the feature complete. As for reading the undocumented file format (if automatic calculating dependencies is the way to go), I'm not worried about if you're not worried about it. <smile/>

Are there any other open issues?

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Heath Stewart
Sent: Friday, May 26, 2017 11:05 AM
To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] WIP 5433

That is correct. I meant to mention that in my details below (hence either allowing them to be authored or harvested). That would facilitate the "already installed" mode of install for VSIXes. If no instances are found with all required dependencies, you could pipe a warning message (to prompt for bare MSIs) much like I did for the ref-counting features years back, such that a silent install just defaults to continuing - unless the VsixPackage is marked vital, in which case probably fail since it would be akin to not being able to install a file, service, etc. because requirements aren't meant.

If you don't want to take a dependency on undocumented formats, I could ask about releasing the nuget package we already build for internal purposes that contains our OM. Since VSIXes are OPC, the System.IO.Packaging namespace is already public and you could use that to extract catalog.json and load that into our OM to get dependencies if you'd prefer. I can't promise anything, and we'd almost definitely have to clean up comments.

From: Bob Arnson<mailto:bob at firegiant.com>
Sent: Friday, May 26, 2017 9:01 AM
To: Heath Stewart<mailto:heaths at outlook.com>; WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>
Subject: RE: [wix-devs] WIP 5433

If an extension had a dependency on anything other than core, is it possible to detect whether the extension "should" install (without potentially invoking a concurrent MSI installation)? It looks like ISetupPackageReference is as close as we get to detecting installed workloads/components. Is that right?

From: Heath Stewart [mailto:heaths at outlook.com]
Sent: Friday, 26 May, 2017 11:35
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>; Bob Arnson <bob at firegiant.com>
Subject: RE: [wix-devs] WIP 5433

@Bob Arnson<mailto:bob at firegiant.com> had asked on GitHub but I'll explain here so we can discuss / plan on wix-devs. I can try to work on it while I'm out on "vacation" next week, or someone else can take over. What free time I've had has been filled more with vswhere and the vssetup powershell cmdlets that the likes of cmake, boost, et. al. needed. Vsixbootstrapper existed as a backstop for wix but some people don't want bundles for their current single-MSI solutions.

So...

I asked those who own VSIXInstaller make a change that let callers pass no only the old /skuVersion and /skuName parameters for 14- support, but also the /instanceIds parameters for 15+ - that's all in one call. Without that, you'd need to schedule multiple calls for each SKU found (old and new) at install time. (And that would affect all methods of calling it - not just via MSI / WIX CA.) For example, if you specified /instanceIds 14- would not be updated at all.

That changed shipped in 15.2. So with the query API 1.9 or newer (i.e. RTW), you would enumerate instances. On any one of them, get the "enginePath" (ISetupInstance2::GetEnginePath). That will point to VSIXInstaller. If it's version is 15.0.26209.1 or newer, you will be able to use it. Set the VSIXInstaller path property we already use to that path.

At build, harvest (or allow for authoring of) the dependency workload and/or component IDs for <vs:VsixPackage>s. As you know, the VSIX is an OPC in just a ZIP container. Get the "catalog.json" from the root, and find in the "packages" array the 1 component (type: component) marked "extension": true. It's dependencies not in the catalog.json are dependencies on VS (or any 2017 product installed via the installer, really). If you don't want to take advantage of this undocumented schema, probably just have them author it in a new table as I called out in the WIP.

At runtime with that information, while you're enumerate instances above find all the instance IDs (ISetupInstance::GetInstanceId) that have those dependencies. Pass those as a comma separate list to /instanceIds:[list]. If the <vs:VsixPackage> also has a skuName and/or skuVersion (I believe both or none are required), pass those as well. One could - though it might add confusion - translate skuNames like "enterprise" to product IDs for 15+ like "Microsoft.VisualStudio.Product.Enterprise", but I'm not sure how worth it that would be. Don't think I've ever seen authoring that used those attributes.

This mode was the "install into instances with stuff already installed". If you wanted to enable "install-on-demand" mode, you wouldn't enumerate instances and just let VSIXInstaller.exe do its double-click-to-run code. The problem, though, is that if any dependencies try to install another MSI, it will fail and require the end user to repair VS (basically, complete the install) in the VS2017 Installer (codename "Willow", which has been out there for a while).

For end users before 15.2, you can't support both 15+ and 14- simultaneously without scheduling multiple sets of custom actions at install time. Not sure whether you'd just send an error or warning message through the pipe or stop with an error. My plan was to log a warning and continue.

From: Rob Mensching<mailto:rob at firegiant.com>
Sent: Friday, May 19, 2017 8:02 AM
To: WiX Toolset Developer Mailing List<mailto:wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] WIP 5433

That sounds right.

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Christopher Painter
Sent: Friday, May 19, 2017 6:01 AM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
Subject: Re: [wix-devs] WIP 5433

Brining this back to a more wix-devs related topic....

I was doing some testing and I wanted to see how things would go on a minimalist installation of 2017 Update 2.  I didn't select any optional workloads just the core ide feature.    Then I installed WiX  / Votive 2017 / IsWiX and all of the WiX project templates fail to construct with the error message

Could not load assembly ... Microsoft.VisualStudio.TemplateWizardInterface version 8.0..........

This might be something we (I basically use WiX templates as my building block for my templates) need to call out as a dependency in our vsix manifest.

From: Christopher Painter
Sent: Thursday, May 18, 2017 6:44 PM
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org>>
Subject: Re: [wix-devs] WIP 5433

I think I would be inclined to detect and block only.   Could you allow installation and then detect missing workloads when the extension initializes?

________________________________
From: wix-devs <wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:wix-devs-bounces at lists.wixtoolset.org>>> on behalf of Kaveesh Dashora <kaveeshd at googlemail.com<mailto:kaveeshd at googlemail.com<mailto:kaveeshd at googlemail.com%3cmailto:kaveeshd at googlemail.com>>>
Sent: Thursday, May 18, 2017 10:30 AM
To: WiX Toolset Developer Mailing List
Subject: Re: [wix-devs] WIP 5433

Thanks Christopher,

The issue which I have is not related to installing the extension. Even I deploy to the VS Extensions folder. And call devenv /updateconfiguration.

The issue which I have is how do I detect and install the missing workloads/components. I was able to use the Microsoft.VisualStudio.Setup.Configuration.Interop assembly to detect the visual studio versions and their components (thanks to Heath for that).

I am struggling with how would I install the required workloads/components if they are missing.

On 18-May-2017 7:24 PM, "Christopher Painter" <chrpai at iswix.com<mailto:chrpai at iswix.com<mailto:chrpai at iswix.com%3cmailto:chrpai at iswix.com>>> wrote:

> FWIW, I'm using the new functionality in WiX 3.11 for IsWiX 4.11 and
> it works quite well.  I use VSIX but deployed via MSI.  The changes
> for me in
> 2017 were:
>
>
> VS2017 requires use of COM interface to determine location.  WiX 3.11
> VSExtension *IS* handling this for me nicely.  Thanks guys for making
> the best of it.
>
>
> VS2017 no longer recognizes ZIP files placed in the ProjectTemplates
> directory.  I had to refactor so that the ZIPs were items in my VSIX
> manifest and deployed underneath the extensions directory structure.
>
>
> I deploy the files to [INSTALLLOCATION]\Templates  and then use CopyFile
> elements to clone them to the different VS directories.   I then call
> Devenv /setup (VSEtension)  to get them all registered.
>
>
> I like this approach because I can use a single MSI without a
> bootstrapper and without multiple VSIX download/installs  to
> distribute my core application and  extensions for all supported
> versions of VS in a single MSI.
>
>
> Bootstrappers are cool but I don't want one if I don't need one.
>
>
>
> PropertyRef and CustomActionRef:
>
> https://github.com/iswix-llc/iswix/blob/master/Source/
[https://avatars1.githubusercontent.com/u/5349881?v=3&s=400]<https://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/%3chttps://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/>>>

iswix-llc/iswix<https://github.com/iswix-llc/iswix/blob/master/Source/>
github.com
iswix - ISWIX

> Installer/IsWiX/Code/Product.wxs
>
>
> ProgressText for the CustomActionRef:
>
> https://github.com/iswix-llc/iswix/blob/master/Source/
[https://avatars1.githubusercontent.com/u/5349881?v=3&s=400]<https://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/%3chttps://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/>>>

iswix-llc/iswix<https://github.com/iswix-llc/iswix/blob/master/Source/>
github.com
iswix - ISWIX

> Installer/IsWiX/Code/UI.wxs
>
>
> CopyFile:
>
> https://github.com/iswix-llc/iswix/blob/master/Source/
[https://avatars1.githubusercontent.com/u/5349881?v=3&s=400]<https://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/<https://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/%3chttps://avatars1.githubusercontent.com/u/5349881?v=3&s=400%5d%3chttps://github.com/iswix-llc/iswix/blob/master/Source/>>>

iswix-llc/iswix<https://github.com/iswix-llc/iswix/blob/master/Source/>
github.com
iswix - ISWIX

> Installer/IsWiXNewAddInMM/IsWiXNewAddInMM.wxs
>
> [https://avatars1.githubusercontent.com/u/5349881?v=3&s=400]<https://
<https://%0b>> github.com/iswix-llc/iswix/blob/master/Source/Installer/IsWiXNewAddInMM/
> IsWiXNewAddInMM.wxs>
>
> iswix-llc/iswix<https://github.com/iswix-llc/iswix/
<https://github.com/iswix-llc/iswix/%0b>> blob/master/Source/Installer/IsWiXNewAddInMM/IsWiXNewAddInMM.wxs>
> github.com
> iswix - ISWIX
>
>
>
>
>
>
> ________________________________
> From: wix-devs
> <wix-devs-bounces at lists.wixtoolset.org<mailto:wix-devs-bounces at lists.w
<mailto:wix-devs-bounces at lists.wixtoolset.org%3cmailto:wix-devs-bounces at lists.w%0b>> ixtoolset.org>> on behalf of Kaveesh Dashora
> <kaveeshd at googlemail.com<mailto:kaveeshd at googlemail.com<mailto:kaveesh
> d at googlemail.com%3cmailto:kaveeshd at googlemail.com>>>
> Sent: Thursday, May 18, 2017 6:48 AM
> To: Heath Stewart
> Cc: WiX Toolset Developer Mailing List; Kaveesh Dashora
> Subject: Re: [wix-devs] WIP 5433
>
> Thank you... I will look into it and let you know if I have more
> questions
>
> Regards,
> Kaveesh
>
> On Thu, May 18, 2017 at 2:22 AM, Heath Stewart <
> Heath.Stewart at microsoft.com<mailto:Heath.Stewart at microsoft.com<mailto:
> Heath.Stewart at microsoft.com%3cmailto:Heath.Stewart at microsoft.com>>>
> wrote:
>
> > We do document that at https://docs.microsoft.com/en-
>
> [https://docs.microsoft.com/_themes/docs.theme/master/en-
> us/_themes/images/microsoft-header.png]<https://docs.microsoft.com/en-
<https://docs.microsoft.com/en-%0b>> >
>
> 404 - Content Not Found<https://docs.microsoft.com/en->
> docs.microsoft.com
>
>
>
> > us/visualstudio/install/use-command-line-parameters-to-
> > install-visual-studio but you're back to the same problem: if any
> > workloads or components install MSIs (we still have a large number
> > of
> them,
> > though most were reduced to our newer VSIX format), the operation
> > will
> fail
> > because MSIs can't install concurrently. So you wouldn't be able to
> invoke
> > the installer via your MSI. You'd have to have a utility EXE as part
> > of your chain that would do that - and for whatever instances the
> > user would want (instance include SxS installations of a particular
> > major release
> like
> > VS2017 / 15.x, or even different major releases like 15.x and 16.x).
> >
> >
> >
> > *Heath Stewart*
> >
> > Visual Studio, Microsoft
> >
> > http://blogs.msdn.microsoft.com/heaths
>
> Setup & Install by Heath Stewart | About Windows Installer, the .NET
> Framework, and Visual Studio.<http://blogs.msdn.microsoft.com/heaths>
> blogs.msdn.microsoft.com
> About Windows Installer, the .NET Framework, and Visual Studio.
>
>
>
> >
> >
> >
> > *From:* kaveeshd at gmail.com<mailto:kaveeshd at gmail.com>
> > [mailto:kaveeshd at gmail.com] * On Behalf Of
> *Kaveesh
> > Dashora
> > *Sent:* Wednesday, May 17, 2017 1:31 AM
> > *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.wixtool
> > set.org>>
> > >
> > *Cc:* Rob Mensching
> > <rob at firegiant.com<mailto:rob at firegiant.com<mailto:rob at firegiant.com
> > %3cmailto:rob at firegiant.com>>>;
> > Heath Stewart <
> > Heath.Stewart at microsoft.com<mailto:Heath.Stewart at microsoft.com<mailt
> > o:Heath.Stewart at microsoft.com%3cmailto:Heath.Stewart at microsoft.com>>
> > >
> > *Subject:* Re: [wix-devs] WIP 5433
> >
> >
> >
> > For our MSI's we haven''t been using the VSIXInstaller. We deploy
> > the
> VSIX
> > contents directly to the Visual Studio Extensions folder.
> >
> > We had an issue with some of our customers, they were not able to
> > install the product with the VSIXInstaller.
> >
> > And then had to move to the non VSIXInstaller way.
> >
> >
> >
> > Is there any other way to install the necessary workloads/components
> other
> > than VSIXInstaller through the MSI?
> >
> >
> >
> > On Wed, May 17, 2017 at 1:25 AM, Heath Stewart <
> > Heath.Stewart at microsoft.com<mailto:Heath.Stewart at microsoft.com<mailto:Heath.Stewart at microsoft.com%3cmailto:Heath.Stewart at microsoft.com>>> wrote:
> >
> > Yes, detection is implemented with almost all the old properties
> > supported, but install is not. We will not be able to support
> > installing VSIXes that might cause MSIs to be installed (basically,
> > VSIXes could
> only
> > reliably depend on the CoreEditor workload since all that has to be
> > installed at the very least). For that, see
> https://github.com/Microsoft/
> > vsixbootstrapper
> > <https://na01.safelinks.protection.outlook.com/?url=
<https://na01.safelinks.protection.outlook.com/?url=%0b>> https%3A%2F%2Fgithub.com%2FMicrosoft%2Fvsixbootstrapper&data=02%
> 7C01%7CHeath.Stewart%40microsoft.com%7C46d7239c15cf40887f4e08d49cff161
> 0%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636306066787502303&sdata=
> Y1q1Qz9w0Th0a%2FyZoyqNUNf0EeeexG8uMgv3%2BCINxec%3D&reserved=0>
> > to effectively install the VSIX as a separate package via Burn directly.
> >
> > I'm finding if/when the necessary support in the VSIXInstaller.exe
> > itself went public, but I can say that we will require all
> > dependency workloads
> to
> > be installed or fail the VSIX (which if the associated File is
> > vital,
> will
> > fail the install). This is because MSIs can't be installed
> > concurrently, and we can join sessions as a chained install because
> > they cross process boundaries.
> >
> > Heath Stewart
> > Visual Studio, Microsoft
> > http://blogs.msdn.microsoft.com/heaths
> > <https://na01.safelinks.protection.outlook.com/?url=
<https://na01.safelinks.protection.outlook.com/?url=%0b>> http%3A%2F%2Fblogs.msdn.microsoft.com%2Fheaths&data=
> 02%7C01%7CHeath.Stewart%40microsoft.com%7C46d7239c15cf40887f4e08d49cff
> 1610%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%
> 7C636306066787502303&sdata=1RFaGyBGZDkeb4LjkO4LfJI%
> 2FVQ9wPfib7B0nY3AbTiQ%3D&reserved=0>
> >
> > -----Original Message-----
> > From: Rob Mensching [mailto:rob at firegiant.com]
> > Sent: Tuesday, May 16, 2017 9:23 AM
> > 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.wixtool
> > set.org>>
> > >
> > Cc: Heath Stewart
> > <Heath.Stewart at microsoft.com<mailto:Heath.Stewart at microsoft.com<mail
> > to:Heath.Stewart at microsoft.com%3cmailto:Heath.Stewart at microsoft.com>
> > >>
> > Subject: RE: [wix-devs] WIP 5433
> >
> > IIRC, detect is implemented. Install is dependent on changes from
> > Visual Studio team. Heath would know latest status.
> >
> >
> > -----Original Message-----
> > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On
> > Behalf Of Kaveesh Dashora
> > Sent: Monday, May 15, 2017 10:44 PM
> > To:
> > wix-devs at lists.wixtoolset.org<mailto:wix-devs at lists.wixtoolset.org<m
> > ailto:wix-devs at lists.wixtoolset.org%3cmailto:wix-devs at lists.wixtools
> > et.org>>
> > Subject: [wix-devs] WIP 5433
> >
> > Hi,
> >
> > I am not sure if this is a wix-devs question.
> >
> > I was just going through WIP 5433 - Add support to detect and
> > install
> VSIX
> > packages into VS2017.
> >
> > https://na01.safelinks.protection.outlook.com/?url=
> > http%3A%2F%2Fwixtoolset.org%2Fdevelopment%2Fwips%2F5433-
> > add-&data=02%7C01%7CHeath.Stewart%40microsoft.com%
> > 7C6eb3d6472afb43b3be7408d49c77d780%7C72f988bf86f141af91ab2d7cd011
> > db47%7C1%7C0%7C636305485912326297&sdata=0rqDMm69LlbifWVbFadzFb7Y5azn
> > Ea
> > 6TUBWUheP%2BBlY%3D&reserved=0
> >
> > support-to-detect-and-install-vsix-packages-into-vs15/
> >
> > Has this been implemented in WiX 3.11? If yes is there a
> > documentation which I can use for my installer?
> >
> > Regards,
> > Kaveesh
> > ____________________________________________________________________
> > WiX Toolset Developer Mailing List provided by FireGiant
> > http://www.firegiant.com/
> > <https://na01.safelinks.protection.outlook.com/?url=
<https://na01.safelinks.protection.outlook.com/?url=%0b>> http%3A%2F%2Fwww.firegiant.com%2F&data=02%7C01%7CHeath.
> Stewart%40microsoft.com%7C46d7239c15cf40887f4e08d49cff1610%
> 7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636306066787502303&sdata=
> DV2jp8hedT21n75zGxD3uaOdzupua3HFjVIo7dVofIw%3D&reserved=0>
> >
> >
> >
> ____________________________________________________________________
> 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/
____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant http://www.firegiant.com/