Re: [WiX-users] Network Install: How To Control What User Sees?

[Bob Arnson]

Andrew Kendall wrote:
> Ok, if an individual user wants to install our product on their computer, no 
> problem. What I don't understand is how to set things up for a network 
> install, whereby an administrator specifies a bunch of install options, which 
> are then propagated to each client install.
>   

The MSI solution is to use ADDLOCAL to control which features get 
installed (including ALL). You can also use the INSTALLLEVEL property to 
use the feature level. You can then pass PROPERTY=value pairs to control 
things like installation directory and server names.

> Regardin Bob's mention of the ADDLOCAL property, how does an adminstrator 
> 'supply properties like ADDLOCAL to install particular (or all) features of a 
> product'?
>   

That's a GPO thing. I can't offer any advice about it.

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



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixDIFxAppExtension and MergeModules

[Bob Arnson]

Moradi, Ari wrote:
> I understand your point.  However, I think that the DIFx merge module 
> dependency is a good way to go, because right now, it is not possible to 
> build two different merge modules using DIFxAppExtension and then include 
> them both in the same MSI.  Any good solution to that problem would make me 
> happy :)  

Understood, but given the multiple steps (mixing and matching merge 
modules with driver installs) and a workaround, I'm not sure taking the 
merge module dependency would be my first choice.

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



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Unresolved reference to symbol 'CustomAction:SchedSecureObjects'

[Bob Arnson]

Alan Sinclair wrote:
> c:/PROGRA~1/WI577F~1/bin/light.exe  -nologo -w0 -wx -pedantic:legendary
> -out Mypkg.msi MyEdge.wixobj MyCommon.wixobj MyCore.wixobj
> MyEdgeService.wixobj MyCA.wixobj MyEdgeGui.wixobj Release/vc_crt.wixobj
> "c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc
> "c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl"
> C:\cygwin\home\alan\perforce\trunk\windows_package\wix\MyEdge.wxs :
> error LGHT0112 : Unresolved reference to symbol
> 'CustomAction:SchedSecureObjects' in section
> 'Product:----'.
>
>   

 From WiX.chm for the Extended attribute:

Specifying 'yes' for this attribute will require you to link your MSI 
with the wixca.wixlib.

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



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Unresolved reference to symbol 'CustomAction:SchedSecureObjects'

[Alan Sinclair]

I'm trying to add code to set directory permissions, plagiarizing
working code from another file. Adding the new code gets an error from
light and it's got me baffled.
 

  

  
  


  


  

 
The top four lines are OK. Adding the TheDestFolder Component (plus an
appropriate ComponentRef) triggers this:
 
c:/PROGRA~1/WI577F~1/bin/light.exe  -nologo -w0 -wx -pedantic:legendary
-out Mypkg.msi MyEdge.wixobj MyCommon.wixobj MyCore.wixobj
MyEdgeService.wixobj MyCA.wixobj MyEdgeGui.wixobj Release/vc_crt.wixobj
"c:\PROGRA~1\WI577F~1\bin\wixui.wixlib" -loc
"c:\PROGRA~1\WI577F~1\bin\WixUI_en-us.wxl"
C:\cygwin\home\alan\perforce\trunk\windows_package\wix\MyEdge.wxs :
error LGHT0112 : Unresolved reference to symbol
'CustomAction:SchedSecureObjects' in section
'Product:----'.

Can anyone give me any clues please?
 
 
 
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Different behavior on uninstall

[Richard]

In article <[EMAIL PROTECTED]>,
"Rolando Valdivia" <[EMAIL PROTECTED]>  writes:

> Sorry, I forgot to mention that I made a log for the kit, and the error Says
> "InstallFinalize return value 3", there is no more information.

Look earlier in the log.  InstallFinalize returns 3 when an action in
the install transaction fails.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Different behavior on uninstall

[Rolando Valdivia]

Sorry, I forgot to mention that I made a log for the kit, and the error Says
"InstallFinalize return value 3", there is no more information.

Thats why I ask.

Thanks,
Rolando

2008/12/10 Wilson, Phil <[EMAIL PROTECTED]>

