Re: [WiX-users] Wix V3 UI image substitution

[Bob Arnson]

Mike Dimmick wrote:

  
  
  
  Having downloaded the latest
weekly (3.0.2128.0), I can confirm that this seems to work - setting
-dWixUILicenseRtf=License.rtf caused it to be picked up and used in the
MSI.

Yes, the idea is to be more flexible than the WiX v2 approach. Using
WiX variables is more verbose but I think that's a good thing when it
comes to things like which license file you ship with.
-- 
sig://boB
http://bobs.org


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Launching a CHM

[Bob Arnson]

Rob Mensching wrote:
> So does that mean you are writing it, Bob?  
>   
I'll happily put it on my ever-growing list. Maybe even in the top 10, 
as I think this would be a very useful CA. But that still puts it 
somewhere in 2009.

-- 
sig://boB
http://bobs.org


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing machine-specific license files

[Bob Arnson]

Arnette, Bill wrote:

  
  
  RE: [WiX-users] Installing machine-specific license files

  Actually, I was thinking I could use the same
product code, upgrade code, and component ids for each customized
license file installer.  I don't think this will be a problem.  Am I
missing something?
  

It'll be a problem only if someone might end up installing more than
one.

-- 
sig://boB
http://bobs.org


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to check for returned value of a call to app.exe

[Rob Mensching]

You can’t do that.  I suggest reading the documentation
that Jason pointed out.  It explains how limited exe CustomActions can
be.  If you really want that much control over your installation, you
should write a DLL CustomAction.  Those have the ability to be more
robust.

 

 





From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Theodore
Kuo (Siemens Business Services Inc)
Sent: Friday, September 29, 2006 17:06
To: Jason Swager; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to check for returned value of a call to
app.exe





 

Thanks, Jason.  I looked up
the information in the link but couldn’t find anything that would be
helpful to me.

 

Suppose I want write an installer
wix file that executes app.exe sometime during installation.  If app.exe
returns 0 it proceeds with the installation,  if it returns 1, it opens
dialog1, and if it returns 2, it opens dialog2.  I know how you can
sequence dialogs and custom actions with  and
 respectively, but I’m not sure how to
handle the case of how to continue sequencing upon different conditions
returned by a call to an .exe file.

 

Any help where I can find a
simple example on this will be much appreciated.

 

Ted 

 



