Re: [WiX-users] Env variables don't get deleted

[Rob Hamflett]

Setting Permanent="yes" on the Component or forgetting to give it a GUID would 
make the env var 
change permanent.  Do either of these apply?

Rob

sandun css wrote:
> Hi,
> 
> I set few env variables from my msi. But they don't get deleted when I
> uninstall them. This is my code,
> 
>Value='[INSTALLDIR]etc\middleware.cfg' System='yes' Permanent='no'/>
> What can be the problem?
> 
> Thanks,
> Sandun
> --


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Env variables don't get deleted

[sandun css]

Hi,

I set few env variables from my msi. But they don't get deleted when I
uninstall them. This is my code,

  
What can be the problem?

Thanks,
Sandun
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Boolean paramaters

[sandun css]

Thanks for the replies. I was able to get it done with 'MYFLAG~="true"'
approach.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Customing WixUI

[Quinton Tormanen]

In the WiX 3.0 help topic "Customizing the WixUI Dialog Sets", what is
meant by "your custom set fragment" in the last paragraph in that the
"Customizing dialog sets" section:

You do not need to rebuild WixUIExtension to customize
the WixUI dialog sets in this manner. All you need to
do is compile your dialog fragment and your custom set
fragment with the rest of your setup project. As long
as you continue using the WixUIExtension, your custom
fragments will be able to find the built-in dialog
fragments.

I want to remove the LicenseAgreementDlg page, which only takes a few
changes. Should I copy the meat of WixUI_InstallDir.wxs and paste it
directly into my project's WXS file, modifying it there? Or should I
copy/paste it into a separate new fragment file that get's included by
light? I've confirmed that this works, and I assume that the above two
options are just a matter of preference. Or, is there some other way of
using the WixUI_InstallDir UI fragment and just applying diffs to it?
For example, can I just do 1
  1
  LicenseAccepted = "1"
  1

I would like to replace them with the following:

  CostingComplete = 1
  1
  1

Basically, I just unlink the LicenseAgreementDlg, and then I added back
in the WaitForCostingDlg that was triggered on the Next in the license
dialog box (not sure if that is necessary).

So, what is the proper way to do custom dialog sets?

Thanks.

Quinton Tormanen
Software Engineer
Delta Computer Systems, Inc.
http://www.deltamotion.com


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[troy hostetter]

No .. it does not have an associated component.  The website does exist on
the server.  Here's what we have in the IIS metabase file .. so it does
exist:




My iis:WebSite and iis:WebAddress tags point to the ServerComment and port.

I recall seeing this suggestion on another post, however when i associate a
component to the locator record, it requires a Directory element and I am
unsure what value to place here.  Our web site is a root web site in IIS, on
which we want to create several virtual directories.

Ideally, we do not want to create a web site .. we only want to create
virtual directories.  A web site locator record should be all that we need.

- Troy

On Wed, Jul 1, 2009 at 3:23 PM, Mike Carlson (DEV DIV) <
mica...@microsoft.com> wrote:

> Does your website have a component associated with it?
>
> The log sounds as though you're using a website locator record (which is
> simply a website with no associated component), and the website it's trying
> to locate on the machine doesn't exist (in which case the install is
> intended to fail). If you want the website to be created if it doesn't
> exist, the website must be associated with a component.
>
> Thanks,
> Mike Carlson
>
> -Original Message-
> From: troy hostetter [mailto:troy.hostet...@gmail.com]
> Sent: Wednesday, July 01, 2009 11:54 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to
> create web application
>
> Mike -
>
> Installed version 3.0.5419, built msi, and am now getting this error during
> install:
>
> Action 18:36:40: StartMetabaseTransaction. Starting IIS Metabase
> Transaction
> Action 18:36:40: RollbackMetabaseTransaction. Rolling back IIS Metabase
> Transaction
> Action 18:36:40: CommitMetabaseTransaction. Committing IIS Metabase
> Transaction
> Action 18:36:40: ConfigureIIsExec.
> ConfigureIIsExec:  A matching web object in memory was found, but the web
> object in memory has no associated base
> ConfigureIIsExec:  Error 0x80070002: Failed to find Web base
> ConfigureIIsExec:  Error 0x80070002: Failed to get base of web:
> WS__kCTools.WebServices for VirtualDir
> ConfigureIIsExec:  Error 0x80070002: failed while processing WebVirtualDirs
> Error 26004. Failed while processing WebVirtualDirs.  (-2147024894
> )
> MSI (s) (78!98) [18:37:50:712]: Product: kCTools (64 bit) -- Error 26004.
> Failed while processing WebVirtualDirs.  (-2147024894 )
>
> Action ended 18:37:50: InstallFinalize. Return value 3.
> Action 18:37:50: Rollback. Rolling back action:
> Rollback: ConfigureIIsExec
> Rollback: Committing IIS Metabase Transaction
> Rollback: Rolling back IIS Metabase Transaction
> Rollback: Starting IIS Metabase Transaction
> Rollback: Copying new files
> Rollback: Creating folders
> Rollback: Deleting services
> Rollback: Stopping services
> Rollback: Updating component registration
> Action ended 18:38:07: INSTALL. Return value 3.
>
> Thanks,
> - Troy
>
> On Wed, Jul 1, 2009 at 12:51 PM, Mike Carlson (DEV DIV) <
> mica...@microsoft.com> wrote:
>
> > A *lot* has changed in the IIS custom actions since WiX v3.0.4805,
> > including an error that looks very similar to this. First, I would
> upgrade
> > to the latest WiX 3.0 build (v3.0.5419) and see if you still have a
> problem
> > after that.
> >
> > Thanks,
> > Mike Carlson
> >
> > -Original Message-
> > From: troy hostetter [mailto:troy.hostet...@gmail.com]
> > Sent: Wednesday, July 01, 2009 9:31 AM
> > To: General discussion for Windows Installer XML toolset.
> > Subject: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to
> > create web application
> >
> > We are getting the following error and are not sure why.  We have been
> > successful at creating virtual directories in several other environments
> > (development, integration, etc.), however the environment we are
> currently
> > deploying to is having issues :(
> >
> > Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase
> > Transaction
> > Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
> > Transaction
> > Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
> > Transaction
> > Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and
> Values
> > WriteMetabaseChanges:  Error 0x80070057: failed to create web
> application:
> > /Root/SecurityAutomation
> > Error 26105. Failed to create web application.  (-2147024809
> > /Root/SecurityAutomation  )
> > MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
> > Failed to create web application.  (-2147024809
> > /Root/SecurityAutomation  )
> >
> > WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
> > Action ended 15:56:04: InstallFinalize. Return value 3.
> > Action 15:56:04: Rollback. Rolling back action:
> > Rollback: Installing Metabase Keys and Values
> > Rollback: Committing IIS Metabase Transaction
> > Rollback: Rolling back IIS Metabase Transac

Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[Mike Carlson (DEV DIV)]

Does your website have a component associated with it?

The log sounds as though you're using a website locator record (which is simply 
a website with no associated component), and the website it's trying to locate 
on the machine doesn't exist (in which case the install is intended to fail). 
If you want the website to be created if it doesn't exist, the website must be 
associated with a component.

Thanks,
Mike Carlson

-Original Message-
From: troy hostetter [mailto:troy.hostet...@gmail.com] 
Sent: Wednesday, July 01, 2009 11:54 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to 
create web application

Mike -

Installed version 3.0.5419, built msi, and am now getting this error during
install:

Action 18:36:40: StartMetabaseTransaction. Starting IIS Metabase Transaction
Action 18:36:40: RollbackMetabaseTransaction. Rolling back IIS Metabase
Transaction
Action 18:36:40: CommitMetabaseTransaction. Committing IIS Metabase
Transaction
Action 18:36:40: ConfigureIIsExec.
ConfigureIIsExec:  A matching web object in memory was found, but the web
object in memory has no associated base
ConfigureIIsExec:  Error 0x80070002: Failed to find Web base
ConfigureIIsExec:  Error 0x80070002: Failed to get base of web:
WS__kCTools.WebServices for VirtualDir
ConfigureIIsExec:  Error 0x80070002: failed while processing WebVirtualDirs
Error 26004. Failed while processing WebVirtualDirs.  (-2147024894 )
MSI (s) (78!98) [18:37:50:712]: Product: kCTools (64 bit) -- Error 26004.
Failed while processing WebVirtualDirs.  (-2147024894 )

Action ended 18:37:50: InstallFinalize. Return value 3.
Action 18:37:50: Rollback. Rolling back action:
Rollback: ConfigureIIsExec
Rollback: Committing IIS Metabase Transaction
Rollback: Rolling back IIS Metabase Transaction
Rollback: Starting IIS Metabase Transaction
Rollback: Copying new files
Rollback: Creating folders
Rollback: Deleting services
Rollback: Stopping services
Rollback: Updating component registration
Action ended 18:38:07: INSTALL. Return value 3.

Thanks,
- Troy

On Wed, Jul 1, 2009 at 12:51 PM, Mike Carlson (DEV DIV) <
mica...@microsoft.com> wrote:

> A *lot* has changed in the IIS custom actions since WiX v3.0.4805,
> including an error that looks very similar to this. First, I would upgrade
> to the latest WiX 3.0 build (v3.0.5419) and see if you still have a problem
> after that.
>
> Thanks,
> Mike Carlson
>
> -Original Message-
> From: troy hostetter [mailto:troy.hostet...@gmail.com]
> Sent: Wednesday, July 01, 2009 9:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to
> create web application
>
> We are getting the following error and are not sure why.  We have been
> successful at creating virtual directories in several other environments
> (development, integration, etc.), however the environment we are currently
> deploying to is having issues :(
>
> Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase
> Transaction
> Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
> Transaction
> Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
> Transaction
> Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and Values
> WriteMetabaseChanges:  Error 0x80070057: failed to create web application:
> /Root/SecurityAutomation
> Error 26105. Failed to create web application.  (-2147024809
> /Root/SecurityAutomation  )
> MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
> Failed to create web application.  (-2147024809
> /Root/SecurityAutomation  )
>
> WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
> Action ended 15:56:04: InstallFinalize. Return value 3.
> Action 15:56:04: Rollback. Rolling back action:
> Rollback: Installing Metabase Keys and Values
> Rollback: Committing IIS Metabase Transaction
> Rollback: Rolling back IIS Metabase Transaction
> Rollback: Starting IIS Metabase Transaction
> Rollback: Copying new files
> Rollback: Creating folders
> Rollback: Deleting services
> Rollback: Stopping services
> Rollback: Updating component registration
> Action ended 15:56:22: INSTALL. Return value 3.
>
> Here is our WiX IIS settings:
>
> Name="[kCTools.ApplicationPool.Name.Uber]" />
> Description="[kCTools.WebServices.WebSite]">
> Port="[kCTools.WebServices.Port]" Header="[kCTools.WebServices.Header]" />
>
>
> The IIS Web site on which we are creating the virtuals exists.  We are able
> to manually create virtuals.  The local hosts file is set to resolve the
> WebSite name we want to create our virtual on.  We are passing in the above
> MSI properties via a mst file, and have verified they exist and are
> properly
> set.
>
> We are using WiX version 3.0.4805.
>
> Any ideas about what else we may consider looking at?
>
> - Troy
>
> -

Re: [WiX-users] Enforcing x86-only and x64-only installs

[Quinton Tormanen]

For what it's worth, Chris Jackson was able to reproduce this problem,
and confirmed that it is a bug in Windows 7. The fix won't make it into
the RTM but should be in "a Windows Update coming soon".

--Quinton
 
-Original Message-
From: Quinton Tormanen [mailto:quint...@deltacompsys.com] 
Sent: Thursday, June 25, 2009 5:36 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs

Thanks Bob. Once I added the appropriate  elements to my
manifest, it appears to disable the Program Compatibility Assistant
(PCA) on Windows 7. There is still one quirk that I haven't figured out.
That is, if I download my bootstrap exe from the web and save it to my
desktop and run it, it runs in the Windows 7 context and therefore
doesn't invoke the PCA when done. However, if I choose to run it
directly from the web (using Run instead of Save), then it mysteriously
runs in the Windows Vista context and DOES invoke the PCA.

*Sigh* I don't expect you to have an answer for why this happens, but
I'll see if I can get an answer from Chris Jackson.

--Quinton

-Original Message-
From: Bob Arnson [mailto:b...@joyofsetup.com] 
Sent: Thursday, June 25, 2009 8:26 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Enforcing x86-only and x64-only installs

Quinton Tormanen wrote:
> Notice that I distribute my MSI file embedded in a bootstrap built
with
> IEXPRESS.EXE, which runs "MSIEXEC /i rmctools.msi /lv
RMC_Install.log".
> This bootstrap utility also has a manifest embedded using MT.exe that
> sets the requested privilege level to "asInvoker". My understanding
was
> that this turned off Windows' program compatibility engine.
>   

Not in Windows 7. See 
http://blogs.msdn.com/cjacks/archive/2009/06/18/pca-changes-for-windows-
7-how-to-tell-us-you-are-not-an-installer-take-2-because-we-changed-the-
rules-on-you.aspx, 
for example.

-- 
sig://boB
http://joyofsetup.com/




--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] AdminUI vs. InstallUI

[Quinton Tormanen]

My current WiX 2.0 project was built several years ago. At some point, I
copied in all of the UI stuff from the WiX UI library directly into my
project for manual edits that I made, and have since left it stagnant.

 

I've since pulled my project up to use WiX 3.0. However, I am confused
when seeing how I can get back on track with the WiX 3.0 UI. Looking at
my existing project, I see duplicates of every dialog form, one for the
Admin sequence and one for the standard sequence. For example,
UserExitForm and AdminUserExitForm, WelcomeForm and AdminWelcomeForm.

 

I looked back at the UI source from 2.0.5805, and even that one doesn't
duplicate all these forms. Can anyone tell me the history behind these
duplicate forms? I'm guessing that it came from early WiX 2.0 or perhaps
even 1.0.

 

Quinton Tormanen

Software Engineer

Delta Computer Systems, Inc.

http://www.deltamotion.com  

 

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[troy hostetter]

FWIW .. I passed in the IP address of the existing web site .. the new WiX
looks like:


  