> The standard answer for this type of issue is to enable MSI logging, and
> look at the MSIxxx.log file in the temp folder. A .reg file wih this will
> turn it on
>
> REGEDIT4
>
> [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
> "Logging"="voicewarmupx"
>
> Phil Wilson
>
>
> -Original Message-
> From: Rolando Valdivia [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 11:18 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Different behavior on uninstall
>
> Hi, I have a weird behaviour uninstalling my kit. When I try to uninstall
> from Add/Remove programs or right click the msi and uninstall, the
> installer
> starts the installation, but before finish, it rolls back.
>
> When I double click the msi and choose the option remove, everything finish
> without problem.
>
> Any Ideas?
>
> Thanks,
> Rolando
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
>
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Different behavior on uninstall

[Wilson, Phil]

The standard answer for this type of issue is to enable MSI logging, and look 
at the MSIxxx.log file in the temp folder. A .reg file wih this will turn it on

REGEDIT4

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Installer]
"Logging"="voicewarmupx"

Phil Wilson 


-Original Message-
From: Rolando Valdivia [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2008 11:18 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Different behavior on uninstall

Hi, I have a weird behaviour uninstalling my kit. When I try to uninstall
from Add/Remove programs or right click the msi and uninstall, the installer
starts the installation, but before finish, it rolls back.

When I double click the msi and choose the option remove, everything finish
without problem.

Any Ideas?

Thanks,
Rolando
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] difference between lit and light

[Christopher Painter]

How do you see this fitting into the whole MSI 4.5 / micropackage strategy? 

It seems somewhat outdated to try to share component/resource data ( be it by 
nested install, merge module or by wixlib ).

--- On Wed, 12/10/08, Rob Mensching <[EMAIL PROTECTED]> wrote:

> From: Rob Mensching <[EMAIL PROTECTED]>
> Subject: Re: [WiX-users] difference between lit and light
> To: "General discussion for Windows Installer XML toolset." 
> 
> Date: Wednesday, December 10, 2008, 1:19 PM
> No and if they followed my recommendation they might never
> do so because they have to share with people that do not use
> WiX v3.  If they chose to ship .wixlibs, they'd still
> have to ship Merge Modules for everyone else.
> 
> -Original Message-
> From: Jon Seanor [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 11:07
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] difference between lit and light
> 
> Hi Rob,
> 
> In the closing paragraph you wrote,
> 
> "These days I always recommend that if you are sharing
> setup logic and
> files with people also using WiX v3, skip Merge Modules and
> just use
> binary .wixlibs."
> 
> Are there wixlibs available for the Microsoft
> redistributables  - e.g.
> vc runtimes, msxml, etc?
> If yes, where?
> If no, when?
> 
> Thanks
> 
> Jon
> 
> 
> Rob Mensching wrote:
> >
> http://robmensching.com/blog/archive/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them.aspx
> - has more information about .wixlibs.
> >
> > -Original Message-
> > From: Dale Stewart
> [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2008 06:55
> > To: 'General discussion for Windows Installer XML
> toolset.'
> > Subject: Re: [WiX-users] difference between lit and
> light
> >
> > See the diagram in the WiX help file (About
> WiX->Tools and Concepts).  Lit
> > creates a library that can be consumed by light.  You
> don't have to use
> > "lit", but if you want to package multiple
> "wxs" files into a reusable
> > library, that is what you would use, as I understand
> it.
> >
> > -Original Message-
> > From: Sean Farrow
> [mailto:[EMAIL PROTECTED]
> > Sent: Wednesday, December 10, 2008 8:30 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] difference between lit and light
> >
> > Hi:
> > can someone please explain the difference between
> lit.exe and light.exe,
> > are both required?
> > Cheered
> > Sean.
> >
> 
> > --
> > SF.Net email is Sponsored by MIX09, March 18-20, 2009
> in Las Vegas, Nevada.
> > The future of the web can't happen without you. 
> Join us at MIX09 to help
> > pave the way to the Next Web now. Learn more and
> register at
> >
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> --
> > SF.Net email is Sponsored by MIX09, March 18-20, 2009
> in Las Vegas, Nevada.
> > The future of the web can't happen without you. 
> Join us at MIX09 to help
> > pave the way to the Next Web now. Learn more and
> register at
> >
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> --
> > SF.Net email is Sponsored by MIX09, March 18-20, 2009
> in Las Vegas, Nevada.
> > The future of the web can't happen without you. 
> Join us at MIX09 to help
> > pave the way to the Next Web now. Learn more and
> register at
> >
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> >
> >
> >
> >
> 
> 
> *** This email and any attachments thereto may contain
> private, confidential, and privileged material for the sole
> use of the intended recipient.  Any review, copying, or
> distribution of this email (or any attachments thereto) by
> others is strictly prohibited.  If you are not the intended
> recipient, please contact the sender immediately and
> permanently delete the original and any copies of this email
> and any attachments thereto. ***
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in
> Las Vegas, Nevada.
> The future of the web can't happen without you.  Join
> us at MIX09 to help
> pave the way to the Next Web now. Learn more and register
> at
> http://ad.doubleclick.net/clk;208669438;13503038

Re: [WiX-users] difference between lit and light

[Rob Mensching]

No and if they followed my recommendation they might never do so because they 
have to share with people that do not use WiX v3.  If they chose to ship 
.wixlibs, they'd still have to ship Merge Modules for everyone else.

-Original Message-
From: Jon Seanor [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 11:07
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] difference between lit and light

Hi Rob,

In the closing paragraph you wrote,

"These days I always recommend that if you are sharing setup logic and
files with people also using WiX v3, skip Merge Modules and just use
binary .wixlibs."

Are there wixlibs available for the Microsoft redistributables  - e.g.
vc runtimes, msxml, etc?
If yes, where?
If no, when?

Thanks

Jon


Rob Mensching wrote:
> http://robmensching.com/blog/archive/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them.aspx
>  - has more information about .wixlibs.
>
> -Original Message-
> From: Dale Stewart [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 06:55
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] difference between lit and light
>
> See the diagram in the WiX help file (About WiX->Tools and Concepts).  Lit
> creates a library that can be consumed by light.  You don't have to use
> "lit", but if you want to package multiple "wxs" files into a reusable
> library, that is what you would use, as I understand it.
>
> -Original Message-
> From: Sean Farrow [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 8:30 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] difference between lit and light
>
> Hi:
> can someone please explain the difference between lit.exe and light.exe,
> are both required?
> Cheered
> Sean.
> 
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>


*** This email and any attachments thereto may contain private, confidential, 
and privileged material for the sole use of the intended recipient.  Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited.  If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto. ***
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Different behavior on uninstall

[Rolando Valdivia]

Hi, I have a weird behaviour uninstalling my kit. When I try to uninstall
from Add/Remove programs or right click the msi and uninstall, the installer
starts the installation, but before finish, it rolls back.

When I double click the msi and choose the option remove, everything finish
without problem.

Any Ideas?

Thanks,
Rolando
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] difference between lit and light

[Jon Seanor]

Hi Rob,

In the closing paragraph you wrote,

"These days I always recommend that if you are sharing setup logic and 
files with people also using WiX v3, skip Merge Modules and just use 
binary .wixlibs."

Are there wixlibs available for the Microsoft redistributables  - e.g. 
vc runtimes, msxml, etc?
If yes, where?
If no, when?

Thanks

Jon


Rob Mensching wrote:
> http://robmensching.com/blog/archive/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them.aspx
>  - has more information about .wixlibs.
>
> -Original Message-
> From: Dale Stewart [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 06:55
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] difference between lit and light
>
> See the diagram in the WiX help file (About WiX->Tools and Concepts).  Lit
> creates a library that can be consumed by light.  You don't have to use
> "lit", but if you want to package multiple "wxs" files into a reusable
> library, that is what you would use, as I understand it.
>
> -Original Message-
> From: Sean Farrow [mailto:[EMAIL PROTECTED]
> Sent: Wednesday, December 10, 2008 8:30 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] difference between lit and light
>
> Hi:
> can someone please explain the difference between lit.exe and light.exe,
> are both required?
> Cheered
> Sean.
> 
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
> --
> SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
> The future of the web can't happen without you.  Join us at MIX09 to help
> pave the way to the Next Web now. Learn more and register at
> http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
>   


*** This email and any attachments thereto may contain private, confidential, 
and privileged material for the sole use of the intended recipient.  Any 
review, copying, or distribution of this email (or any attachments thereto) by 
others is strictly prohibited.  If you are not the intended recipient, please 
contact the sender immediately and permanently delete the original and any 
copies of this email and any attachments thereto. ***
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Very slow performance running SQL Scripts

[Rob Mensching]

I'm wondering if we've just crossed some unspoken threshold in the Windows 
Installer.  That or we have some N^2 (or worse) algorithm shredding the SQL 
script and we don't feel it until 100K.  Based on all of the bugs in the SQL 
Script processing and a few of the feature requests, I think we have a 
candidate for re-writing the CustomAction in WiX v4.  I think IIS CustomActions 
will need a similar re-write.  Both of those CustomActions were written before 
I had my newer tricks/understanding of CustomActions.

Just so there are no surprises, I don't think we're going to make any changes 
in WiX v3 here.  SQL CAs seems pretty stable (now) and touching them seems to 
only bring trouble.  We'll avoid change until we get the license to break 
things again (aka: WiX v4).

-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 10:36
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

Actually if I don't run the 100k one, the package runs just fine. I cannot test 
the 100k alone since it needs the whole sequence to be installed before.

Currently I keep investigating this out of "curiosity" since due to some 
requirements I had to move to Neil's approach using sqlcmd directly (replaces, 
logging, timeout, etc). - By the way, I found out that the SQL client is a 
standalone msi which does not need the whole SQL "monster".

If there is anything that you can suggest to try to single out the performance 
degradation, just let me know, I will be glad to try it here, I have plenty of 
VMs with SQL running on them 8^)




-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 7:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

And is it just the last one (100k) that is slow?  Or is the 60k slow as well?  
I hope the 2K are okay.  



-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 22:30
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

6 scripts, 4 of them around 2k rows, 1 60k rows, and the last one ...100k rows!

We don't create the scripts manually, we load the databases with data, and then 
use Red Gate to generate the SQL scripts.



-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 1:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

How much text (without comments) are in these SQL Scripts again?

-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 06:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

I have done a little research, and while I cannot reach any conclusion, at
least this may help to find a lead:

1. Running the scripts using sqlcmd on custom actions (using Neils' code -
thanks Neil) gives that the scripts run in less than 10mins (I am running
half of the original scripts). This is the partial log:
Action start 15:17:09: INSTALL.
Action start 15:17:11: CreateDatabase.
Action ended 15:17:11: CreateDatabase. Return value 1.
MSI (s) (24:C0) [15:19:59:731]: Executing op:
ActionStart(Name=VCDRData__22a_dbmVCDRData_Data.sql,,)
MSI (s) (24:C0) [15:27:35:370]: Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\Installer\2528232f.msi,ProductCode={D31FEBAF-1B14-45C8-800E-6F80E658FF94},CabinetStreams=CAB001.cab,,)
Action ended 15:27:35: InstallFinalize.