From: Jason Swager
[mailto:[EMAIL PROTECTED] 
Sent: Friday, September 29, 2006 3:23 PM
To: Theodore Kuo (Siemens Business Services Inc);
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to check for returned value of a call to
app.exe



 

When
using Return="check", the executable should return zero for success
and non-zero for failure.  I don't think there is a way to respond to
different returns - if it fails, your install halts.  If it succeeds, the
install continues.  If you need to pass information back from the
executable, consider writing a custom action that can modify properties.

See the MSI documention for additional details:


"Theodore Kuo (Siemens Business Services Inc)"
<[EMAIL PROTECTED]> wrote:



Hi,





 





I’m still new to Wix, so I’m sorry if my
question may seem rudimentary to you.





 





I’m trying to get Wix to execute an application that
returns a status (i.e. OK or an error code), and have Wix checked on the return
status and perform further action based on the returned status.  I used
custom action to execute the application as follow:





 











 





I’m not sure what the Return value should be (is
“check” correct?).  Now how do I check for the returned status
of app.exe and perform further actions?





 





Your quick reply will be much appreciated as I need to get
this done by end of the day.





 





Thanks,





Ted





 



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 






-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to check for returned value of a call to app.exe

[Theodore Kuo (Siemens Business Services Inc)]

Thanks, Jason.  I looked up
the information in the link but couldn’t find anything that would be
helpful to me.

 

Suppose I want write an
installer wix file that executes app.exe sometime during installation.  If
app.exe returns 0 it proceeds with the installation,  if it returns 1, it
opens dialog1, and if it returns 2, it opens dialog2.  I know how you can
sequence dialogs and custom actions with  and
 respectively, but I’m not sure how to handle
the case of how to continue sequencing upon different conditions returned by a
call to an .exe file.

 

Any help where I can find a
simple example on this will be much appreciated.

 

Ted 

 



From: Jason Swager
[mailto:[EMAIL PROTECTED] 
Sent: Friday, September 29, 2006 3:23 PM
To: Theodore Kuo (Siemens Business Services Inc);
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to check for returned value of a call to
app.exe



 

When
using Return="check", the executable should return zero for success
and non-zero for failure.  I don't think there is a way to respond to
different returns - if it fails, your install halts.  If it succeeds, the
install continues.  If you need to pass information back from the
executable, consider writing a custom action that can modify properties.

See the MSI documention for additional details:


"Theodore Kuo (Siemens Business Services Inc)"
<[EMAIL PROTECTED]> wrote:



Hi,





 





I’m still new to Wix, so I’m sorry if my
question may seem rudimentary to you.





 





I’m trying to get Wix to execute an application that
returns a status (i.e. OK or an error code), and have Wix checked on the return
status and perform further action based on the returned status.  I used
custom action to execute the application as follow:





 











 





I’m not sure what the Return value should be (is
“check” correct?).  Now how do I check for the returned status
of app.exe and perform further actions?





 





Your quick reply will be much appreciated as I need to get
this done by end of the day.





 





Thanks,





Ted





 



-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

 






-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to check for returned value of a call to app.exe

[Jason Swager]

When using Return="check", the executable should return zero for success and non-zero for failure.  I don't think there is a way to respond to different returns - if it fails, your install halts.  If it succeeds, the install continues.  If you need to pass information back from the executable, consider writing a custom action that can modify properties.See the MSI documention for additional details: "Theodore Kuo (Siemens Business Services Inc)" <[EMAIL PROTECTED]> wrote:Hi,     I’m still new to Wix, so I’m sorry if my question may seem rudimentary to you.     I’m trying to get Wix to execute an application that returns a status (i.e. OK or an error code), and have Wix checked on the return status and perform further action based on the returned status.  I used custom action to execute the application as follow:      I’m not sure what the Return value should be (is “check” correct?).  Now
 how do I check for the returned status of app.exe and perform further actions?     Your quick reply will be much appreciated as I need to get this done by end of the day.     Thanks,  Ted   -Take Surveys. Earn Cash. Influence the Future of ITJoin SourceForge.net's Techsay panel and you'll get the chance to share youropinions on IT & business topics through brief surveys -- and earn cashhttp://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___WiX-users mailing
 listWiX-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/wix-users-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to check for returned value of a call to app.exe

[Theodore Kuo (Siemens Business Services Inc)]

Hi,

 

I’m still new to Wix, so I’m sorry if my
question may seem rudimentary to you.

 

I’m trying to get Wix to execute an application that
returns a status (i.e. OK or an error code), and have Wix checked on the return
status and perform further action based on the returned status.  I used
custom action to execute the application as follow:

 



 

I’m not sure what the Return value should be (is
“check” correct?).  Now how do I check for the returned status
of app.exe and perform further actions?

 

Your quick reply will be much appreciated as I need to get
this done by end of the day.

 

Thanks,

Ted

 






-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] heat cannot find MSVCR80.dll

[Mike Holcomb]

Why are you running heat.exe each time you
build?  I would think you just run it once, and then modify the source
files to fit into your build environment.

 

I was able to get heat working with DLLs
that had a dependency on MSVCR80.dll with a heat.exe.manifest that contains the
following:

 





    

    WiX
Toolset Harvester

    

   


   


   


    

    

   


   


   


   


   


    



 

 

Place that beside heat.exe and have the 8.0
vcredist installed, and it should work.

 

Thanks,

Mike

 









From:
[EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]
On Behalf Of Steven Chin
Sent: Friday, September 29, 2006
9:56 AM
To: Mike Dimmick;
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] heat
cannot find MSVCR80.dll



 