Still no go :( .. same error as below.

- Troy

On Wed, Jul 1, 2009 at 2:54 PM, troy hostetter wrote:

> Mike -
>
> Installed version 3.0.5419, built msi, and am now getting this error during
> install:
>
> Action 18:36:40: StartMetabaseTransaction. Starting IIS Metabase
> Transaction
> Action 18:36:40: RollbackMetabaseTransaction. Rolling back IIS Metabase
> Transaction
> Action 18:36:40: CommitMetabaseTransaction. Committing IIS Metabase
> Transaction
> Action 18:36:40: ConfigureIIsExec.
> ConfigureIIsExec:  A matching web object in memory was found, but the web
> object in memory has no associated base
> ConfigureIIsExec:  Error 0x80070002: Failed to find Web base
> ConfigureIIsExec:  Error 0x80070002: Failed to get base of web:
> WS__kCTools.WebServices for VirtualDir
> ConfigureIIsExec:  Error 0x80070002: failed while processing WebVirtualDirs
> Error 26004. Failed while processing WebVirtualDirs.  (-2147024894
> )
> MSI (s) (78!98) [18:37:50:712]: Product: kCTools (64 bit) -- Error 26004.
> Failed while processing WebVirtualDirs.  (-2147024894 )
>
> Action ended 18:37:50: InstallFinalize. Return value 3.
> Action 18:37:50: Rollback. Rolling back action:
> Rollback: ConfigureIIsExec
> Rollback: Committing IIS Metabase Transaction
> Rollback: Rolling back IIS Metabase Transaction
> Rollback: Starting IIS Metabase Transaction
> Rollback: Copying new files
> Rollback: Creating folders
> Rollback: Deleting services
> Rollback: Stopping services
> Rollback: Updating component registration
> Action ended 18:38:07: INSTALL. Return value 3.
>
> Thanks,
> - Troy
>
>
> On Wed, Jul 1, 2009 at 12:51 PM, Mike Carlson (DEV DIV) <
> mica...@microsoft.com> wrote:
>
>> A *lot* has changed in the IIS custom actions since WiX v3.0.4805,
>> including an error that looks very similar to this. First, I would upgrade
>> to the latest WiX 3.0 build (v3.0.5419) and see if you still have a problem
>> after that.
>>
>> Thanks,
>> Mike Carlson
>>
>> -Original Message-
>> From: troy hostetter [mailto:troy.hostet...@gmail.com]
>> Sent: Wednesday, July 01, 2009 9:31 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to
>> create web application
>>
>> We are getting the following error and are not sure why.  We have been
>> successful at creating virtual directories in several other environments
>> (development, integration, etc.), however the environment we are currently
>> deploying to is having issues :(
>>
>> Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase
>> Transaction
>> Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
>> Transaction
>> Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
>> Transaction
>> Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and Values
>> WriteMetabaseChanges:  Error 0x80070057: failed to create web application:
>> /Root/SecurityAutomation
>> Error 26105. Failed to create web application.  (-2147024809
>> /Root/SecurityAutomation  )
>> MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
>> Failed to create web application.  (-2147024809
>> /Root/SecurityAutomation  )
>>
>> WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
>> Action ended 15:56:04: InstallFinalize. Return value 3.
>> Action 15:56:04: Rollback. Rolling back action:
>> Rollback: Installing Metabase Keys and Values
>> Rollback: Committing IIS Metabase Transaction
>> Rollback: Rolling back IIS Metabase Transaction
>> Rollback: Starting IIS Metabase Transaction
>> Rollback: Copying new files
>> Rollback: Creating folders
>> Rollback: Deleting services
>> Rollback: Stopping services
>> Rollback: Updating component registration
>> Action ended 15:56:22: INSTALL. Return value 3.
>>
>> Here is our WiX IIS settings:
>>
>>> Name="[kCTools.ApplicationPool.Name.Uber]" />
>>> Description="[kCTools.WebServices.WebSite]">
>>> Port="[kCTools.WebServices.Port]" Header="[kCTools.WebServices.Header]" />
>>
>>
>> The IIS Web site on which we are creating the virtuals exists.  We are
>> able
>> to manually create virtuals.  The local hosts file is set to resolve the
>> WebSite name we want to create our virtual on.  We are passing in the
>> above
>> MSI properties via a mst file, and have verified they exist and are
>> properly
>> set.
>>
>> We are using WiX version 3.0.4805.
>>
>> Any ideas about what else we may consider looking at?
>>
>> - Troy
>>
>> --
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>>
>>
>> --
>> ___

Re: [WiX-users] Boolean paramaters

[Richard]

Think of "boolean" properties acting the same way that properties act
when you connect them to a checkbox.  The property is empty if the
checkbox is cleared and set to some value when the checkbox is
checked.

If you follow this convention with your own properties then MyProperty
will evaluate to true when MyProperty has some non-empty value and
evaluate to false when it is empty.

To set a property to the empty value use a type 19 CA with the value
"{}".  This is discussed in the Windows Installer documentation.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

  Legalize Adulthood! 

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Patch will not cache baseline or what is so special about interop assembles?

[Tony Juricic]

I have an interop assembly that breaks my patching.

When patch is installed verbose log shows this:

MSI (s) (78:E8) [16:12:06:987]: Baseline: INTEROP.SERVICELIB.DLL not touched in 
this transaction, verification required.
MSI (s) (78:E8) [16:12:06:989]: Baseline: Existing INTEROP.SERVICELIB.DLL 
version 5.30.2.52 does not match any baseline. Will not be cached.

There is no previous info in the log showing that this file is treated any 
differently than the other files that get cached.

The information at Heath Stewart's Blog :
http://blogs.msdn.com/heaths/archive/2006/12/08/source-resolution-during-patch-uninstall.aspx
doesn't seem to apply to explain this case because this assembly is not 
installed in GAC and there are no corresponding MsiAssembly and MsiAssemblyName 
tables.

Since the assembly gets created from the type library, in the beginning I 
thought the problem is simple and due to the resource version which was always 
set to 1.0.0.0, even if the code got changed. I fixed this by running the 
utility that updated file and product version resource after assembly was 
created. That didn't help.

Then I realized that, even if I changed file and product version resource, the 
assembly version was still fixed at 1.0.0.0 in both RTM and QFE builds. Ok, 
that got fixed too with the little utility that invokes ildasm and, after 
editing the manifest version part ilasm. But that didn't help either. MSI 
insists on not caching the file.

So my question is how can I understand what is making MSI treat this assembly 
so differently?

There are no such problems with .NET assemblies that are not interop, but are 
built from C# source code.

If I decide to provide the RTM source MSI, that will fix my current problem 
with uninstalling QFE1 patch and going back to RTM.

But will I be able to apply and remove multiple patches of this assembly? What 
about dropping from QFE2 to QFE1 if MSI doesn't feel like caching anything 
about this assembly?

TradeStation Group, Inc. is a publicly-traded holding company (NASDAQ GS: TRAD) 
of three operating subsidiaries, TradeStation Securities, Inc. (Member NYSE, 
FINRA, SIPC and NFA), TradeStation Technologies, Inc., a trading software and 
subscription company, and TradeStation Europe Limited, a United Kingdom, 
FSA-authorized introducing brokerage firm. None of these companies provides 
trading or investment advice, recommendations or endorsements of any kind. The 
information transmitted is intended only for the person or entity to which it 
is addressed and may contain confidential and/or privileged material. Any 
review, retransmission, dissemination or other use of, or taking of any action 
in reliance upon, this information by persons or entities other than the 
intended recipient is prohibited. If you received this in error, please contact 
the sender and delete the material from any computer.
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[troy hostetter]

Mike -

Installed version 3.0.5419, built msi, and am now getting this error during
install:

Action 18:36:40: StartMetabaseTransaction. Starting IIS Metabase Transaction
Action 18:36:40: RollbackMetabaseTransaction. Rolling back IIS Metabase
Transaction
Action 18:36:40: CommitMetabaseTransaction. Committing IIS Metabase
Transaction
Action 18:36:40: ConfigureIIsExec.
ConfigureIIsExec:  A matching web object in memory was found, but the web
object in memory has no associated base
ConfigureIIsExec:  Error 0x80070002: Failed to find Web base
ConfigureIIsExec:  Error 0x80070002: Failed to get base of web:
WS__kCTools.WebServices for VirtualDir
ConfigureIIsExec:  Error 0x80070002: failed while processing WebVirtualDirs
Error 26004. Failed while processing WebVirtualDirs.  (-2147024894 )
MSI (s) (78!98) [18:37:50:712]: Product: kCTools (64 bit) -- Error 26004.
Failed while processing WebVirtualDirs.  (-2147024894 )

Action ended 18:37:50: InstallFinalize. Return value 3.
Action 18:37:50: Rollback. Rolling back action:
Rollback: ConfigureIIsExec
Rollback: Committing IIS Metabase Transaction
Rollback: Rolling back IIS Metabase Transaction
Rollback: Starting IIS Metabase Transaction
Rollback: Copying new files
Rollback: Creating folders
Rollback: Deleting services
Rollback: Stopping services
Rollback: Updating component registration
Action ended 18:38:07: INSTALL. Return value 3.

Thanks,
- Troy

On Wed, Jul 1, 2009 at 12:51 PM, Mike Carlson (DEV DIV) <
mica...@microsoft.com> wrote:

> A *lot* has changed in the IIS custom actions since WiX v3.0.4805,
> including an error that looks very similar to this. First, I would upgrade
> to the latest WiX 3.0 build (v3.0.5419) and see if you still have a problem
> after that.
>
> Thanks,
> Mike Carlson
>
> -Original Message-
> From: troy hostetter [mailto:troy.hostet...@gmail.com]
> Sent: Wednesday, July 01, 2009 9:31 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to
> create web application
>
> We are getting the following error and are not sure why.  We have been
> successful at creating virtual directories in several other environments
> (development, integration, etc.), however the environment we are currently
> deploying to is having issues :(
>
> Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase
> Transaction
> Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
> Transaction
> Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
> Transaction
> Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and Values
> WriteMetabaseChanges:  Error 0x80070057: failed to create web application:
> /Root/SecurityAutomation
> Error 26105. Failed to create web application.  (-2147024809
> /Root/SecurityAutomation  )
> MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
> Failed to create web application.  (-2147024809
> /Root/SecurityAutomation  )
>
> WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
> Action ended 15:56:04: InstallFinalize. Return value 3.
> Action 15:56:04: Rollback. Rolling back action:
> Rollback: Installing Metabase Keys and Values
> Rollback: Committing IIS Metabase Transaction
> Rollback: Rolling back IIS Metabase Transaction
> Rollback: Starting IIS Metabase Transaction
> Rollback: Copying new files
> Rollback: Creating folders
> Rollback: Deleting services
> Rollback: Stopping services
> Rollback: Updating component registration
> Action ended 15:56:22: INSTALL. Return value 3.
>
> Here is our WiX IIS settings:
>
> Name="[kCTools.ApplicationPool.Name.Uber]" />
> Description="[kCTools.WebServices.WebSite]">
> Port="[kCTools.WebServices.Port]" Header="[kCTools.WebServices.Header]" />
>
>
> The IIS Web site on which we are creating the virtuals exists.  We are able
> to manually create virtuals.  The local hosts file is set to resolve the
> WebSite name we want to create our virtual on.  We are passing in the above
> MSI properties via a mst file, and have verified they exist and are
> properly
> set.
>
> We are using WiX version 3.0.4805.
>
> Any ideas about what else we may consider looking at?
>
> - Troy
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/li

Re: [WiX-users] Boolean paramaters

[Wilson, Phil]

That's correct - they're uncomfortably like some C /C++ types, to use that as 
an approximate analogy.  People trip over this sometimes with the standard 
properties. For example the Installed property isn't set to true or false. It's 
a string which (IIRC) is a date. 

Phil Wilson 

-Original Message-
From: Buddell, James [mailto:james.budd...@dkib.com] 
Sent: Wednesday, July 01, 2009 6:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Boolean paramaters

>From memory so this may not be 100% - Windows Installer evaluates
properties as true if they are set, and false if they are not. i.e.
setting MYFLAG=true on the command line will result in boolean condition
tests on MYFLAG returning true, but so will setting MYFLAG=false, as the
MYFLAG property will be set to the string false.

So you'll need to use string comparison tests, and you'll probably want
to use MYFLAG~="true" which will perform a case-insensitive string
comparison, i.e. true for MYFLAG=True or MYFLAG=true, but not for
MYFLAG=false.

Cheers,
James

-Original Message-
From: Christopher Karper [mailto:christopher.kar...@gmail.com] 
Sent: 01 July 2009 12:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Boolean paramaters

You have a boolean operator right in that very example...   I'm just
winging
this, but try:






On Wed, Jul 1, 2009 at 12:21 AM, sandun css  wrote:

> Hi,
>
> I have some conditions in my msi, like the following,
>
>
> 
>
> 
>
> 
>
> But I need to run these conditions only if a certain parameter is set
to
> 'true'. (i.e. msiexec /i installer.msi MYFLAG=true)
>
> Are there boolean parameters, or do I need to treat 'true' and 'false'
> valuse as strings?
>
> Thanks,
>
> Sandun
>
>

--
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This e-mail is confidential and the information contained in it may be
privileged. It should not be read, copied or used by anyone other than the
intended recipient.  If you have received it in error, please contact the sender
immediately by telephoning (+44 (0)20 7623 8000) or by return email, and delete 
the e-mail and do not disclose its contents to any person.  We believe, but do
not warrant, that this e-mail and any attachments are virus free, but you must
take full responsibility for virus checking. Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is a brand and trading name of the Commerzbank group and 
operates through Commerzbank AG, Dresdner Kleinwort Limited and their affiliated
or associated companies.  Commerzbank AG is a company incorporated in Germany
with limited liability and registered in England (registered no. FC008139, place
of business 60 Gracechurch Street, London EC3V 0HR) and is authorised by 
Bundesanstalt fuer Finanzdienstleistungsaufsicht (BaFin) and authorised and 
subject to limited regulation by the Financial Services Authority (FSA).
Dresdner Kleinwort Limited is a company incorporated in England with limited 
liability (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG) and is authorised and regulated by the FSA.  Details about the extent
of our authorisations and regulation are available on request. 


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[Mike Carlson (DEV DIV)]

A *lot* has changed in the IIS custom actions since WiX v3.0.4805, including an 
error that looks very similar to this. First, I would upgrade to the latest WiX 
3.0 build (v3.0.5419) and see if you still have a problem after that.

Thanks,
Mike Carlson

-Original Message-
From: troy hostetter [mailto:troy.hostet...@gmail.com] 
Sent: Wednesday, July 01, 2009 9:31 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create 
web application

We are getting the following error and are not sure why.  We have been
successful at creating virtual directories in several other environments
(development, integration, etc.), however the environment we are currently
deploying to is having issues :(

Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase Transaction
Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
Transaction
Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
Transaction
Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and Values
WriteMetabaseChanges:  Error 0x80070057: failed to create web application:
/Root/SecurityAutomation
Error 26105. Failed to create web application.  (-2147024809
/Root/SecurityAutomation  )
MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
Failed to create web application.  (-2147024809
/Root/SecurityAutomation  )

WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
Action ended 15:56:04: InstallFinalize. Return value 3.
Action 15:56:04: Rollback. Rolling back action:
Rollback: Installing Metabase Keys and Values
Rollback: Committing IIS Metabase Transaction
Rollback: Rolling back IIS Metabase Transaction
Rollback: Starting IIS Metabase Transaction
Rollback: Copying new files
Rollback: Creating folders
Rollback: Deleting services
Rollback: Stopping services
Rollback: Updating component registration
Action ended 15:56:22: INSTALL. Return value 3.

Here is our WiX IIS settings:






The IIS Web site on which we are creating the virtuals exists.  We are able
to manually create virtuals.  The local hosts file is set to resolve the
WebSite name we want to create our virtual on.  We are passing in the above
MSI properties via a mst file, and have verified they exist and are properly
set.

We are using WiX version 3.0.4805.

Any ideas about what else we may consider looking at?

- Troy
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] WriteMetabaseChanges: Error 0x80070057: failed to create web application

[troy hostetter]

We are getting the following error and are not sure why.  We have been
successful at creating virtual directories in several other environments
(development, integration, etc.), however the environment we are currently
deploying to is having issues :(

Action 14:41:11: StartMetabaseTransaction. Starting IIS Metabase Transaction
Action 14:41:11: RollbackMetabaseTransaction. Rolling back IIS Metabase
Transaction
Action 14:41:11: CommitMetabaseTransaction. Committing IIS Metabase
Transaction
Action 14:41:11: WriteMetabaseChanges. Installing Metabase Keys and Values
WriteMetabaseChanges:  Error 0x80070057: failed to create web application:
/Root/SecurityAutomation
Error 26105. Failed to create web application.  (-2147024809
/Root/SecurityAutomation  )
MSI (s) (CC!30) [15:56:04:702]: Product: kCTools (64 bit) -- Error 26105.
Failed to create web application.  (-2147024809
/Root/SecurityAutomation  )

WriteMetabaseChanges:  Error 0x80070057: failed to create ASP App
Action ended 15:56:04: InstallFinalize. Return value 3.
Action 15:56:04: Rollback. Rolling back action:
Rollback: Installing Metabase Keys and Values
Rollback: Committing IIS Metabase Transaction
Rollback: Rolling back IIS Metabase Transaction
Rollback: Starting IIS Metabase Transaction
Rollback: Copying new files
Rollback: Creating folders
Rollback: Deleting services
Rollback: Stopping services
Rollback: Updating component registration
Action ended 15:56:22: INSTALL. Return value 3.

Here is our WiX IIS settings:






The IIS Web site on which we are creating the virtuals exists.  We are able
to manually create virtuals.  The local hosts file is set to resolve the
WebSite name we want to create our virtual on.  We are passing in the above
MSI properties via a mst file, and have verified they exist and are properly
set.

We are using WiX version 3.0.4805.

Any ideas about what else we may consider looking at?

- Troy
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How does the WiX team generate wix.chm from wix.xsd?

[zett42]

I assume you have some nifty tool to do this?
I like the style of the CHM documentation very much, so I would like to
create my own CHMs from XSDs in this way...

Thanks
-- 
View this message in context: 
http://n2.nabble.com/How-does-the-WiX-team-generate-wix.chm-from-wix.xsd--tp3189821p3189821.html
Sent from the wix-users mailing list archive at Nabble.com.


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to reference a system environment variable?

[Yan Sklyarenko]

Note that if you set permissions to a folder with PermissionEx element,
the permissions are set recursively for all descendants. This means if
your TEMP folder exists and is full of folders/files, the installation
time will increase...

-- Yan

-Original Message-
From: Igor Paniushkin [mailto:ipaniush...@sdl.com] 
Sent: Wednesday, July 01, 2009 6:01 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to reference a system environment variable?

I already figured out, I need to specify Directory element and not
DirectoryRef element, which I tried before.

If somebody interested, there is code to do that:


  


  

  

  http://schemas.microsoft.com/wix/UtilExtension"; />

  

...

Igor


-Original Message-
From: Igor Paniushkin [mailto:ipaniush...@sdl.com] 
Sent: Wednesday, July 01, 2009 16:39
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to reference a system environment variable?

Hi all,
 
I have a question about setting permissions on SYSTEM temp environment
directory:
If I will read information from registry about location of SYSTEM TEMP,
how can I use it to set permissions?
Should I write custom actions to do that? Can I reuse PermissionEx
element from Util extensions?
 
Igor
 
-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com] 
Sent: Thursday, February 05, 2009 03:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to reference a system environment variable?
 
As horrible as it may be, I've been reading system environment values
out of 
SYSTEM\CurrentControlSet\Control\Session Manager\Environment for about 4
years 
now and there haven't 
been any support issues (both XP and Vista).  I don't use this for
setting 
values though.  I use the 
normal Environment WiX element.
 
Rob
 
Yan Sklyarenko wrote:
> He-he, nope, this references the local TEMP as well, I've tried this.
> I've also browsed the forums for this info, and the best approach I've
> found so far is to search the system registry for the key
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and
> the value TEMP underneath. 
> 
> This works for me, but maybe others know about the drawbacks of this
> approach? I would really like to know if there's any.
> 
> Thank you.
> 
> -- Yan
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
> Sent: Wednesday, February 04, 2009 10:29 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to reference a system environment
variable?
> 
> The MSI way to get this would be [%TEMP] (formatted type in Windows
> Installer) so you just need to get that in your WiX source somewhere. 
> 
> Phil Wilson 
> 
> 
> -Original Message-
> From: Yan Sklyarenko [mailto:y...@sitecore.net] 
> Sent: Wednesday, February 04, 2009 8:07 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to reference a system environment variable?
> 
> Hello WiX community,
> 
> That's a really newbie question.
> 
> I need to set permissions to the TEMP folder, the one stated in the
> system TEMP environment variable.
> I was trying this way:
> 
> 
> 
> Guid="{YOURGUID-GOES-HERE-B106-B9D9705E01D7}" Permanent="yes">
>   
>  
>   
>
> 
> 
> But this way it references the user-specific TEMP variable, the one
> under Documents & Settings. 
> 
> Could you please point me to the right direction?
> Thanks.
> 
> -- Yan
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
>

--
> Create and Deplo

[WiX-users] Third-party installation

[MacDiarmid, James D]

All, 

I have a couple third-party installers, such as the SOAP toolkit, I need
to kick off during my installer.  This file does not get installed with
the rest of the application.  How would I go about setting that up?  

Thanks,

Jim


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to reference a system environment variable?

[Igor Paniushkin]

I already figured out, I need to specify Directory element and not
DirectoryRef element, which I tried before.

If somebody interested, there is code to do that:


  


  

  

  http://schemas.microsoft.com/wix/UtilExtension"; />

  

...

Igor


-Original Message-
From: Igor Paniushkin [mailto:ipaniush...@sdl.com] 
Sent: Wednesday, July 01, 2009 16:39
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to reference a system environment variable?

Hi all,
 
I have a question about setting permissions on SYSTEM temp environment
directory:
If I will read information from registry about location of SYSTEM TEMP,
how can I use it to set permissions?
Should I write custom actions to do that? Can I reuse PermissionEx
element from Util extensions?
 
Igor
 
-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com] 
Sent: Thursday, February 05, 2009 03:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to reference a system environment variable?
 
As horrible as it may be, I've been reading system environment values
out of 
SYSTEM\CurrentControlSet\Control\Session Manager\Environment for about 4
years 
now and there haven't 
been any support issues (both XP and Vista).  I don't use this for
setting 
values though.  I use the 
normal Environment WiX element.
 
Rob
 
Yan Sklyarenko wrote:
> He-he, nope, this references the local TEMP as well, I've tried this.
> I've also browsed the forums for this info, and the best approach I've
> found so far is to search the system registry for the key
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and
> the value TEMP underneath. 
> 
> This works for me, but maybe others know about the drawbacks of this
> approach? I would really like to know if there's any.
> 
> Thank you.
> 
> -- Yan
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
> Sent: Wednesday, February 04, 2009 10:29 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to reference a system environment
variable?
> 
> The MSI way to get this would be [%TEMP] (formatted type in Windows
> Installer) so you just need to get that in your WiX source somewhere. 
> 
> Phil Wilson 
> 
> 
> -Original Message-
> From: Yan Sklyarenko [mailto:y...@sitecore.net] 
> Sent: Wednesday, February 04, 2009 8:07 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to reference a system environment variable?
> 
> Hello WiX community,
> 
> That's a really newbie question.
> 
> I need to set permissions to the TEMP folder, the one stated in the
> system TEMP environment variable.
> I was trying this way:
> 
> 
> 
> Guid="{YOURGUID-GOES-HERE-B106-B9D9705E01D7}" Permanent="yes">
>   
>  
>   
>
> 
> 
> But this way it references the user-specific TEMP variable, the one
> under Documents & Settings. 
> 
> Could you please point me to the right direction?
> Thanks.
> 
> -- Yan
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
>

--
> Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
code to
> build responsive, highly engaging applications that combine the power
of local
> resources and data with the reach of the web. Download the Adobe AIR
SDK and
> Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
 
 

--
Create and Deploy Rich Interne

Re: [WiX-users] How to reference a system environment variable?

[Igor Paniushkin]

Hi all,
 
I have a question about setting permissions on SYSTEM temp environment
directory:
If I will read information from registry about location of SYSTEM TEMP,
how can I use it to set permissions?
Should I write custom actions to do that? Can I reuse PermissionEx
element from Util extensions?
 
Igor
 
-Original Message-
From: Rob Hamflett [mailto:r...@snsys.com] 
Sent: Thursday, February 05, 2009 03:01
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to reference a system environment variable?
 
As horrible as it may be, I've been reading system environment values
out of 
SYSTEM\CurrentControlSet\Control\Session Manager\Environment for about 4
years 
now and there haven't 
been any support issues (both XP and Vista).  I don't use this for
setting 
values though.  I use the 
normal Environment WiX element.
 
Rob
 
Yan Sklyarenko wrote:
> He-he, nope, this references the local TEMP as well, I've tried this.
> I've also browsed the forums for this info, and the best approach I've
> found so far is to search the system registry for the key
> HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment, and
> the value TEMP underneath. 
> 
> This works for me, but maybe others know about the drawbacks of this
> approach? I would really like to know if there's any.
> 
> Thank you.
> 
> -- Yan
> 
> -Original Message-
> From: Wilson, Phil [mailto:phil.wil...@wonderware.com] 
> Sent: Wednesday, February 04, 2009 10:29 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] How to reference a system environment
variable?
> 
> The MSI way to get this would be [%TEMP] (formatted type in Windows
> Installer) so you just need to get that in your WiX source somewhere. 
> 
> Phil Wilson 
> 
> 
> -Original Message-
> From: Yan Sklyarenko [mailto:y...@sitecore.net] 
> Sent: Wednesday, February 04, 2009 8:07 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: [WiX-users] How to reference a system environment variable?
> 
> Hello WiX community,
> 
> That's a really newbie question.
> 
> I need to set permissions to the TEMP folder, the one stated in the
> system TEMP environment variable.
> I was trying this way:
> 
> 
> 
> Guid="{YOURGUID-GOES-HERE-B106-B9D9705E01D7}" Permanent="yes">
>   
>  
>   
>
> 
> 
> But this way it references the user-specific TEMP variable, the one
> under Documents & Settings. 
> 
> Could you please point me to the right direction?
> Thanks.
> 
> -- Yan
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> 
>

> --
> Create and Deploy Rich Internet Apps outside the browser with
> Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
> code to
> build responsive, highly engaging applications that combine the power
of
> local
> resources and data with the reach of the web. Download the Adobe AIR
SDK
> and
> Ajax docs to start building applications
> today-http://p.sf.net/sfu/adobe-com
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
>

--
> Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
> software. With Adobe AIR, Ajax developers can use existing skills and
code to
> build responsive, highly engaging applications that combine the power
of local
> resources and data with the reach of the web. Download the Adobe AIR
SDK and
> Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
 
 

--
Create and Deploy Rich Internet Apps outside the browser with
Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and
code to
build responsive, highly engaging applications that combine the power of
local
resources and data with the reach of the web. Download the Adobe AIR SDK
and
Ajax docs to start building applications
today-http://p.sf.net/sfu/adobe-com
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
 
 
-

Re: [WiX-users] Boolean paramaters

[Buddell, James]

>From memory so this may not be 100% - Windows Installer evaluates
properties as true if they are set, and false if they are not. i.e.
setting MYFLAG=true on the command line will result in boolean condition
tests on MYFLAG returning true, but so will setting MYFLAG=false, as the
MYFLAG property will be set to the string false.

So you'll need to use string comparison tests, and you'll probably want
to use MYFLAG~="true" which will perform a case-insensitive string
comparison, i.e. true for MYFLAG=True or MYFLAG=true, but not for
MYFLAG=false.

Cheers,
James

-Original Message-
From: Christopher Karper [mailto:christopher.kar...@gmail.com] 
Sent: 01 July 2009 12:25
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Boolean paramaters

You have a boolean operator right in that very example...   I'm just
winging
this, but try:






On Wed, Jul 1, 2009 at 12:21 AM, sandun css  wrote:

> Hi,
>
> I have some conditions in my msi, like the following,
>
>
> 
>
> 
>
> 
>
> But I need to run these conditions only if a certain parameter is set
to
> 'true'. (i.e. msiexec /i installer.msi MYFLAG=true)
>
> Are there boolean parameters, or do I need to treat 'true' and 'false'
> valuse as strings?
>
> Thanks,
>
> Sandun
>
>

--
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
This e-mail is confidential and the information contained in it may be
privileged. It should not be read, copied or used by anyone other than the
intended recipient.  If you have received it in error, please contact the sender
immediately by telephoning (+44 (0)20 7623 8000) or by return email, and delete 
the e-mail and do not disclose its contents to any person.  We believe, but do
not warrant, that this e-mail and any attachments are virus free, but you must
take full responsibility for virus checking. Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is a brand and trading name of the Commerzbank group and 
operates through Commerzbank AG, Dresdner Kleinwort Limited and their affiliated
or associated companies.  Commerzbank AG is a company incorporated in Germany
with limited liability and registered in England (registered no. FC008139, place
of business 60 Gracechurch Street, London EC3V 0HR) and is authorised by 
Bundesanstalt fuer Finanzdienstleistungsaufsicht (BaFin) and authorised and 
subject to limited regulation by the Financial Services Authority (FSA).
Dresdner Kleinwort Limited is a company incorporated in England with limited 
liability (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG) and is authorised and regulated by the FSA.  Details about the extent
of our authorisations and regulation are available on request. 


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Multiple Instance Transforms Walkthrough, Proposed Simple Addition to WiX to Make Them Easier

[amrish]

I am trying to create an MSI which will install a windows service multiple
times on the same machine with a clientname appended to the end of each
service instance (ServiceNameClientA).  I take the servicename as input from
the user and create the service with that name(e.g clientname).  It will be
created in its own directory named exactly the same. 

So if the clientname is ClientA  then the Directory its installed to is also
the same name.

I use a custom action to change the InstallLocation to
[InstallLocation]\[ClientName]

Is it possible to do this via the Multiple Instace example in your post?  

I see you have to define the each instance in the file.  In my requirement
there could be any number of instances.  I need to be able to install any
number of times and uninstall them either by taking the clientname as input
to uninstall or other method.

Could you advise on this please?


Josh Rowe wrote:
> 
> Okay, I've figured out a lot about multiple instance transforms and the
> sorts of contortions you have to go through to make them work.  I even
> figured out how to make a single MSI drive multiple instance transforms
> without the need for a bootstrapping program, relying on the fact that the
> InstallUISequence executes indepently from the InstallExecuteSequence. 
> But one thing remains in WiX to make this a lot easier: automatic
> GUID-changing of components.  In this message, I discuss how to create a
> multiple instance transform, how to make a single MSI drive multiple
> instance transforms, a common pitfall, and a feature request for WiX.
> 
> I want a user, when they double-click an MSI file, to by default install a
> new instance.  First, obviously, we will need to define some instance
> transforms:
> 
>Value="DontUseThis"
>   Secure="yes"
>   />
> 
> 
>ProductName="Instance 1"
> Id="Instance1"/>
>ProductName="Instance 2"
> Id="Instance2"/>
> 
> 
> So far, so good.  What if the new instance ProductName should be driven by
> user selection items?  No problem:
> 
>Property="ProductName"
>   Value="[[ProductNamePropertyPrefix][MYINSTANCE]]"
>   />
> 
>Value="ProductName_"
>   />
> 
>Value="Multiple Instance Transforms - Default instance"
>   />
> 
>Value="Multiple Instance Transforms - Instance #1"
>   />
> 
>Value="Multiple Instance Transforms - Instance #2"
> 
> 
>  Before="ValidateProductID"/>
> 
> 
> Obviously, use whatever algorithm you want in the SetProductName custom
> action.  You will probably want a different install location, too:
> 
>Name="TestMultipleInstanceTransformUi">
> 
> 
>   
> 
>Property="InstanceDirectory"
>   Value="[INSTALLLOCATION][MYINSTANCE]\"/>
> 
> 
>Before="CostFinalize">
> 
> 
> Okay, looking good.  Now, the user can specify MSINEWINSTANCE=1
> TRANSFORMS=Instance1 on the msiexec command line to install a new
> instance, right?  But that seems a little in-depth for users to have to
> worry about.  For example, how do they know which instance names are
> available?  How can they reliably choose the next available instance id? 
> We can obviously do better.  It turns out that the MSI system works in two
> phases when a UI is presented.  First, the InstallUISequence is executed
> in the user's space.  Second, the InstallExecuteSequence is executed in a
> system process.  The two sequences act completely independently; the
> InstallUISequence's ExecuteAction just passes a set of property names to
> the system msiexec service.  So, we can make our parent process pass in
> the right transform as follows:
> 
>Property="TRANSFORMS"
>   Value="{:[MYINSTANCE];}[TRANSFORMS]"
>   />
> 
>Property="MSINEWINSTANCE"
>   Value="1"/>
> 
> 
>  Before="ExecuteAction">
>  Before="ExecuteAction">
> 
> 
> Now we need a reliable way of setting MYINSTANCE.  That's pretty simple,
> too.  We make our install register each instance id during the install,
> and look for the first not-yet-registered instance:
> 
> 
>  Key="[InstancesKey]\Instance1"
>   Name="ProductCode"
>   Root="HKLM"
>   Type="raw"/>
> 
> 
> 
>  Key="[InstancesKey]\Instance2"
>   Name="ProductCode"
>   Root="HKLM"
>   Type="raw"/>
> 
> 
>Value="Software\Manufacturer\TestMultipleInstance"
>   />
> 
> Now we have information about

Re: [WiX-users] Multiple Instance Transforms Walkthrough, Proposed Simple Addition to WiX to Make Them Easier

[amrish]

I am trying to create an MSI which will install a windows service multiple
times on the same machine with a clientname appended to the end of each
service instance (ServiceNameClientA).  I take the servicename as input from
the user and create the service with that name(e.g clientname).  It will be
created in its own directory named exactly the same. 

So if the clientname is ClientA  then the Directory its installed to is also
the same name.

I use a custom action to change the InstallLocation to
[InstallLocation]\[ClientName]

Is it possible to do this via the Multiple Instace example in your post?  

I see you have to define the each instance in the file.  In my requirement
there could be any number of instances.  I need to be able to install any
number of times and uninstall them either by taking the clientname as input
to uninstall or other method.

Could you advise on this please?


Josh Rowe wrote:
> 
> Okay, I've figured out a lot about multiple instance transforms and the
> sorts of contortions you have to go through to make them work.  I even
> figured out how to make a single MSI drive multiple instance transforms
> without the need for a bootstrapping program, relying on the fact that the
> InstallUISequence executes indepently from the InstallExecuteSequence. 
> But one thing remains in WiX to make this a lot easier: automatic
> GUID-changing of components.  In this message, I discuss how to create a
> multiple instance transform, how to make a single MSI drive multiple
> instance transforms, a common pitfall, and a feature request for WiX.
> 
> I want a user, when they double-click an MSI file, to by default install a
> new instance.  First, obviously, we will need to define some instance
> transforms:
> 
>Value="DontUseThis"
>   Secure="yes"
>   />
> 
> 
>ProductName="Instance 1"
> Id="Instance1"/>
>ProductName="Instance 2"
> Id="Instance2"/>
> 
> 
> So far, so good.  What if the new instance ProductName should be driven by
> user selection items?  No problem:
> 
>Property="ProductName"
>   Value="[[ProductNamePropertyPrefix][MYINSTANCE]]"
>   />
> 
>Value="ProductName_"
>   />
> 
>Value="Multiple Instance Transforms - Default instance"
>   />
> 
>Value="Multiple Instance Transforms - Instance #1"
>   />
> 
>Value="Multiple Instance Transforms - Instance #2"
> 
> 
>  Before="ValidateProductID"/>
> 
> 
> Obviously, use whatever algorithm you want in the SetProductName custom
> action.  You will probably want a different install location, too:
> 
>Name="TestMultipleInstanceTransformUi">
> 
> 
>   
> 
>Property="InstanceDirectory"
>   Value="[INSTALLLOCATION][MYINSTANCE]\"/>
> 
> 
>Before="CostFinalize">
> 
> 
> Okay, looking good.  Now, the user can specify MSINEWINSTANCE=1
> TRANSFORMS=Instance1 on the msiexec command line to install a new
> instance, right?  But that seems a little in-depth for users to have to
> worry about.  For example, how do they know which instance names are
> available?  How can they reliably choose the next available instance id? 
> We can obviously do better.  It turns out that the MSI system works in two
> phases when a UI is presented.  First, the InstallUISequence is executed
> in the user's space.  Second, the InstallExecuteSequence is executed in a
> system process.  The two sequences act completely independently; the
> InstallUISequence's ExecuteAction just passes a set of property names to
> the system msiexec service.  So, we can make our parent process pass in
> the right transform as follows:
> 
>Property="TRANSFORMS"
>   Value="{:[MYINSTANCE];}[TRANSFORMS]"
>   />
> 
>Property="MSINEWINSTANCE"
>   Value="1"/>
> 
> 
>  Before="ExecuteAction">
>  Before="ExecuteAction">
> 
> 
> Now we need a reliable way of setting MYINSTANCE.  That's pretty simple,
> too.  We make our install register each instance id during the install,
> and look for the first not-yet-registered instance:
> 
> 
>  Key="[InstancesKey]\Instance1"
>   Name="ProductCode"
>   Root="HKLM"
>   Type="raw"/>
> 
> 
> 
>  Key="[InstancesKey]\Instance2"
>   Name="ProductCode"
>   Root="HKLM"
>   Type="raw"/>
> 
> 
>Value="Software\Manufacturer\TestMultipleInstance"
>   />
> 
> Now we have information about

Re: [WiX-users] Boolean paramaters

[Christopher Karper]

You have a boolean operator right in that very example...   I'm just winging
this, but try:






On Wed, Jul 1, 2009 at 12:21 AM, sandun css  wrote:

> Hi,
>
> I have some conditions in my msi, like the following,
>
>
> 
>
> 
>
> 
>
> But I need to run these conditions only if a certain parameter is set to
> 'true'. (i.e. msiexec /i installer.msi MYFLAG=true)
>
> Are there boolean parameters, or do I need to treat 'true' and 'false'
> valuse as strings?
>
> Thanks,
>
> Sandun
>
> --
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] DTF - "Cursor in invalid state" error when deleting records from a view

