[wix-devs] WIP 5433

Kaveesh Dashora kaveeshd at googlemail.com
Wed Jun 7 06:10:10 PDT 2017


Hi Heath,

I had a look at the link for command line installation of visual studio.

https://docs.microsoft.com/en-us/visualstudio/install/use-command-line-parameters-to-install-visual-studio

I plan to have the following.

1. Detect Visual Studio Versions and find out their components
2. Compare and find out the components which are missing from the
vsixmanifest
3. In a case there are missing components from the selected Visual Studio,
during the installation the visual studio installer will be downloaded and
the missing components will be installed through a silent execution.
4. Once point 4 succeeds, the vs extension will be installed in visual
studio.

All the above will happen through a custom burn hi.

I have a few questions,

1. I was not able to find a way to retrieve the installation
progress/status from the vs installer when it is running in silent mode. Is
there a way to get the current progress of the installation.
2. As I will be downloading the vs installer and running it silently, will
I need to show the Microsoft EULA. As the user already has visual studio
installed the user would have already accepted the EULA.

Regards,
Kaveesh


On 03-Jun-2017 7:11 AM, "Heath Stewart" <heaths at outlook.com> wrote:

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@
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@
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:chrpa
i 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/

____________________________________________________________________
WiX Toolset Developer Mailing List provided by FireGiant
http://www.firegiant.com/


More information about the wix-devs mailing list