Thanks for the info Mike.  I think it
has more to do with the manifests in the DLLs and lack of manifests in
some.  If I remove a manifest from a DLL that has one of the VC80.CRT
dependencies then I will get more of these pop ups.  I know that I have 34
DLLs that have VC80.CRT dependencies that don’t have manifests but if I
try to add the manifests to the DLLs I will get 54 pop up errors.  Because
of this problem I am going to try using tallow and the 2.0 tools.  Tallow
has no problems with the DLLS and their manifest or no manifests at this
time.  Thanks again.

 









From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 21, 2006
2:03 PM
To: Steven Chin;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll



 





Heat is trying to extract
self-registration information from the DLLs. To do this, it uses the
RegOverridePredefKey API to get a clean version of the HKEY_CURRENT_USER,
HKEY_LOCAL_MACHINE keys so that the actual machine environment isn't affected,
and to simplify working out what was written. It then calls the DLL's
DllSelfRegister entry point to get it to perform its self-registration to the surrogate
keys. From this it fills out the Class and Registry tables as appropriate.





 





Unfortunately, these keys are completely clean, and various
self-registration code will fail if some other registry keys and values they
depend on are missing. Here, it's that the side-by-side code in the Windows
loader is looking for registry information about the side-by-side DLLs, and
failing to find it, and presumably that Sun's self-registration code is looking
for the same.





 





If you're shipping C++ DLLs you should know what the correct
GUIDs are for the classes and type libraries - they'll be in your source code
somewhere. Author this manually, don't use heat - that's for tools which
autogenerate GUIDs like VB6. Also, heat is something intended to be run once to
capture an initial script, it's not really meant for running on every build.





 





As for the Java runtime, if you're shipping it yourself, use
Sun's installer. Then Sun can service it correctly. Always ship third-party components
according to the developer's guidance. The component rules mean that unless
you're extremely careful, you'll end up breaking someone else's application
when yours is uninstalled.





 





(Hopefully third-time-lucky)





 





-- 





Mike Dimmick







 







