[wix-devs] Selection of compatible VS instances

Sun Jan 29 10:33:11 PST 2017

Fair enough. It would only be temporary until harvesting of workloads and components is implemented. If not a VSIX v3 the would be no need.

- Heath via Nine<http://www.9folders.com/> on Android
________________________________
From: Bob Arnson <bob at firegiant.com>
Sent: Jan 29, 2017 10:22 AM
To: WiX Toolset Developer Mailing List
Subject: Re: [wix-devs] Selection of compatible VS instances

Then I agree with Sean; we need a warning if there are no dependencies authored. Doc isn't enough. It sucks because it's a useless warning for v1 and v2 VSIXes but...

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Heath Stewart
Sent: Sunday, 29 January, 2017 13:01
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Selection of compatible VS instances

We can't simply skip them. We did consider that. It will leave you with a partly installed workload. We are also considering how we might defer it (as Sean also suggested yesterday) but that won't happen by RTW.

This whole thing is new (and fulfills tenets across all of VS) and we will be bringing certain functionality incrementally. Most extensions are installed via the marketplace and extension manager so that was our primary target.

- Heath via Nine<http://www.9folders.com/> on Android ________________________________
From: Bob Arnson <bob at firegiant.com>
Sent: Jan 29, 2017 9:13 AM
To: WiX Toolset Developer Mailing List
Subject: Re: [wix-devs] Selection of compatible VS instances

The only way to avoid the nested-MSI problem is to prevent VSIXInstaller.exe from installing components; Heath, is there a switch to prevent that? Or to make /q skip it? (Nothing like that shown in RC3 help but then neither is instance support.)

-----Original Message-----
From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org] On Behalf Of Sean Hall
Sent: Saturday, 28 January, 2017 22:06
To: WiX Toolset Developer Mailing List <wix-devs at lists.wixtoolset.org>
Subject: Re: [wix-devs] Selection of compatible VS instances

To clarify, my input is:

1) Thank you for spending your time writing up the WIP and contributing this functionality to WiX.
2) Microsoft needs to address this nested MSI install problem ASAP.
3) We should take the MSI functionality, and WiX needs to emit a warning at build time about installing VSIX v3 packages inside an MSI.

On Sat, Jan 28, 2017 at 8:52 PM, Heath Stewart <heaths at outlook.com> wrote:

> I assure you the Extensibility team discussed this with many partners
> prior to RC1. There are more capabilities with the new model than in
> the past. Partners can and have been able to do more they couldn't before.
>
>
>
> So what are you saying? Should I pull the existing VS15 properties
> (they don't work anyway) and not add support to MSIs, only Burn? I
> think that would be far more disruptive than what I have laid out in
> the WIP for solving the workload problem.
>
>
>
> Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986> for
> Windows 10
>
>
>
> *From: *Sean Hall <r.sean.hall at gmail.com>
> *Sent: *Saturday, January 28, 2017 6:36 PM
> *To: *WiX Toolset Developer Mailing List
> <wix-devs at lists.wixtoolset.org>
> *Subject: *Re: [wix-devs] Selection of compatible VS instances
>
>
> "This is the new extensibility model"
>
> This is exactly why I have not jumped on here before now. Microsoft/VS
> chose to completely redesign the extensibility model without any
> public RFCs, and didn't release it until RC1. IMO, the functionality
> in this WIP should have been designed and implemented alongside the
> redesign of the extensibility model. At this point, we're just having
> to figure out the best way to provide WiX users the functionality of a broken design.
>
> Bob said "I'm -1 on adding any MSI support for VSIX packages to WiX,
> until it is fixed".  I've been addressing the MSI support part of this
> discussion. Adding a VsixPackage element to bundles is a good idea and
> could theoretically be the only way that WiX supports installing VSIX
> v3 packages (I am not advocating this).
>
> On Sat, Jan 28, 2017 at 8:12 PM, Heath Stewart <heaths at outlook.com> wrote:
>
> > We do, and the new model reflects that. You can now install dependencies.
> > You couldn't do that before. VS defaults to a smaller, faster
> > install, so on-demand was necessary. As we reduce MSIs this will go away.
> >
> > This is the new extensibility model and we're trying to get support
> > in WiX. Yes, it will be incremental but right now it seems the
> > roadblock to developers even having any story for installing
> > extensions via MSI is whether you are going to merge the feature branch.
> >
> > The workaround is to use burn to bootstrap VSIXInstaller naked MSIs
> > won't work. Lots of things have changed by design, and I'm surprised
> > you don't consider using a burn bundle an option over using a WiX-built MSI.
> >
> > - Heath via Nine<http://www.9folders.com/> on Android
> > ________________________________
> > From: Sean Hall <r.sean.hall at gmail.com>
> > Sent: Jan 28, 2017 6:06 PM
> > To: WiX Toolset Developer Mailing List
> > Subject: Re: [wix-devs] Selection of compatible VS instances
> >
> > Up until now, extension authors have been able to install their
> > extension in a naked MSI.  Returning an error code at runtime is
> > pretty useless and forces them to completely change how they deliver
> > their extension.  I
> would
> > hope Microsoft would care more than this for the people extending VS.
> >
> > On Jan 28, 2017 7:57 PM, "Heath Stewart" <heaths at outlook.com> wrote:
> >
> > > As stated previously, if they author or harvest dependent
> > > workloads or components, we will eventually (probably post-RTW
> > > given our current
> > plans)
> > > return an error code we can map to a more useful error message. We
> cannot
> > > eliminate all nested MSIs at this time (some are legacy, but we
> > > are
> > working
> > > to reduce them; but many are third-party).
> > >
> > >
> > >
> > > Also called out in the WIP and further below, extension developers
> could
> > > install via an ExePackage in Burn.
> > >
> > >
> > >
> > > Sent from Mail <https://go.microsoft.com/fwlink/?LinkId=550986>
> > > for Windows 10
> > >
> > >
> > >
> > > *From: *Sean Hall <r.sean.hall at gmail.com>
> > > *Sent: *Saturday, January 28, 2017 5:52 PM
> > > *To: *WiX Toolset Developer Mailing List <
> wix-devs at lists.wixtoolset.org>
> > > *Subject: *Re: [wix-devs] Selection of compatible VS instances
> > >
> > >
> > > I'm going to have to agree with Bob here, installing an extension
> > > for
> > > VS2017 from an MSI is seriously broken as currently designed.
> > > Based on
> > the
> > > modular nature VS2017, extension authors are not going to be able
> > > to
> > assume
> > > that their required components are installed and they will have no
> > > idea whether their required components are delivered by MSI.  This
> > > means
> that
> > > there is no way for them or WiX to know at compile time whether
> > > their extension has any chance of getting installed by shipping a
> > > naked
> MSI.  I
> > > can think of the following solutions:
> > >
> > > 1) Microsoft eliminates the nested MSI install problem by
> > > requiring optional VS components to be non-MSI.
> > > 2) Microsoft adds the functionality in VSIXInstaller.exe and VS to
> > > be
> > able
> > > to accept an install request during an MSI install, and complete
> > > the install at a later time.
> > >
> > > The last resort would be for WiX to emit a warning at compile time
> saying
> > > that installing VS extensions inside of an MSI may fail due to
> requiring
> > > nested MSI installs.
> > >
> > > On Sat, Jan 28, 2017 at 3:32 PM, Bob Arnson <bob at firegiant.com> wrote:
> > >
> > > > #alternativefacts. For my install of RC3 Pro with C++ and
> > > > desktop
> .NET,
> > > > it's 246 VSIX packages and 37 MSI packages.
> > > >
> > > > -----Original Message-----
> > > > From: wix-devs [mailto:wix-devs-bounces at lists.wixtoolset.org
> > > <wix-devs-bounces at lists.wixtoolset.org>] On Behalf
> > > > Of Sean Hall
> > > > Sent: Saturday, 28 January, 2017 16:13
> > > > To: WiX Toolset Developer Mailing List <
> wix-devs at lists.wixtoolset.org>
> > > > Subject: Re: [wix-devs] Selection of compatible VS instances
> > > >
> > > > Can you give an example of a component or workload that is
> > > > installed
> by
> > > > MSI?  I thought all parts of the Visual Studio install have been
> > migrated
> > > > away from MSI.
> > > >
> > > > On Sat, Jan 28, 2017 at 1:17 PM, Heath Stewart
> > > > <heaths at outlook.com>
> > > wrote:
> > > >
> > > > > VSIX v3 are backward compatible. They are still valid v2s that
> > > > > work downlevel. I'm not sure what makes it a v1, but if v2s
> > > > > are backward compatible with v1s then that will continue to
> > > > > work. I worked
> closely
> > > > > with the Extensibility team to ensure backward compatibility
> > > > > long
> ago
> > > > > (hence extending the formats - unlike what VSTS and VSCode use
> > > > > as
> > > > ".vsix" files).
> > > > >
> > > > > I'm not suggesting that WiX doesn't include harvesting
> > > > > support. I'm saying that the initial feature will be used by a
> > > > > few internal and external partner that we've already
> > > > > instructed to author
> > dependencies.
> > > > >
> > > > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986>
> > > > > for Windows 10
> > > > >
> > > > > From: Bob Arnson<mailto:bob at firegiant.com <bob at firegiant.com>>
> > > > > Sent: Saturday, January 28, 2017 11:04 AM
> > > > > To: Heath Stewart<mailto:heaths at outlook.com
> > > > > <heaths at outlook.com>>;
> > > WiX Toolset Developer
> > > > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> > > <wix-devs at lists.wixtoolset.org>>; Rob
> > > > Mensching<mailto:
> > > > > rob at firegiant.com>
> > > > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > > > >
> > > > > I'm not a fan of fail-by-default: If you don't author the
> dependency
> > > > > data, the user runs the risk of failure and undesirable behavior.
> I'm
> > > > > willing to consider that I'm being paranoid and if we document
> > > > > it,
> we
> > > > > can wash our hands of the results. Rob? Sean? Anybody else?
> > > > >
> > > > > The WIP doesn't describe what I imagine to be a common
> > > > > scenario (including WiX, if we use this solution): a VSIX v3
> > > > > for Dev15/14
> and
> > > > > v1 for everything else (until we drop VS2010 support).
> > > > >
> > > > > From: Heath Stewart [mailto:heaths at outlook.com
> > > > > <heaths at outlook.com
> >]
> > > > > Sent: Friday, 27 January, 2017 17:42
> > > > > To: Bob Arnson <bob at firegiant.com>; WiX Toolset Developer
> > > > > Mailing
> > List
> > > > > < wix-devs at lists.wixtoolset.org>; Rob Mensching
> > > > > <rob at firegiant.com
> >
> > > > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > > > >
> > > > > That we can't nest MSIs that way, yes, an unfortunate bug but
> > > > > just
> > how
> > > > > MSI works. The install-on-demand is because VS2017 is much
> > > > > lighter weight. The default install is small and quick
> > > > > (roughly equivalent
> to
> > > > > VSCode). That extensions can install features they need was a
> > > > > desirable feature almost from the start.
> > > > >
> > > > > I could do a warning if there are no dependencies authored,
> > > > > but
> we'd
> > > > > have to know during build time it's a VSIX v3 - in which case,
> > > > > we
> may
> > > > > as well harvest the dependencies. I'm certainly open to doing
> > > > > that, but may not be in the first merge (we have a few
> > > > > partners -
> internal
> > > > > and external - that need unblocked). We certainly wouldn't
> > > > > want to warn for VSIX v2s, which I imagine - for now - most
> > > > > VSIX packages
> > will
> > > > > be. Or are you suggesting that in the interim? I have another
> > > > > of
> > other
> > > > > projects related to this on the docket (like vswhere.exe for
> > > > > batch support, like cmake), so while harvesting IDs is
> > > > > important someone else could also jump in with that if we need to get it done sooner.
> > > > >
> > > > > The error case isn't great, but it's also not horrible. If the
> > package
> > > > > was marked non-vital and didn't fail the third-party install,
> > > > > when
> VS
> > > > > is started it will find that the installation didn't not
> > > > > complete
> and
> > > > > prompt to repair it, which would put the product into the
> originally
> > > > > requested state. We considered this when thinking about
> > possibilities,
> > > > > but decided the perception was bad. It is, but VS will prompt
> > > > > to
> put
> > > the
> > > > product right.
> > > > >
> > > > > The WIP does actually call this out how downlevel is
> > > > > supported. The /instanceIds switch is only added if we found
> > > > > instances (which
> means
> > > > > it's
> > > > > Dev15+) and will overwrite the VSIX path variable that is
> > > > > Dev15+otherwise still
> > > > > set by AppSearch for Dev14-. VSIXInstaller.exe itself will
> > > > > install
> to
> > > > > multiple versions. I've worked with their team to get
> > > > > VSIXInstaller.exe doing as much as the work as possible, which
> > > > > is
> why
> > > > > we can leave the existing VSIX CAs almost entirely as-is.
> > > > > Prior
> ideas
> > > > > including scheduling the batch of typical CAs (install,
> > > > > rollback,
> > > > > uninstall) per-package per-version but would be far more
> > > > > expensive
> to
> > > > > develop, more prone to error, slower to install, and less
> > declarative.
> > > > >
> > > > > Sent from Mail<https://go.microsoft.com/fwlink/?LinkId=550986>
> > > > > for Windows 10
> > > > >
> > > > > From: Bob Arnson<mailto:bob at firegiant.com <bob at firegiant.com>>
> > > > > Sent: Friday, January 27, 2017 2:29 PM
> > > > > To: Heath Stewart<mailto:heaths at outlook.com
> > > > > <heaths at outlook.com>>;
> > > WiX Toolset Developer
> > > > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> > > <wix-devs at lists.wixtoolset.org>>; Rob
> > > > Mensching<mailto:
> > > > > rob at firegiant.com>
> > > > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > > > >
> > > > > Ah, I see. It's not a bug, it's an "alternative feature." :)
> > > > >
> > > > > Today, for VS2015, a package or bundle can do a registry
> > > > > search and use the results in a launch condition, feature
> > > > > condition, or
> package
> > > > > InstallCondition. The equivalent for VS2017 would be to detect
> > whether
> > > > > there are any compatible (with all necessary components and
> > workloads)
> > > > > instances installed. That ensures that there won't be failures
> > > > > for known reasons.
> > > > >
> > > > > As long as the immediate custom action (shared as a BA
> > > > > function)
> can
> > > > > safely run early enough for launch conditions, feature
> > > > > conditions,
> > and
> > > > > install conditions, and the deferred CA only invokes
> > > > > VSIXinstaller
> > for
> > > > > compatible instances, then I'm +1. I think we need a warning
> > (probably
> > > > > an
> > > > > error) if dependencies aren't specified/harvested; it's
> unacceptable
> > > > > that you can end up in a scenario where stuff is accidentally
> > > > > installed or that would fail because of a nested install.
> > > > >
> > > > > The WIP should describe how VsixPackage should be authored to
> support
> > > > > multiple versions of VS, downlevel and 15+.
> > > > >
> > > > > From: Heath Stewart [mailto:heaths at outlook.com
> > > > > <heaths at outlook.com
> >]
> > > > > Sent: Friday, 27 January, 2017 12:45
> > > > > 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>>; Rob Mensching
> > > > > <rob at firegiant.com
> > > > <mailto:
> > > > > rob at firegiant.com>>
> > > > > Subject: RE: [wix-devs] Selection of compatible VS instances
> > > > >
> > > > >
> > > > > 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 <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
> > > <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
> > > <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<mailto:rob 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] 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
> > > > > VS2017+ 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
> > > > > <heaths at outlook.com
> >>
> > > > > Sent: Wednesday, January 25, 2017 10:21 AM
> > > > > To: Rob Mensching<mailto:rob at firegiant.com
> > > > > <rob at firegiant.com>>;
> WiX
> > > Toolset Developer
> > > > > Mailing List<mailto:wix-devs at lists.wixtoolset.org
> > > <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
> > > > > <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
> > > <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
> > > > > <mailto:wix-devs at lists.wixtoolset.org <
> 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/
> > > > > ____________________________________________________________
> ________
> > > > > 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/ ____________________________________________________________________
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/