[WiX-users] Wix 3.0 to Wix 3.5 migration

[Venkat Narain]

Hi,

We recently migrated to VS2010 and so upgraded to 3.5. When we did so, we are 
getting an error for the following snippet with 3.5. Not sure how to fix 
it...Any ideas would be appreciated:

  
  
   
 
We got an error saying that it has Illegal characters in the path. How do we 
fix this?


thanks,
Venkat
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] User-Friendly Site-Specific Installation

[Christopher Painter]

There are ways in GPO but none of them are pretty.  Simplest might be to 
teach them to use policy to seed the registry with data then use 
AppSeach/RegLocator to pull that into properties. 


MSSCCM using Collection Variables / Task Sequence variables is more 
powerful and easier to use.



From: "David Cramlet" 

Sent: Friday, March 16, 2012 1:43 PM

To: wix-users@lists.sourceforge.net

Subject: [WiX-users] User-Friendly Site-Specific Installation


This may be more of a general Windows Installer question than a WiX 
question.


I have a deployment group asking if there is any way to make

site-specific installation any easier than the "msiexec command-line

magic" or "Orca voodoo" that transforms seem to require. Notably, this

is for sites that are not using GPO-style deployment, since Windows

takes care of applying the transforms in that case.


After some initial research, I am beginning to think the only other

options would be a transform-aware bootstrapper, or just building a

custom MSI for each site.


Since they always have exactly one transform for the product in

question, the first thing I (perhaps foolishly) tried was adding the

TRANSFORMS property to the Property table of the MSI, with a value

along the lines of "@SiteSpecific.mst" (with such an MST in the same

folder as the MSI). As you might expect, this (and various variations

thereof) had no discernible effect.


Any thoughts would be much appreciated.


Thank you,

David Cramlet

decram...@gmail.com



--

This SF email is sponsosred by:

Try Windows Azure free for 90 days Click Here 

http://p.sf.net/sfu/sfd2d-msazure

___

WiX-users mailing list

WiX-users@lists.sourceforge.net

https://lists.sourceforge.net/lists/listinfo/wix-users


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] User-Friendly Site-Specific Installation

[Dirk Räder]

2012/3/16 Castro, Edwin G. (Hillsboro) :
> I haven't had time to do this yet but I'll throw it over the wall and see if 
> anybody likes it as an idea.
>
> In my case, all of the data we might want to customize on a per-site basis is 
> exposed via public properties. I just need to provide the correct set of 
> command line arguments, one for each customized public property.
>
> I considered creating transforms to customize the values of these properties 
> allowing each site to generate their own transform but the process for 
> generating a transform seem rather difficult to me as you need the base 
> package and the end-result package to generate the transform I often ask 
> myself, if I have to create an end-result package anyway, then why not just 
> use it directly?
>
> Anyway, it makes a lot of sense in my case to build custom action that knows 
> how to parse an XML file (or some other data format) that can be specified on 
> the command line (similar to the TRANSFORMS property). The custom action 
> would need to run early enough to customize public properties before the rest 
> of the actions in the various sequences.
>
> I haven't looked into building this yet for our deployments because we 
> already have scripts that generate the appropriate command lines for us. I 
> have not use burn yet but would love to see something similar to this 
> available out-of-the-box without requiring a custom BA (I think that is what 
> is required today for a burn generated bootstrapper).
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> Please consider the environment before printing this e-mail
>
>
>> -Original Message-
>> From: David Cramlet [mailto:decram...@gmail.com]
>> Sent: Friday, March 16, 2012 11:41 AM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] User-Friendly Site-Specific Installation
>>
>> This may be more of a general Windows Installer question than a WiX
>> question.
>>
>> I have a deployment group asking if there is any way to make site-specific
>> installation any easier than the "msiexec command-line magic" or "Orca
>> voodoo" that transforms seem to require. Notably, this is for sites that are
>> not using GPO-style deployment, since Windows takes care of applying the
>> transforms in that case.
>>
>> After some initial research, I am beginning to think the only other options
>> would be a transform-aware bootstrapper, or just building a custom MSI for
>> each site.
>>
>> Since they always have exactly one transform for the product in question,
>> the first thing I (perhaps foolishly) tried was adding the TRANSFORMS
>> property to the Property table of the MSI, with a value along the lines of
>> "@SiteSpecific.mst" (with such an MST in the same folder as the MSI). As you
>> might expect, this (and various variations
>> thereof) had no discernible effect.
>>
>> Any thoughts would be much appreciated.
>>
>> Thank you,
>> David Cramlet
>> decram...@gmail.com
>>