From: Steven Chin
[mailto:[EMAIL PROTECTED]
Sent: Thu 21/09/2006 15:30
To: Mike Dimmick;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll





Hi Mike,

Heat runs but many of our DLLs in our
product have a manifest in them indicating this dependency.  I noticed
that we have at least a dozen DLLs with manifests requiring VC80.CRT"
version="8.0.50608.0 but the pop-up error saying it cannot find
MSVCR80.DLL only comes up 4 times.  Maybe it is something else.

 

We are not trying to include the Visual C
Runtime in our package.  How would we ignore this dependency from
Heat?  A pop up appears requiring user intervention and I am running heat
from a perl script so as to have the build be automated.

 

We are shipping a copy of the JRE we are
using and when heat gets to those DLLs it causes a pop up 7 times indicating
“Java Plug-in 1.5.0._07 is not installed properly”.  I
actually have this version of JDK installed on my system and use it with my
IDE’s and Tomcat.  Do I need the path to these DLLs in the
system’s path for heat not to complain?









From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 21, 2006
9:35 AM
To: Steven Chin;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll



 

Sorry, I was assuming that the problem
was that heat.exe wouldn't run because MSVCR80.DLL was missing, but I see that
Heat is a .NET Framework executable. I have to assume that you're trying to
include the Visual C Runtime in your package. You should ignore this dependency
from Heat.

 

The supported method of redistributing
the VS2005 C runtime within an MSI is to use a  element to
merge in the Microsoft_VC80_CR

Re: [WiX-users] heat cannot find MSVCR80.dll

[Steven Chin]

Thanks for the info Mike.  I think it
has more to do with the manifests in the DLLs and lack of manifests in some. 
If I remove a manifest from a DLL that has one of the VC80.CRT dependencies
then I will get more of these pop ups.  I know that I have 34 DLLs that
have VC80.CRT dependencies that don’t have manifests but if I try to add
the manifests to the DLLs I will get 54 pop up errors.  Because of this
problem I am going to try using tallow and the 2.0 tools.  Tallow has no
problems with the DLLS and their manifest or no manifests at this time.  Thanks
again.

 









From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 21, 2006
2:03 PM
To: Steven Chin; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll



 





Heat is trying to extract
self-registration information from the DLLs. To do this, it uses the
RegOverridePredefKey API to get a clean version of the HKEY_CURRENT_USER,
HKEY_LOCAL_MACHINE keys so that the actual machine environment isn't affected,
and to simplify working out what was written. It then calls the DLL's
DllSelfRegister entry point to get it to perform its self-registration to
the surrogate keys. From this it fills out the Class and Registry tables
as appropriate.





 





Unfortunately, these keys are completely clean, and various
self-registration code will fail if some other registry keys and values they
depend on are missing. Here, it's that the side-by-side code in the Windows
loader is looking for registry information about the side-by-side DLLs, and
failing to find it, and presumably that Sun's self-registration code is looking
for the same.





 





If you're shipping C++ DLLs you should know what the correct
GUIDs are for the classes and type libraries - they'll be in your source code
somewhere. Author this manually, don't use heat - that's for tools which
autogenerate GUIDs like VB6. Also, heat is something intended to be run once to
capture an initial script, it's not really meant for running on every build.





 





As for the Java runtime, if you're shipping it yourself, use
Sun's installer. Then Sun can service it correctly. Always ship third-party
components according to the developer's guidance. The component rules mean that
unless you're extremely careful, you'll end up breaking someone else's
application when yours is uninstalled.





 





(Hopefully third-time-lucky)





 





-- 





Mike Dimmick







 







From: Steven
Chin [mailto:[EMAIL PROTECTED]
Sent: Thu 21/09/2006 15:30
To: Mike Dimmick;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll





Hi Mike,

Heat runs but many of our DLLs in our
product have a manifest in them indicating this dependency.  I noticed
that we have at least a dozen DLLs with manifests requiring VC80.CRT"
version="8.0.50608.0 but the pop-up error saying it cannot find
MSVCR80.DLL only comes up 4 times.  Maybe it is something else.

 

We are not trying to include the Visual C
Runtime in our package.  How would we ignore this dependency from
Heat?  A pop up appears requiring user intervention and I am running heat
from a perl script so as to have the build be automated.

 

We are shipping a copy of the JRE we are
using and when heat gets to those DLLs it causes a pop up 7 times indicating
“Java Plug-in 1.5.0._07 is not installed properly”.  I
actually have this version of JDK installed on my system and use it with my
IDE’s and Tomcat.  Do I need the path to these DLLs in the
system’s path for heat not to complain?









From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 21, 2006
9:35 AM
To: Steven Chin;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll



 

Sorry, I was assuming that the problem
was that heat.exe wouldn't run because MSVCR80.DLL was missing, but I see that
Heat is a .NET Framework executable. I have to assume that you're trying to
include the Visual C Runtime in your package. You should ignore this dependency
from Heat.

 

The supported method of redistributing
the VS2005 C runtime within an MSI is to use a  element to
merge in the Microsoft_VC80_CRT_x86.msm merge module.

 

-- 

Mike Dimmick

 







From: Steven
Chin [mailto:[EMAIL PROTECTED] 
Sent: 21 September 2006 14:11
To: Mike Dimmick;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll

I checked and I do have that policy file
and but I don’t think the redirect is working.

 



 

heat still cannot find MSVCR80.DLL.

 









From: Mike Dimmick
[mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 21, 2006
4:51 AM
To: Steven Chin;
wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] heat
cannot find MSVCR80.dll



 

Yes, it does indeed do this. However,
you should have a publisher policy installed on your machine which redirects to
8.0.50727.42. I also have one which redirects to 8.0.50727.163. I'm running
Windows XP SP2 with all current 

[WiX-users] RE: Install service using unprivileged user

[Valery Drotenko]

Dear Albert Tuulas,

  Look at LsaAddAccountRights/LsaRemoveAccountRights WinAPI functions.

-- 
Best regards,
 Valery  mailto:[EMAIL PROTECTED]


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix V3 UI image substitution

[Mike Dimmick]

Having downloaded the latest weekly (3.0.2128.0), I can 
confirm that this seems to work - setting -dWixUILicenseRtf=License.rtf caused 
it to be picked up and used in the MSI.
 
-- 
Mike Dimmick


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Mike 
DimmickSent: 29 September 2006 17:26To: Graham D. Ambrose; 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Wix V3 UI 
image substitution

It looks like you need to add 
-dWixUILicenseRtf= to the light command line to 
change this variable. Right now I can't validate this as I have the 3.0.2015.0 
version installed and I can't build the SampleUI tutorial (gets LGHT0132 errors 
complaining that nothing's a valid assembly, even though the Assembly attribute 
isn't specified, which appears to be a problem in the latest stable unstable 
version if that makes sense!)
 
I worked this out by reading LicenseAgreementDlg.wxs in the 
source (in src\ext\UIExtension\wixlib) and working out how light actually 
processes these variables (it's in 
WixVariableResolver.ResolveVariables).
 
Changing the bitmaps is more circuitous; the bitmaps use a 
 from the (compiled) .wxl file that's embedded in the UIExtension. 
This sets each bitmap (marked 'overridable') to WixUI_Bmp_Banner. In Common.wxs 
(same folder as LicenseAgreementDlg.wxs) this is also set via a variable, to 
WixUIBannerBmp. Again, supply this on the command line to light, e.g. 

 
-dWixUIBannerBmp=
 
As I say, this is guesswork. I hope it unsticks 
you.
 
-- 
Mike Dimmick


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Graham D. 
AmbroseSent: 29 September 2006 09:23To: 
wix-users@lists.sourceforge.netSubject: [WiX-users] Wix V3 UI image 
substitution


I am trying to customise the 
standard Wix UI by including our own licence file and branded 
backgrounds.
 
I can not seem to be able to work 
out where to put my files in order to get them picked up. I am using Wix version 
3 and are happily building using the WixUIExtension. But all the examples of 
replacing the images etc that I have found are using Wix V2 and the wixui.wixlib 
file and the paths they suggest do not seem to 
work.
 
Can anyone explain how to achieve 
the substitution of the image files in WixUI
 
Many 
Thanks,
 
Graham
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Wix V3 UI image substitution

[Mike Dimmick]

It looks like you need to add 
-dWixUILicenseRtf= to the light command line to 
change this variable. Right now I can't validate this as I have the 3.0.2015.0 
version installed and I can't build the SampleUI tutorial (gets LGHT0132 errors 
complaining that nothing's a valid assembly, even though the Assembly attribute 
isn't specified, which appears to be a problem in the latest stable unstable 
version if that makes sense!)
 
I worked this out by reading LicenseAgreementDlg.wxs in the 
source (in src\ext\UIExtension\wixlib) and working out how light actually 
processes these variables (it's in 
WixVariableResolver.ResolveVariables).
 
Changing the bitmaps is more circuitous; the bitmaps use a 
 from the (compiled) .wxl file that's embedded in the UIExtension. 
This sets each bitmap (marked 'overridable') to WixUI_Bmp_Banner. In Common.wxs 
(same folder as LicenseAgreementDlg.wxs) this is also set via a variable, to 
WixUIBannerBmp. Again, supply this on the command line to light, e.g. 

 
-dWixUIBannerBmp=
 
As I say, this is guesswork. I hope it unsticks 
you.
 
-- 
Mike Dimmick


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Graham D. 
AmbroseSent: 29 September 2006 09:23To: 
wix-users@lists.sourceforge.netSubject: [WiX-users] Wix V3 UI image 
substitution


I am trying to customise the 
standard Wix UI by including our own licence file and branded 
backgrounds.
 
I can not seem to be able to work 
out where to put my files in order to get them picked up. I am using Wix version 
3 and are happily building using the WixUIExtension. But all the examples of 
replacing the images etc that I have found are using Wix V2 and the wixui.wixlib 
file and the paths they suggest do not seem to 
work.
 
Can anyone explain how to achieve 
the substitution of the image files in WixUI
 
Many 
Thanks,
 
Graham
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] hyper link in wix