2. Running the same scripts using SqlScripts take around 30 mins (using all
the scripts the time increase exponentially)
Action start 16:24:20: INSTALL.
Action start 16:24:24: CreateDatabase.
MSI (s) (48!5C) [16:41:00:894]: PROPERTY CHANGE: Adding ExecuteSqlStrings
property. Its value is (...) (very log text)
Action ended 16:24:24: CreateDatabase. Return value 1.
MSI (s) (48!5C) [16:41:00:972]: Doing action: ExecuteSqlStrings
MSI (s) (48:94) [16:41:24:916]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI4D5.tmp, Entrypoint: ExecuteSqlStrings
and still running
The database creation process is common for both setups. Therefore, the
script handling is my suspect. It seems to be that the loading of the sql
scripts into ExecuteSqlStrings (see MSI (s) (48!5C) [16:41:00:894]: PROPERTY
CHANGE) is what is taking so long.

Hope this helps,

Eitan



On Mon, Dec 8, 2008 at 9:02 PM, Rob Mensching
<[EMAIL PROTECTED]>wrote:

> Sounds like it might be a performance problem in the SQL CustomActions.
>  Can you look in a verbose log file and see what actions are taking the
> longest?  Breakdown of details will help us target the things that are
> actually slow.
>
> -Original Message-
> Fro

Re: [WiX-users] Very slow performance running SQL Scripts

[Eitan Behar]

Actually if I don't run the 100k one, the package runs just fine. I cannot test 
the 100k alone since it needs the whole sequence to be installed before. 

Currently I keep investigating this out of "curiosity" since due to some 
requirements I had to move to Neil's approach using sqlcmd directly (replaces, 
logging, timeout, etc). - By the way, I found out that the SQL client is a 
standalone msi which does not need the whole SQL "monster".

If there is anything that you can suggest to try to single out the performance 
degradation, just let me know, I will be glad to try it here, I have plenty of 
VMs with SQL running on them 8^)




-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2008 7:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

And is it just the last one (100k) that is slow?  Or is the 60k slow as well?  
I hope the 2K are okay.  



-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 22:30
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

6 scripts, 4 of them around 2k rows, 1 60k rows, and the last one ...100k rows!

We don't create the scripts manually, we load the databases with data, and then 
use Red Gate to generate the SQL scripts.



-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 1:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

How much text (without comments) are in these SQL Scripts again?

-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 06:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

I have done a little research, and while I cannot reach any conclusion, at
least this may help to find a lead:

1. Running the scripts using sqlcmd on custom actions (using Neils' code -
thanks Neil) gives that the scripts run in less than 10mins (I am running
half of the original scripts). This is the partial log:
Action start 15:17:09: INSTALL.
Action start 15:17:11: CreateDatabase.
Action ended 15:17:11: CreateDatabase. Return value 1.
MSI (s) (24:C0) [15:19:59:731]: Executing op:
ActionStart(Name=VCDRData__22a_dbmVCDRData_Data.sql,,)
MSI (s) (24:C0) [15:27:35:370]: Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\Installer\2528232f.msi,ProductCode={D31FEBAF-1B14-45C8-800E-6F80E658FF94},CabinetStreams=CAB001.cab,,)
Action ended 15:27:35: InstallFinalize.

2. Running the same scripts using SqlScripts take around 30 mins (using all
the scripts the time increase exponentially)
Action start 16:24:20: INSTALL.
Action start 16:24:24: CreateDatabase.
MSI (s) (48!5C) [16:41:00:894]: PROPERTY CHANGE: Adding ExecuteSqlStrings
property. Its value is (...) (very log text)
Action ended 16:24:24: CreateDatabase. Return value 1.
MSI (s) (48!5C) [16:41:00:972]: Doing action: ExecuteSqlStrings
MSI (s) (48:94) [16:41:24:916]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI4D5.tmp, Entrypoint: ExecuteSqlStrings
and still running
The database creation process is common for both setups. Therefore, the
script handling is my suspect. It seems to be that the loading of the sql
scripts into ExecuteSqlStrings (see MSI (s) (48!5C) [16:41:00:894]: PROPERTY
CHANGE) is what is taking so long.

Hope this helps,

Eitan



On Mon, Dec 8, 2008 at 9:02 PM, Rob Mensching
<[EMAIL PROTECTED]>wrote:

> Sounds like it might be a performance problem in the SQL CustomActions.
>  Can you look in a verbose log file and see what actions are taking the
> longest?  Breakdown of details will help us target the things that are
> actually slow.
>
> -Original Message-
> From: Eitan Behar [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 07, 2008 12:21
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Very slow performance running SQL Scripts
>
> I haven't tried that, I will check tomorrow morning, but I think that they
> will run also fast. I tried the same scripts on Install Shield 12 and they
> take around 10 mins to run.
>
>
>
> -Original Message-
> From: Joe Osman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 07, 2008 10:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Very slow performance running SQL Scripts
>
> Hi Eitan,
> How much does it take for your script to run if you use sqlcmd from the
> command window?
>
> Eitan Behar wrote:
> > Hi,
> >
> > I am having a serious performance problem with SQL Scripts, and would
> > appreciate some help troubleshooting it.
> >
> > This is the scenario: Use WIX to create the database, use script (within
> the
> > component creating 

Re: [WiX-users] WixDIFxAppExtension and MergeModules

[Rob Mensching]

Yeah, .wixlibs have more features in them that make sharing compiled code much 
better than Merge Modules.  You picked up on my hint.  

-Original Message-
From: Moradi, Ari [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 16:11
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

...  but that's one of the issues that I'm dealing with -- I can't guarantee 
everyone is using WiX :)

And I kindof think that if WiX is building a merge module, it wouldn't be 
unreasonable to assume that whoever gets that merge module won't be using WiX 
(or at least might not).  Since if you could guarantee that everyone's using 
WiX, y'all seem to recommend wixlibs instead of merge modules ;)

-Ari


-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 5:15 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

For redisting to other... probably.  Unless everyone is using the WiX toolset.  


-Original Message-
From: Moradi, Ari [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 15:05
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

There actually are differences in the rows, since the binary table entries that 
get added to the merge module get the merge module ID appended to them.

As a test, I manually modified the Binary table entries and removed the merge 
module ID, so that those rows are completely identical between the two merge 
modules.  Then I tried to merge both again.  This time, I didn't see the binary 
table errors (so your suspicion that identical rows are ignored is correct).  
So, changing those entries so that they don't get modularized seems like it 
would help (a little).  However, I still see the errors when it tries to merge 
the ModuleInstallExecuteSequence tables of the two merge modules.  The rows are 
completely identical, but it doesn't like the same action coming from different 
merge modules.  So the second merge fails with the following log lines:


  Merging Sequence Table: ModuleInstallExecuteSequence into Database Table: 
InstallExecuteSequence
  Base Action InstallFiles in InstallExecuteSequence table already exists in 
MSI. Using MSI action.
  Base Action InstallFinalize in InstallExecuteSequence table already exists in 
MSI. Using MSI action.
  Base Action RemoveFiles in InstallExecuteSequence table already exists in 
MSI. Using MSI action.
  Placing action MsiProcessDrivers after InstallFiles
  Placing action MsiCleanupOnSuccess after InstallFinalize
  >> Error: Failed to merge Action: MsiProcessDrivers into Table: 
InstallExecuteSequence
  >> Error: Failed to merge Action: MsiCleanupOnSuccess into Table: 
InstallExecuteSequence

  ...

  >> Error: Merge conflict in Database Table: `InstallExecuteSequence`  - 
Action: `MsiProcessDrivers`
  >> Error: Merge conflict in Database Table: `InstallExecuteSequence`  - 
Action: `MsiCleanupOnSuccess`
  Total merge conflicts: 2


I still think that the solution of creating a dependency on the DIFxApp merge 
module instead of including the DIFxApp wixlib in the merge module is a better 
solution...  What do you think?

-Ari



-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Monday, December 01, 2008 5:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

Hmm, that really surprises me.  I thought that mergemod.dll was smarter than 
that.  There are no differences on those rows where the merge conflicts happen? 
 Hmm.

-Original Message-
From: Moradi, Ari [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 06, 2008 11:59
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

Mergemod.dll doesn't like trying to merge rows with identical primary keys 
(even if they are really supposed to be the same thing.  Here's some log output 
since you asked for it :)

I created my two merge modules, then I ran:
Orca.exe -f ProductFeature -m DriverMergeModule1.msm -l merge.log -c Test.msi

I checked Test.msi and merge.log and sure enough, DriverMergeModule1.msm was 
successfully merged.

Then I deleted merge.log and ran:
Orca.exe -f ProductFeature -m DriverMergeModule2.msm -l merge.log -c Test.msi


Here's some snippets from the merge.log:
Opened MSI Database: Test.msi
Opened Merge Module: DriverMergeModule2.msm
...
Merging Table: Binary
   o Merging row: DIFxApp.dll.B913F2A8_9BB5_40E4_9D7E_2541BC55A38D
   o Merging row: DIFxAppA.dll.B913F2A8_9BB5_40E4_9D7E_2541BC55A38D
...
Merging Table: CustomAction
   o Merging row: MsiProcessDrivers
>> Error: Failed to merge Row: MsiProcessDrivers into Table: CustomAction
   o Merging row: MsiInstallDrivers
>> Error: Failed to merge Row: MsiInstallDrivers into Tab

Re: [WiX-users] Very slow performance running SQL Scripts

[Rob Mensching]

And is it just the last one (100k) that is slow?  Or is the 60k slow as well?  
I hope the 2K are okay.  



-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 22:30
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

6 scripts, 4 of them around 2k rows, 1 60k rows, and the last one ...100k rows!

We don't create the scripts manually, we load the databases with data, and then 
use Red Gate to generate the SQL scripts.



-Original Message-
From: Rob Mensching [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 1:00 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

How much text (without comments) are in these SQL Scripts again?

-Original Message-
From: Eitan Behar [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 06:58
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Very slow performance running SQL Scripts

I have done a little research, and while I cannot reach any conclusion, at
least this may help to find a lead:

1. Running the scripts using sqlcmd on custom actions (using Neils' code -
thanks Neil) gives that the scripts run in less than 10mins (I am running
half of the original scripts). This is the partial log:
Action start 15:17:09: INSTALL.
Action start 15:17:11: CreateDatabase.
Action ended 15:17:11: CreateDatabase. Return value 1.
MSI (s) (24:C0) [15:19:59:731]: Executing op:
ActionStart(Name=VCDRData__22a_dbmVCDRData_Data.sql,,)
MSI (s) (24:C0) [15:27:35:370]: Executing op:
DatabaseCopy(DatabasePath=C:\WINDOWS\Installer\2528232f.msi,ProductCode={D31FEBAF-1B14-45C8-800E-6F80E658FF94},CabinetStreams=CAB001.cab,,)
Action ended 15:27:35: InstallFinalize.

2. Running the same scripts using SqlScripts take around 30 mins (using all
the scripts the time increase exponentially)
Action start 16:24:20: INSTALL.
Action start 16:24:24: CreateDatabase.
MSI (s) (48!5C) [16:41:00:894]: PROPERTY CHANGE: Adding ExecuteSqlStrings
property. Its value is (...) (very log text)
Action ended 16:24:24: CreateDatabase. Return value 1.
MSI (s) (48!5C) [16:41:00:972]: Doing action: ExecuteSqlStrings
MSI (s) (48:94) [16:41:24:916]: Invoking remote custom action. DLL:
C:\WINDOWS\Installer\MSI4D5.tmp, Entrypoint: ExecuteSqlStrings
and still running
The database creation process is common for both setups. Therefore, the
script handling is my suspect. It seems to be that the loading of the sql
scripts into ExecuteSqlStrings (see MSI (s) (48!5C) [16:41:00:894]: PROPERTY
CHANGE) is what is taking so long.

Hope this helps,

Eitan



On Mon, Dec 8, 2008 at 9:02 PM, Rob Mensching
<[EMAIL PROTECTED]>wrote:

> Sounds like it might be a performance problem in the SQL CustomActions.
>  Can you look in a verbose log file and see what actions are taking the
> longest?  Breakdown of details will help us target the things that are
> actually slow.
>
> -Original Message-
> From: Eitan Behar [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 07, 2008 12:21
> To: 'General discussion for Windows Installer XML toolset.'
> Subject: Re: [WiX-users] Very slow performance running SQL Scripts
>
> I haven't tried that, I will check tomorrow morning, but I think that they
> will run also fast. I tried the same scripts on Install Shield 12 and they
> take around 10 mins to run.
>
>
>
> -Original Message-
> From: Joe Osman [mailto:[EMAIL PROTECTED]
> Sent: Sunday, December 07, 2008 10:00 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Very slow performance running SQL Scripts
>
> Hi Eitan,
> How much does it take for your script to run if you use sqlcmd from the
> command window?
>
> Eitan Behar wrote:
> > Hi,
> >
> > I am having a serious performance problem with SQL Scripts, and would
> > appreciate some help troubleshooting it.
> >
> > This is the scenario: Use WIX to create the database, use script (within
> the
> > component creating the database) changing database properties, use
> > scripts on different component to create tables, and fill data, some
> scripts
> > are pretty big (70k+ rows).
> >
> > If I do the process from SQL Studio, it takes barely 5 minutes, from WIX
> it
> > takes more than 1 hour 
> >
> > Here is the log:
> >
> > MSI (s) (6C!7C) [13:26:04:695]: Doing action: CreateDatabase
> > Action start *13:26*:04: CreateDatabase.
> > MSI (s) (6C!7C) [*13:56*:42:069]: PROPERTY CHANGE: Adding
> ExecuteSqlStrings
> > property. Its value is
> > 'MyData_SQL_DB€RDDP-VM29€€master€-2147483648€1€€€01_properties.sql€1€USE
> > [master]€Data_properties.sql€1€EXEC dbo.sp_dbcmptlevel
> @dbname=N'AuxData',
> > @new_cmptlevel=90€AuxData_properties.sql€1€IF (1 =
> > FULLTEXTSERVICEPROPERTY('IsFullTextInstalled'))
> > begin
> > EXEC [AuxData].[dbo].[sp_fulltext_database] @action = 'enable'
> > end (...) AL

Re: [WiX-users] Writing to registry fails, but msi log reports keys written?

[Rob Mensching]

No known issues.  Thousands of people use the Registry table everyday to create 
registry keys with no issue.

Usually, these issues end up being some CustomAction wreaking havoc with what 
was expected.

-Original Message-
From: Eric Maines [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 07:41
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Writing to registry fails, but msi log reports keys 
written?


Hi wix-users,

I was recently asked to write values to the registry in a working installer.
All the other parts of the installer work, even the log seems to show it 
registered.

- The problem is when I look in the registry, the keys are not written.

(I also tried changing the Action attribute to the following: Action="write" 
and Action="append", but with no luck)

Here is my code (Registry.wxs):

http://schemas.microsoft.com/wix/2006/wi";>
  
  
  
  ANKHSVNVSINSTALLDIR
  

  
   
  




.msi log for the Condition:
...
AppSearch: Property: ANKHSVNVSINSTALLDIR, Signature: 
AnkhSvnInstalledRegistryMSI (c) (7C:04) [14:50:09:318]: Note: 1: 2262 2: 
Signature 3: -2147287038 MSI (c) (7C:04) [14:50:09:319]: PROPERTY CHANGE: 
Adding ANKHSVNVSINSTALLDIR property. Its value is 'C:\Program Files\AnkhSvn 
2.0\'.Action ended 14:50:09: AppSearch. Return value 1.
...
Here is the part log that details the registering:
...
MSI (s) (80:94) [14:50:30:481]: Executing op: 
ActionStart(Name=WriteRegistryValues,Description=Writing system registry 
values,Template=Key: [1], Name: [2], Value: [3])Action 14:50:30: 
WriteRegistryValues. Writing system registry valuesMSI (s) (80:94) 
[14:50:30:482]: Executing op: 
ProgressTotal(Total=92,Type=1,ByteEquivalent=13200)MSI (s) (80:94) 
[14:50:30:483]: Executing op: 
RegOpenKey(Root=-2147483646,Key=Software\Microsoft\AppEnv\9.0\Apps\myApp,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:483]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SolutionPersistence\SubversionScc,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:483]: Executing op: 
RegAddValue(,Value={604ad610-5cf9-4bd5-8acc-f49810e2efd4},)WriteRegistryValues: 
Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SolutionPersistence\SubversionScc,
 Name: , Value: {604ad610-5cf9-4bd5-8acc-f49810e2efd4}MSI (s) (80:94) 
[14:50:30:490]: Executing op: RegOpenKey(Root=-2147483646,Key=SOFTWARE\
 Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders,,BinaryType=0,)MSI 
(s) (80:94) [14:50:30:490]: Executing op: 
RegAddValue(,Value={8770915b-b235-42ec-bbc6-8e93286e59b5},)WriteRegistryValues: 
Key: \SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders, 
Name: , Value: {8770915b-b235-42ec-bbc6-8e93286e59b5}MSI (s) (80:94) 
[14:50:30:494]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:494]: Executing op: 
RegAddValue(Name=Service,Value={d8c473d2-9634-4513-91d5-e1a671fe2df4},)WriteRegistryValues:
 Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},
 Name: Service, Value: {d8c473d2-9634-4513-91d5-e1a671fe2df4}MSI (s) (80:94) 
[14:50:30:497]: Executing op: RegAddValue(,Value=AnkhSVN - Subversion Support 
for Visual Studio,)WriteRegistryValues: Key: \SOFTWARE\
 
Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},
 Name: , Value: AnkhSVN - Subversion Support for Visual StudioMSI (s) (80:94) 
[14:50:30:501]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:501]: Executing op: 
RegAddValue(Name=Package,Value={604ad610-5cf9-4bd5-8acc-f49810e2efd4},)WriteRegistryValues:
 Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,
 Name: Package, Value: {604ad610-5cf9-4bd5-8acc-f49810e2efd4}MSI (s) (80:94) 
[14:50:30:505]: Executing op: RegAddValue(,Value=##100,)WriteRegistryValues: 
Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,
 Name: , Value: ##100MSI (s) (80:94) [14:50:30:508]: Executing op: 
RegOpenKey(Root=-2147483646,K
 ey=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\ToolsOptionsPages\Source 
Control,,BinaryType=0,)
...

I'm stuck. I was wondering if there any known bugs with the Registry tag, or 
maybe something I could be doing wrong?

Thanks,

Eric
_

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
h

Re: [WiX-users] does

[Rob Mensching]

No.

-Original Message-
From: Robert O'Brien [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 16:37
To: 'General discussion for Windows Installer XML toolset.'
Subject: [WiX-users] does http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem passing property value to a deferred VB Script custom action

[Rob Mensching]

What?  No, don't do that.  If you're immediate Custom Action isn't elevated 
then it won't succeed... plus you're likely to leave junk behind.

Read about deferred CustomActions in the MSI SDK, there is a very specific 
mechanism called "CustomActionData" that is used to pass data to deferred 
Custom Actions.

PS:  you might read through: 
https://blogs.msdn.com/robmen/archive/2004/05/20/136530.aspx.

PPS:  the Windows Installer can delete folders, a CustomAction like this will 
just add fragility to your install.

-Original Message-
From: Romeo Salayo Jr. [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 02:45
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Problem passing property value to a deferred VB Script 
custom action


When executing CA as deffered it has no access from the MSI property anymore.
What you can do is store the value in the registry (HKLM) and then read the
value from there.

Regards,
Romeo


Andy2k8 wrote:
>
> Hello
>
>  I have defined a property and elevated custom action as follows:
>
> 
>   
> 
>
>  Property="DeletePCCConsoleFolder" Value="DeleteConsoleFolder"/>
>  Property="CustomActionData" Execute="deferred" Impersonate="no"
> Return="check"/>
>
> And this is sequenced as :
>
>Before="DeletePCCConsoleFolder">NOT Installed
>   NOT
> Installed
>
> However i get the following error when i run the MSI
>
> MSI (s) (70:54) [15:35:58:181]: Executing op:
> ActionStart(Name=DeletePCCConsoleFolder,,)
> Action 15:35:58: DeletePCCConsoleFolder.
> MSI (s) (70:54) [15:35:58:181]: Executing op:
> CustomActionSchedule(Action=DeletePCCConsoleFolder,ActionType=3126,,Target=Main,CustomActionData=DeleteConsoleFolder)
> MSI (s) (70:54) [15:35:58:181]: Creating MSIHANDLE (5) of type 790536 for
> thread 2644
> MSI (s) (70:E8) [15:35:58:181]: Creating MSIHANDLE (6) of type 0 for
> thread 1000
> MSI (s) (70:AC) [15:35:58:181]: Generating random cookie.
> MSI (s) (70:AC) [15:35:58:196]: Created Custom Action Server with PID 2628
> (0xA44).
> MSI (s) (70:B0) [15:35:58:227]: Running as a service.
> MSI (s) (70:B0) [15:35:58:227]: Hello, I'm your 32bit Elevated custom
> action server.
> Error 1720. There is a problem with this Windows Installer package. A
> script required for this install to complete could not be run. Contact
> your support personnel or package vendor. Custom action  script error , :
> Line , Column ,
> MSI (s) (70:E8) [15:35:59:321]: Product: ABC 5.0 Console -- Error 1720.
> There is a problem with this Windows Installer package. A script required
> for this install to complete could not be run. Contact your support
> personnel or package vendor. Custom action  script error , :  Line ,
> Column ,
>
> MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (6) of type 0 for thread
> 1000
> MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (5) of type 790536 for
> thread 2644
> Action ended 15:35:59: InstallFinalize. Return value 3.
>
> As far as I know, the steps I have followed to pass the property value to
> the deferred CA are right.Why is my script still fails then?
> Any help?
>

--
View this message in context: 
http://n2.nabble.com/Problem-passing-property-value-to-a-deferred-VB-Script-custom-action-tp1638102p1638193.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Network Install: How To Control What User Sees?

[Rob Mensching]

Note, you can have an "Admin Install UI" that shows up when the admin creates 
the network image and you can specify "Admin Properties" that are persisted 
during that process.  That can be used, for example, to have the Admin accept 
the EULA and have the act of accepting the EULA stored in the network image.

There is a lot to Group Policy deployment that is *way* beyond the scope of the 
WiX toolset.  I suggest finding some good documentation/whitepapers on the 
Group Policy deployment topic and reading for a while.  I remember there being 
a lot to Group Policy deployment back when I worked on Office.

-Original Message-
From: zett42 [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 05:23
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Network Install: How To Control What User Sees?



Andrew Kendall-2 wrote:
>
> Given that no dialogs appear for a client install, how do you control what
> gets installed? Is there some default value for each button/checkbox that
> the user is not seeing!?
>
For a per-machine installation via group policies, only the
InstallExecuteSequence is run. By default, it uses the values of properties
specified in the property table and it installs features depending on the
"level" of the feature.
You can simulate this by running "msiexec /qn Package.msi". Note however,
that during group policy installation, the package has no access to any
user-profile data.

If you want a customized group policy installation, you need to assign a
transform file (.mst) to the group policy object. The MST-file is then
applied "on-the-fly" during installation of the package to change/add/remove
some properties. For instance, the transform could supply the ADDLOCAL
property to specify which features to install.
Look in MSDN how transforms are created.
--
View this message in context: 
http://n2.nabble.com/Network-Install%3A-How-To-Control-What-User-Sees--tp1633615p1638742.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong Isolated Apps

[Roy Abou Assaly]

Rob Mensching-2 wrote:
> 
> ClickThrough has significant bugs that have all been punted to WiX v4
> essentially rendering ClickThrough useless until then.
> 

Thanks for the quick reply!

-- 
View this message in context: 
http://n2.nabble.com/ClickThrough-3.0.4805.0-throws-exception-when-selectiong-Isolated-Apps-tp1639081p1639549.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] difference between lit and light

[Rob Mensching]

http://robmensching.com/blog/archive/2008/10/10/What-are-.wixlibs-and-why-would-you-use-them.aspx
 - has more information about .wixlibs.

-Original Message-
From: Dale Stewart [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 06:55
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] difference between lit and light

See the diagram in the WiX help file (About WiX->Tools and Concepts).  Lit
creates a library that can be consumed by light.  You don't have to use
"lit", but if you want to package multiple "wxs" files into a reusable
library, that is what you would use, as I understand it.

-Original Message-
From: Sean Farrow [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 8:30 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] difference between lit and light

Hi:
can someone please explain the difference between lit.exe and light.exe,
are both required?
Cheered
Sean.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong Isolated Apps

[Rob Mensching]

ClickThrough has significant bugs that have all been punted to WiX v4 
essentially rendering ClickThrough useless until then.

-Original Message-
From: Roy Abou Assaly [mailto:[EMAIL PROTECTED]
Sent: Wednesday, December 10, 2008 06:58
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong 
Isolated Apps



Hi,

I'm using the WiX Beta Exit build 3.0.4805.0.

1. I start ClickThrough
2. I select Click Through for Office Addins (shouldn't it be ClickThrough
and Click Through? Typo?)
3. I get taken to the "Build" page with the 7 steps.  Everything is good.

Now, when

1. I start ClickThrough
2. I select Click Through for Isolated Applications (shouldn't it be
ClickThrough and Click Through? Typo?)
3. An exception is thrown and I stay on the "Welcome Page"

I had another colleague test it on his machine and he got the same
exception.  I'm using Windows Vista SP1.

Any help is appreciated.

Thanks,

Roy

See the end of this message for details on invoking
just-in-time (JIT) debugging instead of this dialog box.

** Exception Text **
System.ArgumentException: Win32 handle that was passed to Icon is not valid
or is the wrong type.
   at System.Drawing.Icon..ctor(IntPtr handle, Boolean takeOwnership)
   at System.Drawing.Icon..ctor(IntPtr handle)
   at System.Drawing.Icon.FromHandle(IntPtr handle)
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.NativeMethods.GetDirectoryIcon(Boolean
small, Boolean open)
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.PickEntryStep..ctor()
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.IsolatedAppClickThroughUI.GetControls()
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.InitializeFromFabricator()
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.set_Extension(ClickThroughUIExtension
value)
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.ClickThroughForm.ShowWorkPage(Object
sender, ClickThroughUIExtension extension)
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WelcomePage.ComboBox_SelectedIndexChanged(Object
sender, EventArgs e)
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.WmReflectCommand(Message& m)
   at System.Windows.Forms.ComboBox.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)


** Loaded Assemblies **
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

ctui
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/ctui.exe

System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll

System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

wui
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wui.DLL

wix
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wix.DLL

System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll

WixIsolatedAppExtension
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/WixIsolatedAppExtension.DLL

wconsole
Assembly Version:

Re: [WiX-users] WixDIFxAppExtension and MergeModules

[Moradi, Ari]

Re: The reason to use the MFC merge modules is that they're the recommended
way of distributing MFC (other than locally) and that they install
resources so it's important to use the merge module to follow component
rules. Neither is true of DifxApp.

I understand your point.  However, I think that the DIFx merge module 
dependency is a good way to go, because right now, it is not possible to build 
two different merge modules using DIFxAppExtension and then include them both 
in the same MSI.  Any good solution to that problem would make me happy :)  My 
current solution is to not use the DIFxAppExtension and to define the 
MsiDriverPackages table using a  element and to add the dependency 
on the merge module from the WDK.  I'd prefer to be able to use the extension 
and the  element.

I'll submit a feature request, but my request is really that I can build 
multiple driver merge modules using DIFxAppExtension that work when merged into 
a single MSI, not necessarily that the solution to the problem is using the 
DIFxApp merge module.

Thanks,

-Ari



-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]
Sent: Tuesday, December 09, 2008 10:23 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] WixDIFxAppExtension and MergeModules

Moradi, Ari wrote:
> There isn't a DIFxApp merge module in WiX, but there is one in the WDK.  WiX 
> can certainly add a dependency on a merge module that isn't shipped with WiX.

You're suggesting WixDifxAppExtension should use the WDK merge modules?
Interesting, assuming the merge modules are well-authored. Please file a
feature request so it's not lost.

>   Wouldn't you do the same thing with the MFC redistributable (add a merge 
> module dependency)?  You wouldn't add the MFC components directly to your own 
> merge module, right?
>

The reason to use the MFC merge modules is that they're the recommended
way of distributing MFC (other than locally) and that they install
resources so it's important to use the merge module to follow component
rules. Neither is true of DifxApp.

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



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Writing to registry fails, but msi log reports keys written?

[Eric Maines]

Hi wix-users,
 
I was recently asked to write values to the registry in a working installer.
All the other parts of the installer work, even the log seems to show it 
registered.
 
- The problem is when I look in the registry, the keys are not written.
 
(I also tried changing the Action attribute to the following: Action="write" 
and Action="append", but with no luck)
 
Here is my code (Registry.wxs):

http://schemas.microsoft.com/wix/2006/wi";>
  
  
  
  ANKHSVNVSINSTALLDIR
  
 
  
   
  



 
.msi log for the Condition:
...
AppSearch: Property: ANKHSVNVSINSTALLDIR, Signature: 
AnkhSvnInstalledRegistryMSI (c) (7C:04) [14:50:09:318]: Note: 1: 2262 2: 
Signature 3: -2147287038 MSI (c) (7C:04) [14:50:09:319]: PROPERTY CHANGE: 
Adding ANKHSVNVSINSTALLDIR property. Its value is 'C:\Program Files\AnkhSvn 
2.0\'.Action ended 14:50:09: AppSearch. Return value 1.
...
Here is the part log that details the registering:
...
MSI (s) (80:94) [14:50:30:481]: Executing op: 
ActionStart(Name=WriteRegistryValues,Description=Writing system registry 
values,Template=Key: [1], Name: [2], Value: [3])Action 14:50:30: 
WriteRegistryValues. Writing system registry valuesMSI (s) (80:94) 
[14:50:30:482]: Executing op: 
ProgressTotal(Total=92,Type=1,ByteEquivalent=13200)MSI (s) (80:94) 
[14:50:30:483]: Executing op: 
RegOpenKey(Root=-2147483646,Key=Software\Microsoft\AppEnv\9.0\Apps\myApp,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:483]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SolutionPersistence\SubversionScc,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:483]: Executing op: 
RegAddValue(,Value={604ad610-5cf9-4bd5-8acc-f49810e2efd4},)WriteRegistryValues: 
Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SolutionPersistence\SubversionScc,
 Name: , Value: {604ad610-5cf9-4bd5-8acc-f49810e2efd4}MSI (s) (80:94) 
[14:50:30:490]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:490]: Executing op: 
RegAddValue(,Value={8770915b-b235-42ec-bbc6-8e93286e59b5},)WriteRegistryValues: 
Key: \SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders, 
Name: , Value: {8770915b-b235-42ec-bbc6-8e93286e59b5}MSI (s) (80:94) 
[14:50:30:494]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:494]: Executing op: 
RegAddValue(Name=Service,Value={d8c473d2-9634-4513-91d5-e1a671fe2df4},)WriteRegistryValues:
 Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},
 Name: Service, Value: {d8c473d2-9634-4513-91d5-e1a671fe2df4}MSI (s) (80:94) 