Hi David, Edwin,

I'm doing something quite similar to that:
On update, a custom action reads out an environment variable and sets
the TARGETDIR. Other custom actions modify the transitions used in the
UI definitions by re-defining other properties.

So this way of reading data from a response file inside a custom
action works fine. But make sure to use sensible defaults / popup
decent error message if the response file is missing or corrupt.

Kind regards,

Dirk Räder

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] User-Friendly Site-Specific Installation

[Castro, Edwin G. (Hillsboro)]

I haven't had time to do this yet but I'll throw it over the wall and see if 
anybody likes it as an idea.

In my case, all of the data we might want to customize on a per-site basis is 
exposed via public properties. I just need to provide the correct set of 
command line arguments, one for each customized public property.

I considered creating transforms to customize the values of these properties 
allowing each site to generate their own transform but the process for 
generating a transform seem rather difficult to me as you need the base package 
and the end-result package to generate the transform I often ask myself, if 
I have to create an end-result package anyway, then why not just use it 
directly?

Anyway, it makes a lot of sense in my case to build custom action that knows 
how to parse an XML file (or some other data format) that can be specified on 
the command line (similar to the TRANSFORMS property). The custom action would 
need to run early enough to customize public properties before the rest of the 
actions in the various sequences.

I haven't looked into building this yet for our deployments because we already 
have scripts that generate the appropriate command lines for us. I have not use 
burn yet but would love to see something similar to this available 
out-of-the-box without requiring a custom BA (I think that is what is required 
today for a burn generated bootstrapper).

Edwin G. Castro
Software Developer - Staff
Digital Channels
Fiserv
Office: 503-746-0643
Fax: 503-617-0291
www.fiserv.com
Please consider the environment before printing this e-mail


> -Original Message-
> From: David Cramlet [mailto:decram...@gmail.com]
> Sent: Friday, March 16, 2012 11:41 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] User-Friendly Site-Specific Installation
> 
> This may be more of a general Windows Installer question than a WiX
> question.
> 
> I have a deployment group asking if there is any way to make site-specific
> installation any easier than the "msiexec command-line magic" or "Orca
> voodoo" that transforms seem to require. Notably, this is for sites that are
> not using GPO-style deployment, since Windows takes care of applying the
> transforms in that case.
> 
> After some initial research, I am beginning to think the only other options
> would be a transform-aware bootstrapper, or just building a custom MSI for
> each site.
> 
> Since they always have exactly one transform for the product in question,
> the first thing I (perhaps foolishly) tried was adding the TRANSFORMS
> property to the Property table of the MSI, with a value along the lines of
> "@SiteSpecific.mst" (with such an MST in the same folder as the MSI). As you
> might expect, this (and various variations
> thereof) had no discernible effect.
> 
> Any thoughts would be much appreciated.
> 
> Thank you,
> David Cramlet
> decram...@gmail.com
> 
> --
> This SF email is sponsosred by:
> Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-
> msazure ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] User-Friendly Site-Specific Installation

[David Cramlet]

This may be more of a general Windows Installer question than a WiX question.

I have a deployment group asking if there is any way to make
site-specific installation any easier than the "msiexec command-line
magic" or "Orca voodoo" that transforms seem to require. Notably, this
is for sites that are not using GPO-style deployment, since Windows
takes care of applying the transforms in that case.

After some initial research, I am beginning to think the only other
options would be a transform-aware bootstrapper, or just building a
custom MSI for each site.

Since they always have exactly one transform for the product in
question, the first thing I (perhaps foolishly) tried was adding the
TRANSFORMS property to the Property table of the MSI, with a value
along the lines of "@SiteSpecific.mst" (with such an MST in the same
folder as the MSI). As you might expect, this (and various variations
thereof) had no discernible effect.

Any thoughts would be much appreciated.

Thank you,
David Cramlet
decram...@gmail.com

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling

[Daniel Sniderman]

I didn't even have to do the logging.   I checked the properties for the old 
Installer and it did have   - so I added 
this to my WIX project.  Needless to say - it fixed the problem

-Original Message-
From: Wilson, Phil [mailto:phil.wil...@invensys.com] 
Sent: Friday, March 16, 2012 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Migration from VS Setup Project to WIX - not 
uninstalling

Doing the upgrade with a verbose log will tell you if it's finding the previous 
product. One gotcha when everything else looks correct is that the older 
install could have per user (or per system) and your upgrade is the opposite. 