[Buddell, James]

Hi,

I am using C# in VS2008 to access an MSI and delete some rows. I am
using the latest weekly WIX build, 3.5.0626. When I try to use the
View.Delete method I receive the InstallerException "Cursor in invalid
state". I've simplified the code and replicated the error with the
sample below:

string strMsiPath = @"C:\Test.msi";
using (Database objDatabase = new Database(strMsiPath,
DatabaseOpenMode.Transact))
{
using (View vwTable = objDatabase.OpenView("SELECT *
FROM Class"))
{
vwTable.Execute();
Record rcdTable = vwTable.Fetch();
while (rcdTable != null)
{
vwTable.Delete(rcdTable);
rcdTable = vwTable.Fetch();
}
}
}
System.Windows.Forms.MessageBox.Show("Done");

I am pretty sure that I am following all of the pointers in the
documentation ("The Record must have been obtained by calling Fetch().
Fails if the row has been deleted. Works only with read-write records.
This method cannot be used with a View containing joins."). There is
also a reference to See Modify(ViewModifyMode, Record) for more remarks.
I've tried replacing vwTable.Delete(rcdTable) with
vwTable.Modify(ViewModifyMode.Delete, rcdTable) and get the same error,
though that's to be expected as View.Delete(Record) just falls through
to View.Modify(Delete,Record).

The equivalent code in VBS works fine:

Const msiOpenDatabaseModeTransact = 1
Const msiViewModifyDelete = 6
Set objWI = Wscript.CreateObject("WindowsInstaller.Installer")
Set objDB = objWI.OpenDatabase("C:\Test.msi",
msiOpenDatabaseModeTransact)
Set objView = objDB.OpenView("SELECT * FROM Class")
objView.Execute
Set objRecord = objView.Fetch
While Not objRecord Is Nothing
objView.Modify msiViewModifyDelete, objRecord
Set objRecord = objView.Fetch
Wend
objView.Close
Set objWI = Nothing
MsgBox "Done"

Any clue as to what I am doing wrong?

Many thanks,
James
This e-mail is confidential and the information contained in it may be
privileged. It should not be read, copied or used by anyone other than the
intended recipient.  If you have received it in error, please contact the sender
immediately by telephoning (+44 (0)20 7623 8000) or by return email, and delete 
the e-mail and do not disclose its contents to any person.  We believe, but do
not warrant, that this e-mail and any attachments are virus free, but you must
take full responsibility for virus checking. Please refer to 
http://www.dresdnerkleinwort.com/disc/email/ and read our e-mail disclaimer 
statement and monitoring policy.

Dresdner Kleinwort is a brand and trading name of the Commerzbank group and 
operates through Commerzbank AG, Dresdner Kleinwort Limited and their affiliated
or associated companies.  Commerzbank AG is a company incorporated in Germany
with limited liability and registered in England (registered no. FC008139, place
of business 60 Gracechurch Street, London EC3V 0HR) and is authorised by 
Bundesanstalt fuer Finanzdienstleistungsaufsicht (BaFin) and authorised and 
subject to limited regulation by the Financial Services Authority (FSA).
Dresdner Kleinwort Limited is a company incorporated in England with limited 
liability (registered no. 551334, registered office 30 Gresham Street, London 
EC2V 7PG) and is authorised and regulated by the FSA.  Details about the extent
of our authorisations and regulation are available on request. 


--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] wix3_x64.msi

[Sebastian Brand (Instyler Software)]

I got it working. I compiled winterop.dll as 64-bit.


Back on Route 64...
Sebastian Brand

Instyler Setup - Creating WiX-based MSI installations, elegantly.
http://www.instyler.com



-Original Message-
From: Sebastian Brand (Instyler Software) [mailto:wix+us...@instyler.com] 
Sent: Wednesday, July 01, 2009 8:22 AM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] wix3_x64.msi

Thanks for all the replies.
My problem is that our tool is calling the WiX compiler, binder and linker 
directly, without light.exe - light.exe is 32-bit only, probably because 
winterop.dll (interop to Windows CabBuilder) is 32-bit only. Now calling the 
WiX binder directly from our 64-bit tool, invoking anything from winterop fails 
(BadImageFormatException).

Any chance in getting a 64-bit release of winterop.dll?


Best regards,
Sebastian Brand

Instyler Setup - Creating WiX-based MSI installations, elegantly.
http://www.instyler.com



-Original Message-
From: Mike Carlson (DEV DIV) [mailto:mica...@microsoft.com] 
Sent: Tuesday, June 30, 2009 7:21 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] wix3_x64.msi