[14:50:30:497]: Executing op: RegAddValue(,Value=AnkhSVN - Subversion Support 
for Visual Studio,)WriteRegistryValues: Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5},
 Name: , Value: AnkhSVN - Subversion Support for Visual StudioMSI (s) (80:94) 
[14:50:30:501]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,,BinaryType=0,)MSI
 (s) (80:94) [14:50:30:501]: Executing op: 
RegAddValue(Name=Package,Value={604ad610-5cf9-4bd5-8acc-f49810e2efd4},)WriteRegistryValues:
 Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,
 Name: Package, Value: {604ad610-5cf9-4bd5-8acc-f49810e2efd4}MSI (s) (80:94) 
[14:50:30:505]: Executing op: RegAddValue(,Value=##100,)WriteRegistryValues: 
Key: 
\SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\SourceControlProviders\{8770915B-B235-42EC-BBC6-8E93286E59B5}\Name,
 Name: , Value: ##100MSI (s) (80:94) [14:50:30:508]: Executing op: 
RegOpenKey(Root=-2147483646,Key=SOFTWARE\Microsoft\AppEnv\9.0\Apps\myApp\2.0\ToolsOptionsPages\Source
 Control,,BinaryType=0,)
...
 
I'm stuck. I was wondering if there any known bugs with the Registry tag, or 
maybe something I could be doing wrong?
 
Thanks,
 
Eric
_

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] ClickThrough 3.0.4805.0 throws exception when selectiong Isolated Apps