Phil W 

-Original Message-
From: Daniel Sniderman [mailto:dani...@magenic.com]
Sent: Friday, March 16, 2012 9:47 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling

We are currently using a Visual Studio 2010 Setup project to generate the MSI 
for our application and I'm developing a replacement in WIX.  Currently - it's 
not uninstalling the previous (Visual Studio generated) installation.  I found 
a solution on Stack Overflow - but it's not working.
I used Orca to find the UpgradeCode for the previous installation and that is 
what I'm using

Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";>
  


  
  



  




Daniel P. Sniderman| Sr Consultant| Magenic MCSD.NET, MCTS: Team Foundation 
Server 2010 Administration

333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
Mobile: 847-668-4882  | eFax 847-390-7810 magenic.com | 
dani...@magenic.com


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here http://p.sf.net/sfu/sfd2d-msazure 
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx.

You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
recept...@invensys.com. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling

[Wilson, Phil]

Doing the upgrade with a verbose log will tell you if it's finding the previous 
product. One gotcha when everything else looks correct is that the older 
install could have per user (or per system) and your upgrade is the opposite. 

Phil W 

-Original Message-
From: Daniel Sniderman [mailto:dani...@magenic.com] 
Sent: Friday, March 16, 2012 9:47 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Migration from VS Setup Project to WIX - not uninstalling

We are currently using a Visual Studio 2010 Setup project to generate the MSI 
for our application and I'm developing a replacement in WIX.  Currently - it's 
not uninstalling the previous (Visual Studio generated) installation.  I found 
a solution on Stack Overflow - but it's not working.
I used Orca to find the UpgradeCode for the previous installation and that is 
what I'm using

Wix xmlns="http://schemas.microsoft.com/wix/2006/wi";>
  


  
  



  




Daniel P. Sniderman| Sr Consultant| Magenic
MCSD.NET, MCTS: Team Foundation Server 2010 Administration

333 E. Butterfield Rd. Suite 100, Lombard, IL 60148
Mobile: 847-668-4882  | eFax 847-390-7810
magenic.com | dani...@magenic.com


--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


*** Confidentiality Notice: This e-mail, including any associated or attached 
files, is intended solely for the individual or entity to which it is 
addressed. This e-mail is confidential and may well also be legally privileged. 
If you have received it in error, you are on notice of its status. Please 
notify the sender immediately by reply e-mail and then delete this message from 
your system. Please do not copy it or use it for any purposes, or disclose its 
contents to any other person. This email comes from a division of the Invensys 
Group, owned by Invensys plc, which is a company registered in England and 
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 
7AW (Registered number 166023). For a list of European legal entities within 
the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx.

You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail 
recept...@invensys.com. This e-mail and any attachments thereto may be subject 
to the terms of any agreements between Invensys (and/or its subsidiaries and 
affiliates) and the recipient (and/or its subsidiaries and affiliates).



--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting MsiLogFileLocation property

[Alec Swan]

session.Log seems to work fine, thanks. However, I can only see these
messages in the log file if I pass /l*v parameter to msiexec.

So, how do I write that bootstrapper that passes /l*v command line
parameter or an argument to MsiProductInstall() which enables logging?

Thanks,

Alec

On Fri, Mar 16, 2012 at 8:41 AM, Hoover, Jacob
 wrote:
> For .Net CA's there is a Log method on the session object. As for C/C+ custom 
> actions, the SDK provides a WcaLog(LOGMSG_STANDARD, "Message goes here.") 
> method.
>
> Both of these will write to the Windows installer log, if it's enabled.
>
> -Original Message-
> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
> Sent: Thursday, March 15, 2012 5:42 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>
> I use a second custom action called WriteToMSILog that I call at specific 
> times from my first custom action to log to the normal log file that 
> everything else writes to. Keeps everything in one log file and is easy to 
> call as needed.
>
> The CDATA portion looks like this (Jscript example)
>
> 
>
>
> The call from my first custom action looks like this
>
> Session.Property("WriteToMSILog") = "Process Name: " + pProps[proc];
> Session.DoAction("WriteToMSILog");
>
> -Original Message-
> From: Alec Swan [mailto:alecs...@gmail.com]
> Sent: Thursday, March 15, 2012 3:20 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>
> Wow, this is a pretty active mailing list. I think we have the
> definite answer now.
>
> As you can already tell I am a newbie to WIX, so please take it easy
> on me with my next question. What logging mechanism do you normally
> use to log messages from your custom actions?
>
> Thanks,
>
> Alec
>
> On Thu, Mar 15, 2012 at 12:58 PM, Castro, Edwin G. (Hillsboro)
>  wrote:
>> In addition, the Windows Installer engine starts producing log messages 
>> before it loads the MSI package to determine what log file to use.
>>
>> In short, one can set a log file:
>> * On the command line
>> * As an argument to MsiProductInstall()
>> * In the registry (global and applies to all MSI packages, cannot be changed 
>> on a per package basis)
>>
>> The MsiLogFileLocation property is automatically set by the Windows 
>> Installer engine to allow a MSI UI to display the log file location on a 
>> dialog. Changing the value of MsiLogFileLocation within the MSI package 
>> itself does not change where the Windows Installer engine is logging to (as 
>> evidenced by the tests performed by various people).
>>
>> To automatically set a log file you'll need to use a bootstrapper as was 
>> already suggested so that the bootstrapper can set it on the command line or 
>> as an argument to MsiProductInstall().
>>
>> Your system administrator could use the registry approach to control whether 
>> all MSI packages generate a log file to a specific folder location with a 
>> random: MSI*.LOG name.
>>
>> This is documented in the MSDN documentation so if anybody wants to use this 
>> approach I suggest they check MSDN at 
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx
>>
>> Edwin G. Castro
>> Software Developer - Staff
>> Digital Channels
>> Fiserv
>> Office: 503-746-0643
>> Fax: 503-617-0291
>> www.fiserv.com
>> Please consider the environment before printing this e-mail
>>
>>
>>
>>> -Original Message-
>>> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
>>> Sent: Thursday, March 15, 2012 11:22 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>>>
>>> A good test anyone can try. Run a command something like this.
>>>
>>> MSIEXEC.EXE /L*v C:\Foobar\test.log /I 
>>>
>>> For that log folder that you point to make sure the C:\Foobar directly DOES
>>> NOT EXIST.
>>>
>>> Note how MSIEXEC.EXE will simply error out rather than creating the Foobar
>>> folder in which to create the log file.
>>>
>>> I feel this shows an example of what Edwin and others are talking about. Log
>>> file must be established before MSIEXEC calls into the MSI.
>>>
>>> -Original Message-
>>> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
>>> Sent: Thursday, March 15, 2012 11:10 AM
>>> To: General discussion for Windows Installer XML toolset.
>>> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>>>
>>> WiX is not in control of the MsiLogFileLocation property. This is 
>>> functionality
>>> provided by Windows Installer.
>>>
>>> As mentioned earlier, the log file location must be set before the MSI
>>> package is loaded by the Windows Installer engine. This is how Windows
>>> Installer works and the WiX team has no control over it.
>>>
>>> Please refer to http://msdn.microsoft.com/en-
>>> us/library/windows/desktop/aa372847.aspx for information on Windows
>>> Installer Logging. 

Re: [WiX-users] Setting MsiLogFileLocation property

[Hoover, Jacob]

For .Net CA's there is a Log method on the session object. As for C/C+ custom 
actions, the SDK provides a WcaLog(LOGMSG_STANDARD, "Message goes here.") 
method.

Both of these will write to the Windows installer log, if it's enabled.

-Original Message-
From: Chad Petersen [mailto:chad.peter...@harlandfs.com] 
Sent: Thursday, March 15, 2012 5:42 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property

I use a second custom action called WriteToMSILog that I call at specific times 
from my first custom action to log to the normal log file that everything else 
writes to. Keeps everything in one log file and is easy to call as needed.

The CDATA portion looks like this (Jscript example)




The call from my first custom action looks like this

Session.Property("WriteToMSILog") = "Process Name: " + pProps[proc];
Session.DoAction("WriteToMSILog");

-Original Message-
From: Alec Swan [mailto:alecs...@gmail.com] 
Sent: Thursday, March 15, 2012 3:20 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Setting MsiLogFileLocation property

Wow, this is a pretty active mailing list. I think we have the
definite answer now.

As you can already tell I am a newbie to WIX, so please take it easy
on me with my next question. What logging mechanism do you normally
use to log messages from your custom actions?

Thanks,

Alec

On Thu, Mar 15, 2012 at 12:58 PM, Castro, Edwin G. (Hillsboro)
 wrote:
> In addition, the Windows Installer engine starts producing log messages 
> before it loads the MSI package to determine what log file to use.
>
> In short, one can set a log file:
> * On the command line
> * As an argument to MsiProductInstall()
> * In the registry (global and applies to all MSI packages, cannot be changed 
> on a per package basis)
>
> The MsiLogFileLocation property is automatically set by the Windows Installer 
> engine to allow a MSI UI to display the log file location on a dialog. 
> Changing the value of MsiLogFileLocation within the MSI package itself does 
> not change where the Windows Installer engine is logging to (as evidenced by 
> the tests performed by various people).
>
> To automatically set a log file you'll need to use a bootstrapper as was 
> already suggested so that the bootstrapper can set it on the command line or 
> as an argument to MsiProductInstall().
>
> Your system administrator could use the registry approach to control whether 
> all MSI packages generate a log file to a specific folder location with a 
> random: MSI*.LOG name.
>
> This is documented in the MSDN documentation so if anybody wants to use this 
> approach I suggest they check MSDN at 
> http://msdn.microsoft.com/en-us/library/windows/desktop/aa372847.aspx
>
> Edwin G. Castro
> Software Developer - Staff
> Digital Channels
> Fiserv
> Office: 503-746-0643
> Fax: 503-617-0291
> www.fiserv.com
> Please consider the environment before printing this e-mail
>
>
>
>> -Original Message-
>> From: Chad Petersen [mailto:chad.peter...@harlandfs.com]
>> Sent: Thursday, March 15, 2012 11:22 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>>
>> A good test anyone can try. Run a command something like this.
>>
>> MSIEXEC.EXE /L*v C:\Foobar\test.log /I 
>>
>> For that log folder that you point to make sure the C:\Foobar directly DOES
>> NOT EXIST.
>>
>> Note how MSIEXEC.EXE will simply error out rather than creating the Foobar
>> folder in which to create the log file.
>>
>> I feel this shows an example of what Edwin and others are talking about. Log
>> file must be established before MSIEXEC calls into the MSI.
>>
>> -Original Message-
>> From: Castro, Edwin G. (Hillsboro) [mailto:edwin.cas...@fiserv.com]
>> Sent: Thursday, March 15, 2012 11:10 AM
>> To: General discussion for Windows Installer XML toolset.
>> Subject: Re: [WiX-users] Setting MsiLogFileLocation property
>>
>> WiX is not in control of the MsiLogFileLocation property. This is 
>> functionality
>> provided by Windows Installer.
>>
>> As mentioned earlier, the log file location must be set before the MSI
>> package is loaded by the Windows Installer engine. This is how Windows
>> Installer works and the WiX team has no control over it.
>>
>> Please refer to http://msdn.microsoft.com/en-
>> us/library/windows/desktop/aa372847.aspx for information on Windows
>> Installer Logging. In particular check the Normal Logging  section at
>> http://msdn.microsoft.com/en-us/library/windows/desktop/aa370536.aspx
>> for an explanation of your options.
>>
>> Edwin G. Castro
>> Software Developer - Staff
>> Digital Channels
>> Fiserv
>> Office: 503-746-0643
>> Fax: 503-617-0291
>> www.fiserv.com
>> P Please consider the environment before printing this e-mail
>>
>>
>>
>> > -Original Message-
>> > From: Alec Swan [mailto:alecs...@gmail.com]
>> > Sent: Thursday, March 15,

Re: [WiX-users] condition test using ScreenX property not working

[McDuffie, Andy]

I'm trying to have my installer copy one of two different files depending on 
the screen resolution of the install host by testing the ScreenX property in a 
condition element.  However, using the code below the statement 
ScreenX="1024" ALWAYS evaluates as true, regardless of 
the actual resolution of the host.  ScreenX="800" NEVER 
evaluates as true even on a host whose screen is actually 800x600

If you uncomment the bits of code below pertaining to "scrnxtest", rebuild and 
run the installer, and then run "echo %SCRNXVAL%" in a terminal you will find 
that the value of ScreenX at the point at which that code executes is ALWAYS 
1024!

Can anyone explain why this is happening?  It seemed like such a dead-simple 
task, but I've now lost a couple of hours of my life trying to make this work 
without success.

Any insight would be much appreciated

Andy



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






  
  
  
  

  

  

  

  

  

  

  
  
ScreenX="800"

  
  
ScreenX="1024"

  

  




--
This SF email is sponsosred by:
Try Windows Azure free for 90 days Click Here 
http://p.sf.net/sfu/sfd2d-msazure
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users