The x64 CA's also come with the x86 version of WiX. I believe the only 
difference between the x86 and x64 releases of WiX is the MSBuild difference 
mentioned below.

Also, to be clear, while some of the custom actions are also built as 64-bit 
DLLs, others are not, and support 64-bit scenarios through the Wow64 API.

Thanks,
Mike Carlson

-Original Message-
From: John Robbins [mailto:j...@wintellect.com] 
Sent: Tuesday, June 30, 2009 10:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] wix3_x64.msi

Doh! Yes, the CA's have x64 versions too. The x64 version will also get the 
dutil_*_x64.lib files as well.

>-Original Message-
>From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
>Sent: Tuesday, June 30, 2009 9:44 AM
>To: General discussion for Windows Installer XML toolset.
>Subject: Re: [WiX-users] wix3_x64.msi
>
>I was under the impression that the C++ custom actions are also built as
>64-bit DLLs. Is that not the case?
>
>Edwin G. Castro
>Software Developer - Staff
>Electronic Banking Services
>Fiserv
>Office: 503-746-0643
>Fax: 503-617-0291
>www.fiserv.com
>Please consider the environment before printing this e-mail
>
>
>> -Original Message-
>> From: John Robbins [mailto:j...@wintellect.com]
>> Sent: Tuesday, June 30, 2009 9:28 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] wix3_x64.msi
>>
>> The x64 installer also installs the MSBuild target files into
>> C:\Program Files\MSBuild\Microsoft\WiX so if you do a command line
>> build using MSBUILD.EXE from the Framework64 directory it works.
>>
>> >-Original Message-
>> >From: Sebastian Brand (Instyler Software)
>> >[mailto:wix+us...@instyler.com]
>> >Sent: Tuesday, June 30, 2009 4:34 AM
>> >To: wix-users@lists.sourceforge.net
>> >Subject: [WiX-users] wix3_x64.msi
>> >
>> >Hello,
>> >
>> >
>> >
>> >I was just installing the x64 version of WiX and noticed the files
>are
>> >identical as in x86. All binaries are "Any Cpu" assemblies. Can
>> someone
>> >tell
>> >me what (besides the installer) are the differences in the x64
>release
>> >of
>> >WiX?
>> >
>> >
>> >
>> >
>> >
>> >Best regards,
>> >
>> >Sebastian Brand
>> >
>> >
>> >
>> >Instyler Setup - Creating WiX-based MSI installations, elegantly.
>> >
>> >  http://www.instyler.com
>> >
>> >
>> >
>> >
>> >
>> >-
>-
>> --
>> >--
>> >___
>> >WiX-users mailing list
>> >WiX-users@lists.sourceforge.net
>> >https://lists.sourceforge.net/lists/listinfo/wix-users
>>
>> --
>-
>> ---
>> ___
>> WiX-users mailing list
>> WiX-users@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>--
>___
>WiX-users mailing list
>WiX-users@lists.sourceforge.net
>https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
___
WiX-users mailing list
W