[Roy Abou Assaly]

Hi,

I'm using the WiX Beta Exit build 3.0.4805.0.  

1. I start ClickThrough
2. I select Click Through for Office Addins (shouldn't it be ClickThrough
and Click Through? Typo?)
3. I get taken to the "Build" page with the 7 steps.  Everything is good.

Now, when

1. I start ClickThrough
2. I select Click Through for Isolated Applications (shouldn't it be
ClickThrough and Click Through? Typo?)
3. An exception is thrown and I stay on the "Welcome Page"

I had another colleague test it on his machine and he got the same
exception.  I'm using Windows Vista SP1. 

Any help is appreciated.

Thanks,

Roy

See the end of this message for details on invoking 
just-in-time (JIT) debugging instead of this dialog box.

** Exception Text **
System.ArgumentException: Win32 handle that was passed to Icon is not valid
or is the wrong type.
   at System.Drawing.Icon..ctor(IntPtr handle, Boolean takeOwnership)
   at System.Drawing.Icon..ctor(IntPtr handle)
   at System.Drawing.Icon.FromHandle(IntPtr handle)
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.NativeMethods.GetDirectoryIcon(Boolean
small, Boolean open)
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.ClickThrough.PickEntryStep..ctor()
   at
Microsoft.Tools.WindowsInstallerXml.Extensions.IsolatedAppClickThroughUI.GetControls()
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.InitializeFromFabricator()
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WorkPage.set_Extension(ClickThroughUIExtension
value)
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.ClickThroughForm.ShowWorkPage(Object
sender, ClickThroughUIExtension extension)
   at