[Leila Lali (Excell Data Corporation)]

Thanks Stefan,

I'm going to use IE, as my browser now and may be try to use default
browser later.

Thanks anyway
Leila

-Original Message-
From: Stefan Pavlik [mailto:[EMAIL PROTECTED] 
Sent: Thursday, September 28, 2006 11:52 PM
To: Leila Lali (Excell Data Corporation)
Cc: Bob Arnson; WiX-users
Subject: Re: [WiX-users] hyper link in wix

Hi Leila

I have tested this and it works.
Some disadvantage is that the console windows is visible for some
tims (cca 0.5 s).



I hope it will help you...

Stefan


Leila Lali (Excell Data Corporation) wrote:
> Yes it works. I've used Custom Action type 34 like this:
> 
>  
> 
>  ExeCommand='"[ProgramFilesFolder]Internet
> Explorer\iexplore.exe""http://www.live.com";' Directory='INSTALLDIR'
> Return="asyncNoWait" />
> 
>  
> 
> But it means that I can not use default browser?
> 
>  
> 
> Thanks
> 
> Leila
> 
>  
> 
>  
> 
>

> 
> *From:* Bob Arnson [mailto:[EMAIL PROTECTED]
> *Sent:* Tuesday, September 26, 2006 10:31 PM
> *To:* Leila Lali (Excell Data Corporation); WiX-users
> *Subject:* Re: [WiX-users] hyper link in wix
> 
>  
> 
> Please keep /wix-users/ on the thread.
> 
> Leila Lali (Excell Data Corporation) wrote:
> 
> Here is my code:
> 
>  
> 
> **
> 
> *   
> *  Root='HKCR' Key='http\shell\open\command' />*
> 
> **
> 
> * *
> 
> * ExeCommand='www.live.com ' Return='asyncNoWait'
/>*
> 
> * *
> 
> * Height="50" Cancel="yes"
> Text="{\HyperLinkStyle}$(loc.MsgDotNetFrameworkDependency)">*
> 
> **
> 
> **
> 
> **
> 
> * *
> 
> But it doesn't do anything. It can find default browser but nothing
> happened.
> 
> I didn't find anything like error in log file.
> 
> What value does BROWSER have? If IE is the default browser, it usually
> contains extra command-line parameters that won't work with a type 50
> custom action. You might want to try
CustomAction/@Directory,@ExeCommand
> -- that lets you pass the whole command line. But I'm not sure if
it'll
> work either -- the HKCR value generally contains placed arguments.
> 
> 
> --  
> 
> sig://boB
> 
> http://bobs.org
> 
> 
> 
> __ NOD32 1.1780 (20060927) Information __
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
>

> 
>

-
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the chance to
share your
> opinions on IT & business topics through brief surveys -- and earn
cash
>
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDE
V
> 
> __ NOD32 1.1780 (20060927) Information __
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 
> 
> 
>

> 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 
> __ NOD32 1.1780 (20060927) Information __
> 
> This message was checked by NOD32 antivirus system.
> http://www.eset.com
> 

-- 
Stefan Pavlik | [EMAIL PROTECTED]
Whitestein Technologies | www.whitestein.com
Panenska 28 | SK-81103 Bratislava | Slovak Republic
Tel +421(2)5930-0735 | Fax +421(2)5443-5512

-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Error setting target through command line

[Foster, Richard - PAL]

One other thing I would check for - make sure you don't 
have a custom action which is overriding what you specified from the 
command line. That bit me one time! :-)
 
Regards,
Richard


From: [EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew 
JanulewiczSent: Thursday, September 28, 2006 19:33To: Jeff 
MacDuff; wix-users@lists.sourceforge.netSubject: Re: [WiX-users] 
Error setting target through command line


Without seeing the code, I’d have to 
guess. But I think that private properties can’t be set or changed, only public. 
Public properties are always in all caps. Maybe the ProgramFilesFolder is taking 
precedent because it’s initially defined in TARGETDIR? As a test, compile and 
try the installer using a different variable (other than TARGETDIR) with a fixed 
local path that doesn’t use a system folder. Or change TARGETDIR to not include 
ProgramFilesFolder in it’s path. Then try to pass in “c:\temp” and see what 
happens.
 
 
-Matt
 




From: Jeff 
MacDuff [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 4:26 
PMTo: Matthew Janulewicz; 
wix-users@lists.sourceforge.netSubject: RE: [WiX-users] Error setting 
target through command line
 
Ok so that worked, if I 
do that syntax with the “” I see in the log file where the targetdir get’s set… 
however it still installs to the program files 
directory.
 
I then tried setting 
the ProgramFilesFolder to c:\temp.. again the logfile shows it being set but it 
still resolves the real one.
 
Is there a trick to 
making this work?
 
 




From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of Matthew JanulewiczSent: Thursday, September 28, 2006 4:06 
PMTo: Jeff MacDuff; 
wix-users@lists.sourceforge.netSubject: Re: [WiX-users] Error setting 
target through command line
 
Try this:
 
TARGETDIR=”c:\temp”
 
I can’t find any documentation to 
corroborate it, but all the auto-deployment scripts I have set public properties 
with quotes, even when there are no spaces or odd characters in it. I must have 
done that for some reason when I wrote them months and months ago, 
no?
 
 
-Matt
 




From: Jeff 
MacDuff [mailto:[EMAIL PROTECTED] Sent: Thursday, September 28, 2006 3:22 
PMTo: 
wix-users@lists.sourceforge.netSubject: [WiX-users] Error setting target 
through command line
 
I am trying to the TARGETDIR through 
the cmd line when running my MSI but it get’s completely ignored…. Some 
customers might need to overwrite the default value so they have requested this 
msiexec function to work.
 
The syntax I am using is msiexec /I 
foo.msi TARGETDIR=c:\temp
 
Is there any trick to getting this 
to work?
 
Thanks for the 
help,
Jeff 



* C O N F I D E N T I A L I T Y N O T I C E *
---
The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Peek Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer.




-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Launching a CHM

[Rob Mensching]

So does that mean you are writing it, Bob?  


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Thursday, September 28, 2006 18:49
To: Wilson, Phil
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Launching a CHM

Wilson, Phil wrote:
> If Wix actually
> has a built-in custom action that does a shell open on a file then it
> would work for probably all these situations, whether it's a URL, a text
> file, an RTF file, chm, mp3, wav, csv, and so on, and it would use the
> app that the user wanted, not that one that the setup author wanted.
>
Yep, exactly. That also solves the "default browser" problem nicely. WiX
doesn't have such a CA right now but it'd be easy to add...

--
sig://boB
http://bobs.org


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Launching a CHM

[Rob Mensching]

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson
Sent: Thursday, September 28, 2006 18:49
To: Wilson, Phil
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Launching a CHM

Wilson, Phil wrote:
> If Wix actually
> has a built-in custom action that does a shell open on a file then it
> would work for probably all these situations, whether it's a URL, a text
> file, an RTF file, chm, mp3, wav, csv, and so on, and it would use the
> app that the user wanted, not that one that the setup author wanted.
>
Yep, exactly. That also solves the "default browser" problem nicely. WiX
doesn't have such a CA right now but it'd be easy to add...

--
sig://boB
http://bobs.org


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Wix V3 UI image substitution

[Graham D. Ambrose]

I am trying to customise the standard Wix UI by including
our own licence file and branded backgrounds.

 

I can not seem to be able to work out where to put my files
in order to get them picked up. I am using Wix version 3 and are happily building
using the WixUIExtension. But all the examples of replacing the images etc that
I have found are using Wix V2 and the wixui.wixlib file and the paths they suggest
do not seem to work.

 

Can anyone explain how to achieve the substitution of the
image files in WixUI

 

Many Thanks,

 

Graham






-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Upgrade and remove

[Calin Iaru]

Hi Bob,

been there. I find that something similar is done with WinDbg. 
Thanks to all for helping out. Keep you posted.

Best regards,
Calin

Bob Arnson wrote:
> Calin Iaru wrote:
>> I see that MigrateFeatureStates discovers that the features are 
>> installed. Next, InstallValidate says that the feature is absent when 
>> the versions do not match (ie install with one MSI and uninstall with 
>> the other). RemoveExistingProducts is skipped in both cases (remove 
>> from different version and remove from same).
>>   
> Take a look at http://www.tramontana.co.hu/wix/lesson4.php for samples.
>


-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users