Microsoft.Tools.WindowsInstallerXml.Tools.ClickThrough.WelcomePage.ComboBox_SelectedIndexChanged(Object
sender, EventArgs e)
   at System.Windows.Forms.ComboBox.OnSelectedIndexChanged(EventArgs e)
   at System.Windows.Forms.ComboBox.WmReflectCommand(Message& m)
   at System.Windows.Forms.ComboBox.WndProc(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.OnMessage(Message& m)
   at System.Windows.Forms.Control.ControlNativeWindow.WndProc(Message& m)
   at System.Windows.Forms.NativeWindow.Callback(IntPtr hWnd, Int32 msg,
IntPtr wparam, IntPtr lparam)


** Loaded Assemblies **
mscorlib
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/Microsoft.NET/Framework/v2.0.50727/mscorlib.dll

ctui
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/ctui.exe

System.Windows.Forms
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Windows.Forms/2.0.0.0__b77a5c561934e089/System.Windows.Forms.dll

System
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System/2.0.0.0__b77a5c561934e089/System.dll

System.Drawing
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Drawing/2.0.0.0__b03f5f7f11d50a3a/System.Drawing.dll

wui
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wui.DLL

wix
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wix.DLL

System.Configuration
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Configuration/2.0.0.0__b03f5f7f11d50a3a/System.Configuration.dll

System.Xml
Assembly Version: 2.0.0.0
Win32 Version: 2.0.50727.3053 (netfxsp.050727-3000)
CodeBase:
file:///C:/Windows/assembly/GAC_MSIL/System.Xml/2.0.0.0__b77a5c561934e089/System.Xml.dll

WixIsolatedAppExtension
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/WixIsolatedAppExtension.DLL

wconsole
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/wconsole.DLL

WixOfficeExtension
Assembly Version: 3.0.0.0
Win32 Version: 3.0.4805.0
CodeBase:
file:///C:/Program%20Files/Windows%20Installer%20XML%20v3/bin/WixOfficeExtension.DLL
--

Re: [WiX-users] difference between lit and light

[Dale Stewart]

See the diagram in the WiX help file (About WiX->Tools and Concepts).  Lit
creates a library that can be consumed by light.  You don't have to use
"lit", but if you want to package multiple "wxs" files into a reusable
library, that is what you would use, as I understand it.

-Original Message-
From: Sean Farrow [mailto:[EMAIL PROTECTED] 
Sent: Wednesday, December 10, 2008 8:30 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] difference between lit and light

Hi: 
can someone please explain the difference between lit.exe and light.exe,
are both required?
Cheered
Sean.

--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] difference between lit and light

[Sean Farrow]

Hi: 
can someone please explain the difference between lit.exe and light.exe,
are both required?
Cheered
Sean.
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Network Install: How To Control What User Sees?

[zett42]

Andrew Kendall-2 wrote:
> 
> Given that no dialogs appear for a client install, how do you control what
> gets installed? Is there some default value for each button/checkbox that
> the user is not seeing!?
> 
For a per-machine installation via group policies, only the
InstallExecuteSequence is run. By default, it uses the values of properties
specified in the property table and it installs features depending on the
"level" of the feature. 
You can simulate this by running "msiexec /qn Package.msi". Note however,
that during group policy installation, the package has no access to any
user-profile data.

If you want a customized group policy installation, you need to assign a
transform file (.mst) to the group policy object. The MST-file is then
applied "on-the-fly" during installation of the package to change/add/remove
some properties. For instance, the transform could supply the ADDLOCAL
property to specify which features to install.
Look in MSDN how transforms are created.
-- 
View this message in context: 
http://n2.nabble.com/Network-Install%3A-How-To-Control-What-User-Sees--tp1633615p1638742.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Network Install: How To Control What User Sees?

[Andrew Kendall]

Hi Bob et al,

Sorry, I'm not clear on this at all. I'm struggling with network install 
concepts in general here, and perhaps I should outline what I am trying to 
achieve a bit more clearly.

The installation package for our product is currently created using 
InstallShield, for a traditional, non-MSI install. Using the Wix toolset, I am 
creating a Windows Installer version in order to facilitate automatic network 
installs from Windows a domain server, using Group Policy Objects. The Windows 
Installer version will supercede the InstallShield version for all clients.

So far I have created an install package that a user would manually invoke to 
install the product on their machine. It goes through a typical set of dialogs, 
from accepting a licence agreement, then offering an installation choice of 
Typical, Custom or Complete. For the Custom option, it then offers the user 
various additional options.

Ok, if an individual user wants to install our product on their computer, no 
problem. What I don't understand is how to set things up for a network install, 
whereby an administrator specifies a bunch of install options, which are then 
propagated to each client install.

Given that no dialogs appear for a client install, how do you control what gets 
installed? Is there some default value for each button/checkbox that the user 
is not seeing!?

Under the traditional InstallShield system, the administrator goes through the 
install process and it records the options that have been chosen in some kind 
of config file. This file is then invoked by individual users on their own 
machines to install the product according to the options chosen by the 
administrator. Does the Windows Installer system have something similar, 
whereby administrator-defined options can be propagated to all clients at 
install time? 

A important issue here is that we have a network version of our product which, 
if installed, means that client machines need to know certain central items of 
data, ie. IP addresses. How can such data be set up by an administrator such 
that it is available to a client machine when the product is installed.

Regardin Bob's mention of the ADDLOCAL property, how does an adminstrator 
'supply properties like ADDLOCAL to install particular (or all) features of a 
product'?

I'm fumbling around in the dark here on this whole area of network installs, 
and would be most grateful for some clear guidance. Like I say, it's concepts I 
need to know about here, rather than technical specifics.

Many, many thanks.

Andrew Kendall






From: Bob Arnson <[EMAIL PROTECTED]>
To: General discussion for Windows Installer XML toolset. 

Sent: Tuesday, 9 December, 2008 22:46:11
Subject: Re: [WiX-users] Network Install: How To Control What User Sees?

Andrew Kendall wrote:
> How does the Network Administrator control what gets installed on a client 
> machine, in terms of whether the user should see the dialogs or not? For a 
> network install, how is even something as simple as acceptance of a Licence 
> Agreement handled, when no dialog appears for the user? 

They generally don't: The admin accepts the EULA on the user's behalf, 
and supplies properties like ADDLOCAL to install particular (or all) 
features of a product.

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



--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] finding nant

[Neil Sleightholm]

I think you click on the +'s to navigate to the zip files.
 
Neil
 
Neil Sleightholm
X2 Systems Limited
[EMAIL PROTECTED]  
 



From: Sean Farrow [mailto:[EMAIL PROTECTED]
Sent: Wed 10/12/2008 07:22
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] finding nant



Hi:
has anyone got the latest build of nant, required tobuild wix, the nant
page giving the latest files are down.
Any help apreciated.
Chers
Sean.
--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Problem passing property value to a deferred VB Script custom action

[Romeo Salayo Jr.]

When executing CA as deffered it has no access from the MSI property anymore.
What you can do is store the value in the registry (HKLM) and then read the
value from there.

Regards,
Romeo


Andy2k8 wrote:
> 
> Hello
> 
>  I have defined a property and elevated custom action as follows:
> 
> 
>   
> 
> 
>  Property="DeletePCCConsoleFolder" Value="DeleteConsoleFolder"/>
>  Property="CustomActionData" Execute="deferred" Impersonate="no" 
> Return="check"/>
> 
> And this is sequenced as :
> 
>Before="DeletePCCConsoleFolder">NOT Installed
>   NOT
> Installed
> 
> However i get the following error when i run the MSI
> 
> MSI (s) (70:54) [15:35:58:181]: Executing op:
> ActionStart(Name=DeletePCCConsoleFolder,,)
> Action 15:35:58: DeletePCCConsoleFolder. 
> MSI (s) (70:54) [15:35:58:181]: Executing op:
> CustomActionSchedule(Action=DeletePCCConsoleFolder,ActionType=3126,,Target=Main,CustomActionData=DeleteConsoleFolder)
> MSI (s) (70:54) [15:35:58:181]: Creating MSIHANDLE (5) of type 790536 for
> thread 2644
> MSI (s) (70:E8) [15:35:58:181]: Creating MSIHANDLE (6) of type 0 for
> thread 1000
> MSI (s) (70:AC) [15:35:58:181]: Generating random cookie.
> MSI (s) (70:AC) [15:35:58:196]: Created Custom Action Server with PID 2628
> (0xA44).
> MSI (s) (70:B0) [15:35:58:227]: Running as a service.
> MSI (s) (70:B0) [15:35:58:227]: Hello, I'm your 32bit Elevated custom
> action server.
> Error 1720. There is a problem with this Windows Installer package. A
> script required for this install to complete could not be run. Contact
> your support personnel or package vendor. Custom action  script error , : 
> Line , Column ,  
> MSI (s) (70:E8) [15:35:59:321]: Product: ABC 5.0 Console -- Error 1720.
> There is a problem with this Windows Installer package. A script required
> for this install to complete could not be run. Contact your support
> personnel or package vendor. Custom action  script error , :  Line ,
> Column ,  
> 
> MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (6) of type 0 for thread
> 1000
> MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (5) of type 790536 for
> thread 2644
> Action ended 15:35:59: InstallFinalize. Return value 3.
> 
> As far as I know, the steps I have followed to pass the property value to
> the deferred CA are right.Why is my script still fails then?
> Any help?
> 

-- 
View this message in context: 
http://n2.nabble.com/Problem-passing-property-value-to-a-deferred-VB-Script-custom-action-tp1638102p1638193.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Problem passing property value to a deferred VB Script custom action

[Andy2k8]

Hello

 I have defined a property and elevated custom action as follows:


  





And this is sequenced as :

  NOT Installed
  NOT
Installed

However i get the following error when i run the MSI

MSI (s) (70:54) [15:35:58:181]: Executing op:
ActionStart(Name=DeletePCCConsoleFolder,,)
Action 15:35:58: DeletePCCConsoleFolder. 
MSI (s) (70:54) [15:35:58:181]: Executing op:
CustomActionSchedule(Action=DeletePCCConsoleFolder,ActionType=3126,,Target=Main,CustomActionData=DeleteConsoleFolder)
MSI (s) (70:54) [15:35:58:181]: Creating MSIHANDLE (5) of type 790536 for
thread 2644
MSI (s) (70:E8) [15:35:58:181]: Creating MSIHANDLE (6) of type 0 for thread
1000
MSI (s) (70:AC) [15:35:58:181]: Generating random cookie.
MSI (s) (70:AC) [15:35:58:196]: Created Custom Action Server with PID 2628
(0xA44).
MSI (s) (70:B0) [15:35:58:227]: Running as a service.
MSI (s) (70:B0) [15:35:58:227]: Hello, I'm your 32bit Elevated custom action
server.
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor. Custom action  script error , :  Line , Column
,  
MSI (s) (70:E8) [15:35:59:321]: Product: PowerChute Central 1.0 Console --
Error 1720. There is a problem with this Windows Installer package. A script
required for this install to complete could not be run. Contact your support
personnel or package vendor. Custom action  script error , :  Line , Column
,  

MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (6) of type 0 for thread
1000
MSI (s) (70:E8) [15:35:59:322]: Closing MSIHANDLE (5) of type 790536 for
thread 2644
Action ended 15:35:59: InstallFinalize. Return value 3.

As far as I know, the steps I have followed to pass the property value to
the deferred CA are right.Why is my script still fails then?
Any help?

-
Andy
MSI Developer
Schneider Electric:working:
-- 
View this message in context: 
http://n2.nabble.com/Problem-passing-property-value-to-a-deferred-VB-Script-custom-action-tp1638102p1638102.html
Sent from the wix-users mailing list archive at Nabble.com.


--
SF.Net email is Sponsored by MIX09, March 18-20, 2009 in Las Vegas, Nevada.
The future of the web can't happen without you.  Join us at MIX09 to help
pave the way to the Next Web now. Learn more and register at
http://ad.doubleclick.net/clk;208669438;13503038;i?http://2009.visitmix.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users