Re: [WiX-users] MSI returns 1606 Could not access location

2007-11-01 Thread Davut Karabay
Are you saying that TARGETDIR should not be set to 
\\wmiscratch\scratch\davut\DaRT? But that's where software was installed 
right?. Installer should be setting it internally. My problem is; if the share 
become unavailable then there seems to be no way out. Can't uninstall or 
repair, or install on top of existing.


From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL 
PROTECTED]: Thu, 1 Nov 2007 14:50:41 -0700Subject: RE: [WiX-users] MSI returns 
1606 Could not access location






MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. 
Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery 
Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'.
 
This line seems to me to be the primary reason. TARGETDIR is the location where 
the software has been installed. It seems to me that it can’t erase it out of 
the network share if the network share doesn’t exist.
 
The MSDN docs say that KB886549 can also produce 1606 errors 
(http://support.microsoft.com/kb/886549/en-us). But, instead I think it is 
something wrong in your directory table and/or passed in command-line values.
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut 
KarabaySent: Thursday, November 01, 2007 2:28 PMTo: Rob MenschingCc: [EMAIL 
PROTECTED]: Re: [WiX-users] MSI returns 1606 Could not access location
 
Hi Rob - Thank you for your reply. Do you mean I require network share to exist 
during uninstall (in the WIX code)? Isn't that a requirement by MSI which I 
don't have control over? Here is the log. I couldn't understand anything useful 
other than error code. ...Id start 13:48:25: CostFinalize.MSI (c) (4C:38) 
[13:48:25:747]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is 
'0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace 
property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: 
Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.MSI (c) (4C:38) 
[13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. 
Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceRemaining property. Its value is '0'.MSI (c) (4C:38) 
[13:48:25:762]: Note: 1: 2205 2:  3: MsiAssembly MSI (c) (4C:38) 
[13:48:25:762]: Note: 1: 2228 2:  3: MsiAssembly 4:  SELECT 
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, 
`MsiAssembly`.`File_Manifest`,  `Component`.`KeyPath` FROM `MsiAssembly`, 
`Component` WHERE  `MsiAssembly`.`Component_` = `Component`.`Component` AND 
`MsiAssembly`.`Component_` = ? MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: 
Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft 
Diagnostics and Recovery Toolset'. Its new value: 
'\\wmiscratch\scratch\davut\DaRT'.MSI (c) (4C:38) [13:48:25:825]: PROPERTY 
CHANGE: Adding enUS property. Its value is 
'\\wmiscratch\scratch\davut\DaRT\en-us'.MSI (c) (4C:38) [13:48:25:840]: Note: 
1: 2205 2:  3: Patch MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2:  3: 
Condition MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding 
MSDARTShortCuts property. Its value is 
'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft 
Diagnostics and Recovery Toolset\'.MSI (c) (4C:38) [13:48:25:903]: Note: 1: 
1314 2: \\wmiscratch\scratch\davut\DaRT MSI (c) (4C:38) [13:48:25:903]: Note: 
1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network 
location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:637]: 
Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could 
not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) 
[13:48:31:652]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. 
Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) 
(4C:38) [13:48:32:909]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 
-- Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.Id ended 13:48:32: CostFinalize. Return value 
3Thanks,Davut



> Date: Wed, 31 Oct 2007 11:35:43 -0700> From: [EMAIL PROTECTED]> To: [EMAIL 
> PROTECTED]> CC: wix-users@lists.sourceforge.net> Subject: Re: [WiX-users] MSI 
> returns 1606 Could not access location> > This happens if your MSI requires 
> the original source media for some > reason during uninstall. Usually, it's 
> some coding error that causes > this problem. Look in the verbose log file 
> and see what is causing the > source prompt.> > Davut Karabay wrote:> > Hi,> 
> >> > I run my insaller (e.g. msiexec /i XYZ.msi). Select a network path to 
> install (e.g. \\somecomputer\someshare\installdir). Product is installed with 
> success. Now delete the network path. Run the installer again. It returns 
> 1606 saying that could not access the network location. Installer is stuck. 
> Can't uninstall or repair. Is this by design? Can I handle it differently?> 
> >> > Thanks,> > Davut> > 
>

Re: [WiX-users] Font definition and WXL

2007-11-01 Thread Eric Baudouin
Not a bad suggestion:)

Paul would you mind to have  a look at this, in case the linker is case 
sensitive.

Thank you.

E.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 4:59 PM
To: Eric Baudouin
Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Font definition and WXL


Ok... It also appears that your error message says 'Facename' (lowercase 'N'), 
but your declaration shows an uppercase.  Not sure if it matters, just thought 
I'd mention it since I noticed it.

Kelly


Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

11/01/2007 04:44 PM

To

Kelly Leahy <[EMAIL PROTECTED]>

cc

"[EMAIL PROTECTED]" <[EMAIL PROTECTED]>, Paul Houldridge <[EMAIL PROTECTED]>, 
"wix-users@lists.sourceforge.net" 

Subject

Re: [WiX-users] Font definition and WXL







Here is the answer from Paul, so it look like syntaxically speaking we were 
doing the right thing.
So I think we need to focus more on the methodology. Thank you anyway for your 
reply.

No luck.  Using the ! instead of the $ is right.  $ is deprecated.

.\SetupUI.wix(26) : warning LGHT1073 : The localization variable 
$(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'.  Please use the 
'!' prefix instead.  Since the prefix '$' is also used by the preprocessor, it 
has been deprecated to avoid namespace collisions.
warnings in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The 
localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix 
'$'.  Please use the '!' prefix instead.  Since the prefix '$' is also used by 
the preprocessor, it has been deprecated to avoid namespace collisions.
.\SetupUI.wix(26) : error LGHT0102 : The localization variable 
!(loc.BannerTextStyle_Facename) is unknown.  Please ensure the variable is 
defined.
errors in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The 
localization variable !(loc.BannerTextStyle_Facename) is unknown.  Please 
ensure the variable is defined.
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code 
'0x66'
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code 
'0x66'
Stop.


From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 4:31 PM
To: Eric Baudouin
Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Font definition and WXL


Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)?

Kelly
Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

11/01/2007 04:17 PM


To

"wix-users@lists.sourceforge.net" 

cc

Paul Houldridge <[EMAIL PROTECTED]>

Subject

[WiX-users] Font definition and WXL











Hello,

We have moved our resource to a wxl file to facilitate the localization of our 
component.
In the localization world it is a good practice to make sure that the font size 
and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well so 
that the localization team could change it accordingly, since the font size and 
the font facename are different for the Japanese, or any far-east languages.


Unfortunately as you can see down below replacing the font attribute with the 
WXL loc ID causes the compiler to break, because the preprocessor might run 
some validation because linked the loc data in the code.

Would you have a different approach we could use so that at least we have a 
work-around.

Thank you very much.

E.




MS Sans Serif
 12
 yes

Then within my  tag I have:
 

The error I get indicates that the !(loc.name) syntax does not work within the 
attributes for TextStyle.  The loc variables are not getting processed into the 
defined values.  This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The 
TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is not a 
legal integer value.  Legal integer values are from -2,147,483,648 to 
2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : The 
TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is not a 
legal yes/no value.  The only legal value is 'no' or 'yes'.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> 
http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This commun

Re: [WiX-users] Font definition and WXL

2007-11-01 Thread Kelly Leahy
Ok... It also appears that your error message says 'Facename' (lowercase 
'N'), but your declaration shows an uppercase.  Not sure if it matters, 
just thought I'd mention it since I noticed it.

Kelly




Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
11/01/2007 04:44 PM

To
Kelly Leahy <[EMAIL PROTECTED]>
cc
"[EMAIL PROTECTED]" 
<[EMAIL PROTECTED]>, Paul Houldridge 
<[EMAIL PROTECTED]>, "wix-users@lists.sourceforge.net" 

Subject
Re: [WiX-users] Font definition and WXL






Here is the answer from Paul, so it look like syntaxically speaking we 
were doing the right thing.
So I think we need to focus more on the methodology. Thank you anyway for 
your reply.
 
No luck.  Using the ! instead of the $ is right.  $ is deprecated.
 
.\SetupUI.wix(26) : warning LGHT1073 : The localization variable 
$(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'.  Please use 
the '!' prefix instead.  Since the prefix '$' is also used by the 
preprocessor, it has been deprecated to avoid namespace collisions.
warnings in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : 
The localization variable $(loc.BannerTextStyle_Facename) uses a 
deprecated prefix '$'.  Please use the '!' prefix instead.  Since the 
prefix '$' is also used by the preprocessor, it has been deprecated to 
avoid namespace collisions.
.\SetupUI.wix(26) : error LGHT0102 : The localization variable 
!(loc.BannerTextStyle_Facename) is unknown.  Please ensure the variable is 
defined.
errors in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : 
The localization variable !(loc.BannerTextStyle_Facename) is unknown. 
Please ensure the variable is defined.
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return 
code '0x66'
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return 
code '0x66'
Stop.
 
 
From: Kelly Leahy [mailto:[EMAIL PROTECTED] 
Sent: Thursday, November 01, 2007 4:31 PM
To: Eric Baudouin
Cc: Paul Houldridge; wix-users@lists.sourceforge.net; 
[EMAIL PROTECTED]
Subject: Re: [WiX-users] Font definition and WXL
 

Don't you want $(loc.BannerTextStyle_Size) not 
!(loc.BannerTextStyle_Size)? 

Kelly 



Eric Baudouin <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED] 
11/01/2007 04:17 PM 


To
"wix-users@lists.sourceforge.net"  
cc
Paul Houldridge <[EMAIL PROTECTED]> 
Subject
[WiX-users] Font definition and WXL
 








 Hello, 
  
We have moved our resource to a wxl file to facilitate the localization of 
our component. 
In the localization world it is a good practice to make sure that the font 
size and the font facename can be localized. 
I was hoping that I could move the font style attribute in the WXL as well 
so that the localization team could change it accordingly, since the font 
size and the font facename are different for the Japanese, or any far-east 
languages. 
  
  
Unfortunately as you can see down below replacing the font attribute with 
the WXL loc ID causes the compiler to break, because the preprocessor 
might run some validation because linked the loc data in the code. 
  
Would you have a different approach we could use so that at least we have 
a work-around. 
  
Thank you very much. 
  
E. 
  
  
  
  
 MS Sans 
Serif 
  12 
  yes 
  
Then within my  tag I have: 
   
  
The error I get indicates that the !(loc.name) syntax does not work within 
the attributes for TextStyle.  The loc variables are not getting processed 
into the defined values.  This is the error I get: 
errors in directory c:\harmonica\sql\sync\src\setup\core 
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : 
The TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is 
not a legal integer value.  Legal integer values are from -2,147,483,648 
to 2,147,483,647. 
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : 
The TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is 
not a legal yes/no value.  The only legal value is 'no' or 'yes'. 
  
 -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> 
http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not const

Re: [WiX-users] Font definition and WXL

2007-11-01 Thread Eric Baudouin
Here is the answer from Paul, so it look like syntaxically speaking we were 
doing the right thing.
So I think we need to focus more on the methodology. Thank you anyway for your 
reply.

No luck.  Using the ! instead of the $ is right.  $ is deprecated.

.\SetupUI.wix(26) : warning LGHT1073 : The localization variable 
$(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'.  Please use the 
'!' prefix instead.  Since the prefix '$' is also used by the preprocessor, it 
has been deprecated to avoid namespace collisions.
warnings in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The 
localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix 
'$'.  Please use the '!' prefix instead.  Since the prefix '$' is also used by 
the preprocessor, it has been deprecated to avoid namespace collisions.
.\SetupUI.wix(26) : error LGHT0102 : The localization variable 
!(loc.BannerTextStyle_Facename) is unknown.  Please ensure the variable is 
defined.
errors in directory c:\drs_sync_1\sql\sync\src\setup\core
c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The 
localization variable !(loc.BannerTextStyle_Facename) is unknown.  Please 
ensure the variable is defined.
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code 
'0x66'
NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code 
'0x66'
Stop.


From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 4:31 PM
To: Eric Baudouin
Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Font definition and WXL


Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)?

Kelly


Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

11/01/2007 04:17 PM

To

"wix-users@lists.sourceforge.net" 

cc

Paul Houldridge <[EMAIL PROTECTED]>

Subject

[WiX-users] Font definition and WXL







 Hello,

We have moved our resource to a wxl file to facilitate the localization of our 
component.
In the localization world it is a good practice to make sure that the font size 
and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well so 
that the localization team could change it accordingly, since the font size and 
the font facename are different for the Japanese, or any far-east languages.


Unfortunately as you can see down below replacing the font attribute with the 
WXL loc ID causes the compiler to break, because the preprocessor might run 
some validation because linked the loc data in the code.

Would you have a different approach we could use so that at least we have a 
work-around.

Thank you very much.

E.




 MS Sans Serif
  12
  yes

Then within my  tag I have:
  

The error I get indicates that the !(loc.name) syntax does not work within the 
attributes for TextStyle.  The loc variables are not getting processed into the 
defined values.  This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The 
TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is not a 
legal integer value.  Legal integer values are from -2,147,483,648 to 
2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : The 
TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is not a 
legal yes/no value.  The only legal value is 'no' or 'yes'.

 -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> 
http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or
opinions upon which reliance may be made by the addressee or any
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries
guidelines.
**
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to fi

Re: [WiX-users] start and stop services

2007-11-01 Thread shapla

Thanks a lot. You are right. I was using the display name and so it was not
working. It is now working with the correct service name.

Again thanks!


Richard-45 wrote:
> 
> 
> In article <[EMAIL PROTECTED]>,
> shapla <[EMAIL PROTECTED]>  writes:
> 
>> I checked it in Orca. I see that it has the correct name in service
>> control
>> table. 
>> Other values are as below:
>> Event=2
>> Wait=1  
> 
> How do you know that the name is correct?
> 
> For instance, to manipulate the COM remote procedure call service
> using this table, you must use "RPCSS" (the name is case insensitive),
> but if you do "net start" it will list as "Remote Procedure Call
> (RPC)", which is its display name, not its service name.  You have to
> use the service name in the ServiceControl table.
> -- 
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
>   
> 
> Legalize Adulthood! 
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 
> 

-- 
View this message in context: 
http://www.nabble.com/start-and-stop-services-tf4715721.html#a13539717
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Font definition and WXL

2007-11-01 Thread Eric Baudouin
Let me check with Paul, this might simply explains why the variables were not 
replaced.

Thank you.

E.

From: Kelly Leahy [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 4:31 PM
To: Eric Baudouin
Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED]
Subject: Re: [WiX-users] Font definition and WXL


Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)?

Kelly


Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]

11/01/2007 04:17 PM

To

"wix-users@lists.sourceforge.net" 

cc

Paul Houldridge <[EMAIL PROTECTED]>

Subject

[WiX-users] Font definition and WXL







 Hello,

We have moved our resource to a wxl file to facilitate the localization of our 
component.
In the localization world it is a good practice to make sure that the font size 
and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well so 
that the localization team could change it accordingly, since the font size and 
the font facename are different for the Japanese, or any far-east languages.


Unfortunately as you can see down below replacing the font attribute with the 
WXL loc ID causes the compiler to break, because the preprocessor might run 
some validation because linked the loc data in the code.

Would you have a different approach we could use so that at least we have a 
work-around.

Thank you very much.

E.




 MS Sans Serif
  12
  yes

Then within my  tag I have:
  

The error I get indicates that the !(loc.name) syntax does not work within the 
attributes for TextStyle.  The loc variables are not getting processed into the 
defined values.  This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The 
TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is not a 
legal integer value.  Legal integer values are from -2,147,483,648 to 
2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : The 
TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is not a 
legal yes/no value.  The only legal value is 'no' or 'yes'.

 -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> 
http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or
opinions upon which reliance may be made by the addressee or any
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries
guidelines.
**
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Font definition and WXL

2007-11-01 Thread Kelly Leahy
Don't you want $(loc.BannerTextStyle_Size) not 
!(loc.BannerTextStyle_Size)?

Kelly




Eric Baudouin <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
11/01/2007 04:17 PM

To
"wix-users@lists.sourceforge.net" 
cc
Paul Houldridge <[EMAIL PROTECTED]>
Subject
[WiX-users] Font definition and WXL






 Hello,
 
We have moved our resource to a wxl file to facilitate the localization of 
our component.
In the localization world it is a good practice to make sure that the font 
size and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well 
so that the localization team could change it accordingly, since the font 
size and the font facename are different for the Japanese, or any far-east 
languages.
 
 
Unfortunately as you can see down below replacing the font attribute with 
the WXL loc ID causes the compiler to break, because the preprocessor 
might run some validation because linked the loc data in the code.
 
Would you have a different approach we could use so that at least we have 
a work-around.
 
Thank you very much.
 
E.
 
 
 
 
 MS Sans 
Serif
  12
  yes
 
Then within my  tag I have:
  
 
The error I get indicates that the !(loc.name) syntax does not work within 
the attributes for TextStyle.  The loc variables are not getting processed 
into the defined values.  This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : 
The TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is 
not a legal integer value.  Legal integer values are from -2,147,483,648 
to 2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : 
The TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is 
not a legal yes/no value.  The only legal value is 'no' or 'yes'.
 
 -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Common virtual directory for multiple products

2007-11-01 Thread Kelly Leahy
It doesn't look to me like there's a way to do this, but I don't know 
anything about WiX's support for IIS.

Hopefully somebody else will recommend.

Kelly




Rolando <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
11/01/2007 04:00 PM

To
Kelly Leahy <[EMAIL PROTECTED]>
cc
[EMAIL PROTECTED], wix-users@lists.sourceforge.net
Subject
Re: [WiX-users] Common virtual directory for multiple products






Thank you for your reply,
I've tried this before but it doesn't work, because is not possible to add 
a reference from the children web directories to the common web directory.

Is there any way to add a reference to an existing web directory?

Kelly Leahy wrote: 

I don't know anything about using MSI to install virtual directories, but 
I think the solution is to put your 'shared' parent directory in a 
component that is used by all of your applications, using the same 
ComponentGuid.  Then, only the 'first' application installed will add the 
directory, and only the 'last' application removed will remove it. 

However, I'm not sure how to do this. 

good luck. 

Kelly 



Rolando <[EMAIL PROTECTED]> 

Sent by: [EMAIL PROTECTED] 
11/01/2007 11:57 AM 


To
wix-users@lists.sourceforge.net 
cc

Subject
[WiX-users] Common virtual directory for multiple products








Hi, I have five products, each one of them creates one or more virtual 
directories. I need to put all this virtual directories inside a common 
virtual directory.

ie.
  Default Web Site
 |-[My product line]
  |-ProductOne
  |-ProductTwo
  ...
  |-Product N

the code I'm using to create each virtual directory looks like this

  
  
   
  
  
   ...
  
  
  
  

When I install the products everything works as desired, but if I 
uninstall one product, the common virtual directory is removed and the 
other products virtual directories can not be accessed (Obviously)

Do you have any suggestion?
Thanks,
Rolando


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**
 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourc

[WiX-users] Font definition and WXL

2007-11-01 Thread Eric Baudouin
 Hello,

We have moved our resource to a wxl file to facilitate the localization of our 
component.
In the localization world it is a good practice to make sure that the font size 
and the font facename can be localized.
I was hoping that I could move the font style attribute in the WXL as well so 
that the localization team could change it accordingly, since the font size and 
the font facename are different for the Japanese, or any far-east languages.


Unfortunately as you can see down below replacing the font attribute with the 
WXL loc ID causes the compiler to break, because the preprocessor might run 
some validation because linked the loc data in the code.

Would you have a different approach we could use so that at least we have a 
work-around.

Thank you very much.

E.




 MS Sans Serif
  12
  yes

Then within my  tag I have:
  

The error I get indicates that the !(loc.name) syntax does not work within the 
attributes for TextStyle.  The loc variables are not getting processed into the 
defined values.  This is the error I get:
errors in directory c:\harmonica\sql\sync\src\setup\core
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The 
TextStyle/@Size attribute's value, '!(loc.BannerTextStyle_Size)', is not a 
legal integer value.  Legal integer values are from -2,147,483,648 to 
2,147,483,647.
c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0015 : The 
TextStyle/@Bold attribute's value, '!(loc.BannerTextStyle_Bold)', is not a 
legal yes/no value.  The only legal value is 'no' or 'yes'.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Davut Karabay
Rob, Peter, Blair and Chad - Thank you guys all for the help. Turns out I 
haven't changed Package/@Id. Now it is working as charm! Thanks a lot.Davut

> Date: Thu, 1 Nov 2007 15:49:24 -0700> From: [EMAIL PROTECTED]> To: [EMAIL 
> PROTECTED]> CC: wix-users@lists.sourceforge.net> Subject: Re: [WiX-users] How 
> to prevent cached msi being invoked (not asking msiexec /fv)> > Can you share 
> the before and after values for:> > Product/@Id> Product/@UpgradeCode> 
> Package/@Id> > What version of the WiX toolset are you using?> > Davut 
> Karabay wrote:> > Hi,> > > > When I run the new version of installer, it 
> invokes the installed old > > version. I don't want that happen. I want the 
> new version installed > > anyway. How can I break the link between the new 
> and the old? I > > changed Product ID GUID but it didn't help. Using Launch 
> Conditions do > > not help because old version is invoked. Here I am not 
> asking "msiexec > > /fv". My users will likely run the installer by double 
> clicking.> > > > Thanks,> > Davut> >> > 
> > > 
> Boo! Scare away worms, viruses and so much more! Try Windows Live > > 
> OneCare! Try now! > > 
> 
>  > >> > 
> > >> 
> > -> 
> > This SF.net email is sponsored by: Splunk Inc.> > Still grepping through 
> log files to find problems? Stop.> > Now Search log events and configuration 
> files using AJAX and a browser.> > Download your FREE copy of Splunk now >> 
> http://get.splunk.com/> > 
> > >> 
> > ___> > WiX-users mailing list> 
> > WiX-users@lists.sourceforge.net> > 
> https://lists.sourceforge.net/lists/listinfo/wix-users> > 
_
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Common virtual directory for multiple products

2007-11-01 Thread Rolando

Thank you for your reply,
I've tried this before but it doesn't work, because is not possible to 
add a reference from the children web directories to the common web 
directory.


Is there any way to add a reference to an existing web directory?

Kelly Leahy wrote:


I don't know anything about using MSI to install virtual directories, 
but I think the solution is to put your 'shared' parent directory in a 
component that is used by all of your applications, using the same 
ComponentGuid.  Then, only the 'first' application installed will add 
the directory, and only the 'last' application removed will remove it.


However, I'm not sure how to do this.

good luck.

Kelly



*Rolando <[EMAIL PROTECTED]>*

Sent by: [EMAIL PROTECTED]

11/01/2007 11:57 AM


To
wix-users@lists.sourceforge.net
cc

Subject
[WiX-users] Common virtual directory for multiple products









Hi, I have five products, each one of them creates one or more virtual
directories. I need to put all this virtual directories inside a common
virtual directory.

ie.
  Default Web Site
 |-[My product line]
  |-ProductOne
  |-ProductTwo
  ...
  |-Product N

the code I'm using to create each virtual directory looks like this

  
  
   
  
  
   ...
  
  
  
  

When I install the products everything works as desired, but if I
uninstall one product, the common virtual directory is removed and the
other products virtual directories can not be accessed (Obviously)

Do you have any suggestion?
Thanks,
Rolando


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure,
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or
opinions upon which reliance may be made by the addressee or any
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries
guidelines.
** 



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Rob Mensching
Can you share the before and after values for:

Product/@Id
Product/@UpgradeCode
Package/@Id

What version of the WiX toolset are you using?

Davut Karabay wrote:
> Hi,
>  
> When I run the new version of installer, it invokes the installed old 
> version. I don't want that happen. I want the new version installed 
> anyway. How can I break the link between the new and the old? I 
> changed Product ID GUID but it didn't help. Using Launch Conditions do 
> not help because old version is invoked. Here I am not asking "msiexec 
> /fv". My users will likely run the installer by double clicking.
>  
> Thanks,
> Davut
>
> 
> Boo! Scare away worms, viruses and so much more! Try Windows Live 
> OneCare! Try now! 
> 
>  
>
> 
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> 
>
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>   

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Finding existing IIS websites and virtual directories

2007-11-01 Thread Rob Mensching
Sadly, not supported yet.  It's one of those features I wish was 
implemented.

Marc Scheuner wrote:
> Is there a way in WiX / Windows Installer to get a dialog that will show the 
> currently available IIS web sites, and the currently defined virtual 
> directories inside each web site, so that I can pick a web site / virtual 
> directory as my installation target directory?? 
>
> Also, I'd like to be able to install to the location of that virtual 
> directory WITHOUT changing anything for that virtual directory (no changes to 
> virtual dir or its permissions etc.) during or after installation. Can I do 
> that?
>
> Thanks!
> Marc
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>   

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Peter Marcu
Note that Package ID and ProductCode are different. One is on the Package 
element and should always change, one is on the Product element and should 
change with each release.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 2:54 PM
To: Chad Petersen; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)

That was the first thing I did, changing both product id and upgrade code. But 
still invokes the cached msi. I think I will give another try because everyone 
suggests it will work.

By the way please bare with me on installers :). It is one of the things that I 
inherited recently.




Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)
Date: Thu, 1 Nov 2007 14:38:33 -0700
From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Peter is suggesting you change your Product Id="GUID". I think you might want 
to also consider changing the UpgradeCode="GUID" also for future ease of 
upgrading one product versus the other, but it really depends on what your 
ultimate goal is.


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 2:31 PM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)

Hi Peter - What do you mean by changing the product code?


From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Date: Thu, 1 Nov 2007 13:47:35 -0700
Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)
Change the product code.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 1:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)



Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec 
/fv)
From: Richard <[EMAIL PROTECTED]> - 2007-11-01 19:47

In article <[EMAIL PROTECTED]>,
Davut Karabay <[EMAIL PROTECTED]> writes:

> When I run the new version of installer, it invokes the installed old versi=
> on. I don't want that happen. I want the new version installed anyway.

Why?
--


Because new version of the product is completely different from old one 
(apparently except the installer). Set of features, targeted platforms are 
different. So, it makes sense to me that new one does not invoke old cache. 
Specific scenario is this:

--Old version is installed on XP
--New version has launch conditions to install only on Vista
--Try installing new version on XP (to test that it won't install)
--New version invokes old cache. Launch conditions won't even run.

Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try 
now!


Windows Live Hotmail and Microsoft Office Outlook - together at last. Get it 
now!


Climb to the top of the charts!  Play Star Shuffle:  the word scramble 
challenge with star power. Play 
Now!
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Davut Karabay
That was the first thing I did, changing both product id and upgrade code. But 
still invokes the cached msi. I think I will give another try because everyone 
suggests it will work.
 
By the way please bare with me on installers :). It is one of the things that I 
inherited recently.


Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)Date: Thu, 1 Nov 2007 14:38:33 -0700From: [EMAIL PROTECTED]: [EMAIL 
PROTECTED]; wix-users@lists.sourceforge.net








Peter is suggesting you change your Product Id=”GUID”. I think you might want 
to also consider changing the UpgradeCode=”GUID” also for future ease of 
upgrading one product versus the other, but it really depends on what your 
ultimate goal is.
 




From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut 
KarabaySent: Thursday, November 01, 2007 2:31 PMTo: Peter Marcu; [EMAIL 
PROTECTED]: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)
 
Hi Peter - What do you mean by changing the product code?



From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: Thu, 1 Nov 2007 
13:47:35 -0700Subject: RE: [WiX-users] How to prevent cached msi being invoked 
(not asking msiexec /fv)

Change the product code.
 


From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut 
KarabaySent: Thursday, November 01, 2007 1:40 PMTo: [EMAIL PROTECTED]: Re: 
[WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)
 




 







Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)
From: Richard <[EMAIL PROTECTED]> - 2007-11-01 19:47


In article <[EMAIL PROTECTED]>,Davut Karabay <[EMAIL PROTECTED]> writes:> When 
I run the new version of installer, it invokes the installed old versi=> on. I 
don't want that happen. I want the new version installed anyway.Why?-- 

Because new version of the product is completely different from old one 
(apparently except the installer). Set of features, targeted platforms are 
different. So, it makes sense to me that new one does not invoke old cache. 
Specific scenario is this: --Old version is installed on XP--New version has 
launch conditions to install only on Vista--Try installing new version on XP 
(to test that it won't install)--New version invokes old cache. Launch 
conditions won't even run.



Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try 
now!
 



Windows Live Hotmail and Microsoft Office Outlook – together at last. Get it 
now!
_
Climb to the top of the charts!  Play Star Shuffle:  the word scramble 
challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not askingmsiexec /fv)

2007-11-01 Thread Blair Murri
Is your new package id different than the old one? Almost no one should ever 
explicitly set the package id. They should always have it autogenerated 
instead. (http://msdn2.microsoft.com/library/aa370568.aspx)

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 2:34 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not 
askingmsiexec /fv)

I generated a real GUID (package id) :). But that didn't work. It still invokes 
the cache. Do you think it shouldn't?


Re: [WiX-users] How to prevent cached msi being invoked (not askingmsiexec 
/fv)
From: Hugues Valois <[EMAIL PROTECTED]> - 2007-11-01 21:03

Attachments: Message as 
HTML

Did you forget to change the package id? Or use
---- to have a package id generated
automatically by Wix.

=20

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Davut
Karabay
Sent: Thursday, November 01, 2007 12:41 PM
To: [EMAIL PROTECTED]
Subject: [WiX-users] How to prevent cached msi being invoked (not
askingmsiexec /fv)

=20

Hi,
=20
When I run the new version of installer, it invokes the installed old
version. I don't want that happen. I want the new version installed
anyway. How can I break the link between the new and the old? I changed
Product ID GUID but it didn't help. Using Launch Conditions do not help
because old version is invoked. Here I am not asking "msiexec /fv". My
users will likely run the installer by double clicking.
=20
Thanks,
Davut




Peek-a-boo FREE Tricks & Treats for You! Get 
'em!
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] MSI returns 1606 Could not access location

2007-11-01 Thread Blair Murri
MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. 
Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery 
Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'.

This line seems to me to be the primary reason. TARGETDIR is the location where 
the software has been installed. It seems to me that it can't erase it out of 
the network share if the network share doesn't exist.

The MSDN docs say that KB886549 can also produce 1606 errors 
(http://support.microsoft.com/kb/886549/en-us). But, instead I think it is 
something wrong in your directory table and/or passed in command-line values.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 2:28 PM
To: Rob Mensching
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] MSI returns 1606 Could not access location

Hi Rob - Thank you for your reply. Do you mean I require network share to exist 
during uninstall (in the WIX code)? Isn't that a requirement by MSI which I 
don't have control over? Here is the log. I couldn't understand anything useful 
other than error code.

...
Id start 13:48:25: CostFinalize.
MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfDiskSpace 
property. Its value is '0'.
MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace 
property. Its value is '0'.
MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceAvailable property. Its value is '0'.
MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceRequired property. Its value is '0'.
MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceRemaining property. Its value is '0'.
MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2205 2:  3: MsiAssembly
MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2228 2:  3: MsiAssembly 4:  SELECT 
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, 
`MsiAssembly`.`File_Manifest`,  `Component`.`KeyPath` FROM `MsiAssembly`, 
`Component` WHERE  `MsiAssembly`.`Component_` = `Component`.`Component` AND 
`MsiAssembly`.`Component_` = ?
MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. 
Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery 
Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'.
MSI (c) (4C:38) [13:48:25:825]: PROPERTY CHANGE: Adding enUS property. Its 
value is '\\wmiscratch\scratch\davut\DaRT\en-us'.
MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2:  3: Patch
MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2:  3: Condition
MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding MSDARTShortCuts 
property. Its value is 'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start 
Menu\Programs\Microsoft Diagnostics and Recovery Toolset\'.
MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1314 2: 
\\wmiscratch\scratch\davut\DaRT
MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1606 2: 
\\wmiscratch\scratch\davut\DaRT
Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.
MSI (c) (4C:38) [13:48:31:637]: Product: Microsoft Diagnostics and Recovery 
Toolset 6.0 -- Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.
MSI (c) (4C:38) [13:48:31:652]: Note: 1: 1606 2: 
\\wmiscratch\scratch\davut\DaRT
Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.
MSI (c) (4C:38) [13:48:32:909]: Product: Microsoft Diagnostics and Recovery 
Toolset 6.0 -- Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.
Id ended 13:48:32: CostFinalize. Return value 3.
...

Thanks,
Davut


> Date: Wed, 31 Oct 2007 11:35:43 -0700
> From: [EMAIL PROTECTED]
> To: [EMAIL PROTECTED]
> CC: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] MSI returns 1606 Could not access location
>
> This happens if your MSI requires the original source media for some
> reason during uninstall. Usually, it's some coding error that causes
> this problem. Look in the verbose log file and see what is causing the
> source prompt.
>
> Davut Karabay wrote:
> > Hi,
> >
> > I run my insaller (e.g. msiexec /i XYZ.msi). Select a network path to 
> > install (e.g. \\somecomputer\someshare\installdir). Product is installed 
> > with success. Now delete the network path. Run the installer again. It 
> > returns 1606 saying that could not access the network location. Installer 
> > is stuck. Can't uninstall or repair. Is this by design? Can I handle it 
> > differently?
> >
> > Thanks,
> > Davut
> > _
> > Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
> > http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews
> > -
> > This SF.net email is sponsored by: Splunk Inc.
> > Still grepping through log files to find problems? Stop.
> > Now Search log events and c

Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Chad Petersen
Peter is suggesting you change your Product Id="GUID". I think you might
want to also consider changing the UpgradeCode="GUID" also for future
ease of upgrading one product versus the other, but it really depends on
what your ultimate goal is.

 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Davut
Karabay
Sent: Thursday, November 01, 2007 2:31 PM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not
asking msiexec /fv)

 

Hi Peter - What do you mean by changing the product code?






From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Date: Thu, 1 Nov 2007 13:47:35 -0700
Subject: RE: [WiX-users] How to prevent cached msi being invoked (not
asking msiexec /fv)

Change the product code.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Davut
Karabay
Sent: Thursday, November 01, 2007 1:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not
asking msiexec /fv)

 

 

Re: [WiX-users] How to prevent cached msi being invoked (not asking
msiexec /fv)
 

From: Richard <[EMAIL PROTECTED]> - 2007-11-01 19:47

In article <[EMAIL PROTECTED]>,
Davut Karabay <[EMAIL PROTECTED]> writes:

> When I run the new version of installer, it invokes the installed old
versi=
> on. I don't want that happen. I want the new version installed anyway.

Why?
-- 

Because new version of the product is completely different from old one
(apparently except the installer). Set of features, targeted platforms
are different. So, it makes sense to me that new one does not invoke old
cache. Specific scenario is this:
 
--Old version is installed on XP
--New version has launch conditions to install only on Vista
--Try installing new version on XP (to test that it won't install)
--New version invokes old cache. Launch conditions won't even run.



Boo! Scare away worms, viruses and so much more! Try Windows Live
OneCare! Try now!
 

 



Windows Live Hotmail and Microsoft Office Outlook - together at last.
Get it now!
 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Changing the default installation directory

2007-11-01 Thread Luis Mejia
On 11/1/07, 0x001A4 <[EMAIL PROTECTED]> wrote:
>
> How would I go about changing the default installation directory from Program
> Files to the C:\ or whatever drive the user has windows installed on?

Your Directory structure probably looks something like this:


  

   .

  


You could replace the 2nd Id for "WindowsVolume"... but then again the
documentation says you shouldn't use that. I don't know why. You can
always give it a try.

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Peter Marcu
>From the msi documentation: "The ProductCode property is a unique identifier 
>for the particular product release"

It sounded to me like you have a completely separate release so you should 
change the ProductCode property of the MSI. This is set by the Product/@Id 
attribute in WiX.

From: Davut Karabay [mailto:[EMAIL PROTECTED]
Sent: Thursday, November 01, 2007 2:31 PM
To: Peter Marcu; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)

Hi Peter - What do you mean by changing the product code?



From: [EMAIL PROTECTED]
To: [EMAIL PROTECTED]; wix-users@lists.sourceforge.net
Date: Thu, 1 Nov 2007 13:47:35 -0700
Subject: RE: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)
Change the product code.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 1:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec 
/fv)
From: Richard <[EMAIL PROTECTED]> - 2007-11-01 19:47

In article <[EMAIL PROTECTED]>,
Davut Karabay <[EMAIL PROTECTED]> writes:

> When I run the new version of installer, it invokes the installed old versi=
> on. I don't want that happen. I want the new version installed anyway.

Why?
--


Because new version of the product is completely different from old one 
(apparently except the installer). Set of features, targeted platforms are 
different. So, it makes sense to me that new one does not invoke old cache. 
Specific scenario is this:

--Old version is installed on XP
--New version has launch conditions to install only on Vista
--Try installing new version on XP (to test that it won't install)
--New version invokes old cache. Launch conditions won't even run.

Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try 
now!


Windows Live Hotmail and Microsoft Office Outlook - together at last. Get it 
now!
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not askingmsiexec /fv)

2007-11-01 Thread Davut Karabay
I generated a real GUID (package id) :). But that didn't work. It still invokes 
the cache. Do you think it shouldn't?
 











Re: [WiX-users] How to prevent cached msi being invoked (not askingmsiexec 
/fv)From: Hugues Valois <[EMAIL PROTECTED]> - 2007-11-01 21:03Attachments: 
Message as HTML  

Did you forget to change the package id? Or 
use---- to have a package id 
generatedautomatically by Wix.=20From: [EMAIL PROTECTED]:[EMAIL PROTECTED] On 
Behalf Of DavutKarabaySent: Thursday, November 01, 2007 12:41 PMTo: [EMAIL 
PROTECTED]: [WiX-users] How to prevent cached msi being invoked 
(notaskingmsiexec /fv)=20Hi,=20When I run the new version of installer, it 
invokes the installed oldversion. I don't want that happen. I want the new 
version installedanyway. How can I break the link between the new and the old? 
I changedProduct ID GUID but it didn't help. Using Launch Conditions do not 
helpbecause old version is invoked. Here I am not asking "msiexec /fv". Myusers 
will likely run the installer by double clicking.=20Thanks,Davut
_
Peek-a-boo FREE Tricks & Treats for You!
http://www.reallivemoms.com?ocid=TXT_TAGHM&loc=us-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] MSI returns 1606 Could not access location

2007-11-01 Thread Davut Karabay
Hi Rob - Thank you for your reply. Do you mean I require network share to exist 
during uninstall (in the WIX code)? Isn't that a requirement by MSI which I 
don't have control over? Here is the log. I couldn't understand anything useful 
other than error code.
 
...Id start 13:48:25: CostFinalize.MSI (c) (4C:38) [13:48:25:747]: PROPERTY 
CHANGE: Adding OutOfDiskSpace property. Its value is '0'.MSI (c) (4C:38) 
[13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value 
is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceAvailable property. Its value is '0'.MSI (c) (4C:38) 
[13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. 
Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding 
PrimaryVolumeSpaceRemaining property. Its value is '0'.MSI (c) (4C:38) 
[13:48:25:762]: Note: 1: 2205 2:  3: MsiAssembly MSI (c) (4C:38) 
[13:48:25:762]: Note: 1: 2228 2:  3: MsiAssembly 4:  SELECT 
`MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, 
`MsiAssembly`.`File_Manifest`,  `Component`.`KeyPath` FROM `MsiAssembly`, 
`Component` WHERE  `MsiAssembly`.`Component_` = `Component`.`Component` AND 
`MsiAssembly`.`Component_` = ? MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: 
Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft 
Diagnostics and Recovery Toolset'. Its new value: 
'\\wmiscratch\scratch\davut\DaRT'.MSI (c) (4C:38) [13:48:25:825]: PROPERTY 
CHANGE: Adding enUS property. Its value is 
'\\wmiscratch\scratch\davut\DaRT\en-us'.MSI (c) (4C:38) [13:48:25:840]: Note: 
1: 2205 2:  3: Patch MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2:  3: 
Condition MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding 
MSDARTShortCuts property. Its value is 
'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft 
Diagnostics and Recovery Toolset\'.MSI (c) (4C:38) [13:48:25:903]: Note: 1: 
1314 2: \\wmiscratch\scratch\davut\DaRT MSI (c) (4C:38) [13:48:25:903]: Note: 
1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network 
location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:637]: 
Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could 
not access network location \\wmiscratch\scratch\davut\DaRT.
MSI (c) (4C:38) [13:48:31:652]: Note: 1: 1606 2: 
\\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location 
\\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:32:909]: Product: 
Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access 
network location \\wmiscratch\scratch\davut\DaRT.
Id ended 13:48:32: CostFinalize. Return value 3Thanks,Davut



> Date: Wed, 31 Oct 2007 11:35:43 -0700> From: [EMAIL PROTECTED]> To: [EMAIL 
> PROTECTED]> CC: wix-users@lists.sourceforge.net> Subject: Re: [WiX-users] MSI 
> returns 1606 Could not access location> > This happens if your MSI requires 
> the original source media for some > reason during uninstall. Usually, it's 
> some coding error that causes > this problem. Look in the verbose log file 
> and see what is causing the > source prompt.> > Davut Karabay wrote:> > Hi,> 
> >> > I run my insaller (e.g. msiexec /i XYZ.msi). Select a network path to 
> install (e.g. \\somecomputer\someshare\installdir). Product is installed with 
> success. Now delete the network path. Run the installer again. It returns 
> 1606 saying that could not access the network location. Installer is stuck. 
> Can't uninstall or repair. Is this by design? Can I handle it differently?> 
> >> > Thanks,> > Davut> > 
> _> > Boo! 
> Scare away worms, viruses and so much more! Try Windows Live OneCare!> > 
> http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews>
>  > -> 
> > This SF.net email is sponsored by: Splunk Inc.> > Still grepping through 
> log files to find problems? Stop.> > Now Search log events and configuration 
> files using AJAX and a browser.> > Download your FREE copy of Splunk now >> 
> http://get.splunk.com/> > ___> > 
> WiX-users mailing list> > WiX-users@lists.sourceforge.net> > 
> https://lists.sourceforge.net/lists/listinfo/wix-users> >> > 
_
Climb to the top of the charts!  Play Star Shuffle:  the word scramble 
challenge with star power.
http://club.live.com/star_shuffle.aspx?icid=starshuffle_wlmailtextlink_oct-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing 

Re: [WiX-users] How to prevent cached msi being invoked (not askingmsiexec /fv)

2007-11-01 Thread Hugues Valois
Did you forget to change the package id?  Or use
---- to have a package id generated
automatically by Wix.

 

From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Davut
Karabay
Sent: Thursday, November 01, 2007 12:41 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to prevent cached msi being invoked (not
askingmsiexec /fv)

 

Hi,
 
When I run the new version of installer, it invokes the installed old
version. I don't want that happen. I want the new version installed
anyway. How can I break the link between the new and the old? I changed
Product ID GUID but it didn't help. Using Launch Conditions do not help
because old version is invoked. Here I am not asking "msiexec /fv". My
users will likely run the installer by double clicking.
 
Thanks,
Davut



Boo! Scare away worms, viruses and so much more! Try Windows Live
OneCare! Try now!
 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Peter Marcu
Change the product code.

From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay
Sent: Thursday, November 01, 2007 1:40 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] How to prevent cached msi being invoked (not asking 
msiexec /fv)


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec 
/fv)
From: Richard <[EMAIL PROTECTED]> - 2007-11-01 19:47

In article <[EMAIL PROTECTED]>,
Davut Karabay <[EMAIL PROTECTED]> writes:

> When I run the new version of installer, it invokes the installed old versi=
> on. I don't want that happen. I want the new version installed anyway.

Why?
--


Because new version of the product is completely different from old one 
(apparently except the installer). Set of features, targeted platforms are 
different. So, it makes sense to me that new one does not invoke old cache. 
Specific scenario is this:

--Old version is installed on XP
--New version has launch conditions to install only on Vista
--Try installing new version on XP (to test that it won't install)
--New version invokes old cache. Launch conditions won't even run.

Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! Try 
now!
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Finding existing IIS websites and virtual directories

2007-11-01 Thread Marc Scheuner
Is there a way in WiX / Windows Installer to get a dialog that will show the 
currently available IIS web sites, and the currently defined virtual 
directories inside each web site, so that I can pick a web site / virtual 
directory as my installation target directory?? 

Also, I'd like to be able to install to the location of that virtual directory 
WITHOUT changing anything for that virtual directory (no changes to virtual dir 
or its permissions etc.) during or after installation. Can I do that?

Thanks!
Marc


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Disk Usage dialog values

2007-11-01 Thread Brian Simoneau
Where does the disk usage dialog get the values to put into the table?
The selection tree in the custom setup dialog indicates that the install
requires 68 MB, but in the disk usage dialog it says that 159 MB are
required on the drive.  I would expect these values to be the same.

Brian Simoneau
Software Developer
Freedom Scientific


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Crystal Reports modules not registering files

2007-11-01 Thread Pedro Ferreira
Hello Richard, thank you for your help.

I will try to include the SelfRegModules action and test it on a
virtual machine, and see if that solves the problem.

Do you know where can I get the Crystal Reports runtime MSI packages?
We are using  version XI, and in the crystal page, I can only find
MSIs for version 2008. Do you know if newer versions include support
for previous versions? I know this is not wix related, but I can't
seem to find this information on Crystal site, so any help on this
would be highly appreciated.

Best regards,

Pedro Ferreira

On 11/1/07, [EMAIL PROTECTED]
<[EMAIL PROTECTED]> wrote:
> Pedro,
>
> My first recommendation would be to use a bootstrapper and the Crystal
> reports runtime MSI file instead of the merge modules. The merge modules
> are IMHO almost useless, not to mention the fact that if you use WiX 3
> you'll have to turn off verification because the CR merge modules have
> so many things that cause ICE warnings.
>
> If that is not an option for you, the most likely reason for the problem
> is that you don't have all the necessary actions in your
> InstallExecuteSequence. Specifically, at least according to comments in
> some code I used before switching away from the merge modules, you will
> need to include the SelfRegModules and SelfUnregModules actions.
>
> Good luck!
> Richard
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Pedro
> Ferreira
> Sent: Wednesday, October 31, 2007 8:21 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Crystal Reports modules not registering files
>
> Hi,
>
> I'm fairly new to wix, and I'm trying to deploy the Crystal Reports
> runtime with my application.
>
> I'm inserting the crystal modules as shown here:
> http://pastebin.com/f286f6c04
>
> The problem is that although the Crystal Reports files are copied to
> the right directories in the target machine, some or most files are
> not registered.
>
> Tried to create a setup project using Visual Studio 2005, and added
> the modules to the project, and there, everything works fine, with all
> files being registered. So I think the problem is with my wix source
> files.
>
> Could someone please give me some tips? I'm getting lost here.
>
> Thanks,
>
> Pedro Ferreira
>
> 
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
>
>
> * 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. Quixote 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.
>
>
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Richard

In article <[EMAIL PROTECTED]>,
Davut Karabay <[EMAIL PROTECTED]>  writes:

> When I run the new version of installer, it invokes the installed old versi=
> on. I don't want that happen. I want the new version installed anyway.

Why?
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Common virtual directory for multiple products

2007-11-01 Thread Kelly Leahy
I don't know anything about using MSI to install virtual directories, but 
I think the solution is to put your 'shared' parent directory in a 
component that is used by all of your applications, using the same 
ComponentGuid.  Then, only the 'first' application installed will add the 
directory, and only the 'last' application removed will remove it.

However, I'm not sure how to do this.

good luck.

Kelly




Rolando <[EMAIL PROTECTED]>

Sent by: [EMAIL PROTECTED]
11/01/2007 11:57 AM

To
wix-users@lists.sourceforge.net
cc

Subject
[WiX-users] Common virtual directory for multiple products






Hi, I have five products, each one of them creates one or more virtual 
directories. I need to put all this virtual directories inside a common 
virtual directory.

ie.
   Default Web Site
  |-[My product line]
   |-ProductOne
   |-ProductTwo
   ...
   |-Product N

the code I'm using to create each virtual directory looks like this

   
   

   
   
...
   
   
   
   

When I install the products everything works as desired, but if I 
uninstall one product, the common virtual directory is removed and the 
other products virtual directories can not be accessed (Obviously)

Do you have any suggestion?
Thanks,
Rolando


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users




**
This communication is intended solely for the addressee and is
confidential. If you are not the intended recipient, any disclosure, 
copying, distribution or any action taken or omitted to be taken in
reliance on it, is prohibited and may be unlawful.  Unless indicated
to the contrary: it does not constitute professional advice or 
opinions upon which reliance may be made by the addressee or any 
other party, and it should be considered to be a work in progress.
Unless stated otherwise, this communication does not form a prescribed
statement of actuarial opinion under American Academy of Actuaries 
guidelines.
**-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] How to prevent cached msi being invoked (not asking msiexec /fv)

2007-11-01 Thread Davut Karabay
Hi,
 
When I run the new version of installer, it invokes the installed old version. 
I don't want that happen. I want the new version installed anyway. How can I 
break the link between the new and the old? I changed Product ID GUID but it 
didn't help. Using Launch Conditions do not help because old version is 
invoked. Here I am not asking "msiexec /fv". My users will likely run the 
installer by double clicking.
 
Thanks,Davut
_
Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare!
http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Common virtual directory for multiple products

2007-11-01 Thread Rolando
Hi, I have five products, each one of them creates one or more virtual 
directories. I need to put all this virtual directories inside a common 
virtual directory.

ie.
   Default Web Site
  |-[My product line]
   |-ProductOne
   |-ProductTwo
   ...
   |-Product N

the code I'm using to create each virtual directory looks like this

   
   

   
   
...
   
   
   
   

When I install the products everything works as desired, but if I 
uninstall one product, the common virtual directory is removed and the 
other products virtual directories can not be accessed (Obviously)

Do you have any suggestion?
Thanks,
Rolando


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Uninstall removing edited files

2007-11-01 Thread Richard

In article <[EMAIL PROTECTED]>,
Adam Majer <[EMAIL PROTECTED]>  writes:

> Huh? Hacky is allowing files to be modified in install locations.

Agreed, but you can't "fix" everything.  Attempting to modify files in
the installed program location is likely to break on a highly locked
down Windows installation (i.e. Vista) as well as you mention.

What you list are definately the best practices, but how many times
have you had developers push back on best practices because the
counsel is coming from an installation developer?  Its sad, its
pathetic, but its also very common.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] WixVsExtension and help registration bug

2007-11-01 Thread Simon Dahlbacka
Hi,

I'm still trying to register my help2 files, and if I use the
WixVSExtension I end up with the same problem as described in bug
1588180

If I follow do it the manual way according to
http://msdn2.microsoft.com/en-us/library/bb164959(VS.80).aspx it
works, if I decompile this msi then I once again end up with the same
problems as the above mentioned bug.

Is there a workaround, or is it just not possible to register help
files using the VSExtension right now?

regards,

Simon

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Crystal Reports modules not registering files

2007-11-01 Thread Richard.Foster
Pedro,

My first recommendation would be to use a bootstrapper and the Crystal
reports runtime MSI file instead of the merge modules. The merge modules
are IMHO almost useless, not to mention the fact that if you use WiX 3
you'll have to turn off verification because the CR merge modules have
so many things that cause ICE warnings.

If that is not an option for you, the most likely reason for the problem
is that you don't have all the necessary actions in your
InstallExecuteSequence. Specifically, at least according to comments in
some code I used before switching away from the merge modules, you will
need to include the SelfRegModules and SelfUnregModules actions.

Good luck!
Richard

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Pedro
Ferreira
Sent: Wednesday, October 31, 2007 8:21 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Crystal Reports modules not registering files

Hi,

I'm fairly new to wix, and I'm trying to deploy the Crystal Reports
runtime with my application.

I'm inserting the crystal modules as shown here:
http://pastebin.com/f286f6c04

The problem is that although the Crystal Reports files are copied to
the right directories in the target machine, some or most files are
not registered.

Tried to create a setup project using Visual Studio 2005, and added
the modules to the project, and there, everything works fine, with all
files being registered. So I think the problem is with my wix source
files.

Could someone please give me some tips? I'm getting lost here.

Thanks,

Pedro Ferreira


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



* 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. Quixote 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.



-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Uninstall removing edited files

2007-11-01 Thread Adam Majer
Richard wrote:
> In article <[EMAIL PROTECTED]>,
> Craig0ss <[EMAIL PROTECTED]>  writes:
> 
>> Basically my installer installs certain standard letters for use with the
>> software, if i change the standard letter to incorperate client specific
>> details and then uninstall the product the modified file is removed, is
>> there a way to check if the file has been modified and do not delete it on
>> uninstall?
> 
> The way I've dealt with this was to run a custom action that copies
> the files to a backup before the upgrade install transaction begins,
> i.e. the CA was immediate and sequenced before InstallInitialize.
> 
> Its kinda hacky; I'd rather that Windows Installer not remove modified
> files during an upgrade, but I can see how that would be problematic
> to get right in all circumstances.

Huh? Hacky is allowing files to be modified in install locations. I'm
mostly from Linux distributions when it comes to this but,

  1. installer must never install in user modifiable folders for system
wide installs
  2. installer must not modify user settings - only system settings
(unless user install, of course).
  3. software must store modifications in user folders and in user
accessible locations (registry), unless it is some system software that
stores global changes, then it must not just overwrite the default,
install data.
  4. install locations should not be overwritten by user actions from
within the program no matter if installed as system or user.


There are other areas too, like not removing user configurations when
uninstalling software. Most Windows installation people would do users a
favour by following rules that are common in UNIX world.

I think Vista is starts to enforce this more than older versions of
Windows - finally Windows version that makes sense in terms of
user/system/install defaults.

- Adam

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Uninstall removing edited files

2007-11-01 Thread Richard

In article <[EMAIL PROTECTED]>,
Craig0ss <[EMAIL PROTECTED]>  writes:

> Basically my installer installs certain standard letters for use with the
> software, if i change the standard letter to incorperate client specific
> details and then uninstall the product the modified file is removed, is
> there a way to check if the file has been modified and do not delete it on
> uninstall?

The way I've dealt with this was to run a custom action that copies
the files to a backup before the upgrade install transaction begins,
i.e. the CA was immediate and sequenced before InstallInitialize.

Its kinda hacky; I'd rather that Windows Installer not remove modified
files during an upgrade, but I can see how that would be problematic
to get right in all circumstances.
-- 
"The Direct3D Graphics Pipeline" -- DirectX 9 draft available for download
  

Legalize Adulthood! 

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] CAQuietExec custom action - launching 64-bit exe

2007-11-01 Thread David Ward
I'm  learning WiX and have been experimenting with a 64-bit install package for 
Vista64  During the install, I would like to run a 64-bit configuration tool.  
I can successfully launch the tool with a normal MSI custom action.  

However, when I try to launch the 64-bit exe silently using the WixCA 
CAQuietExec, it doesn't work.  From the log files, it looks like the 32-bit 
custom action server is started and it fails to execute the 64-bit exe.  Which 
makes sense, I don't think a WOW 32-bit process can launch a 64-bit exe.  I'm 
thinking I need a 64-bit version of WixCA CAQuietExec.  Does this exist?  Are 
there other options?  

Example XML: 





  

 



Log File output:

MSI (s) (C8:28) [05:19:32:984]: Executing op: ActionStart(Name=AddCfg64,,)
MSI (s) (C8:28) [05:19:33:000]: Executing op: 
CustomActionSchedule(Action=AddCfg64,ActionType=3073,Source=BinaryData,Target=CAQuietExec,CustomActionData="c:\Windows\system32\CfgTool.exe")
MSI (s) (C8:F4) [05:19:33:015]: Invoking remote custom action. DLL: 
C:\Windows\Installer\MSIE0B8.tmp, Entrypoint: CAQuietExec
MSI (s) (C8:A0) [05:19:33:015]: Generating random cookie.
MSI (s) (C8:A0) [05:19:33:015]: Created Custom Action Server with PID 2324 
(0x914).
MSI (s) (C8:0C) [05:19:34:187]: Running as a service.
MSI (s) (C8:0C) [05:19:34:187]: Hello, I'm your 32bit Impersonated custom 
action server.
CAQuietExec:  Error 0x80070002: Command failed to execute.
CAQuietExec:  Error 0x80070002: CAQuietExec Failed



__
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 
http://mail.yahoo.com -
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] SelectionTree not showing the features to be installed!

2007-11-01 Thread Sebastian Brand
Also make sure the 's Level attribute is not set to "0".


Best regards,
Sebastian Brand

Instyler Software - http://www.instyler.com


On Oct 30, 2007, at 2:29 , Richard wrote:

>
> In article  
> <[EMAIL PROTECTED]>,
>"Sajo Jacob" <[EMAIL PROTECTED]>  writes:
>
>> I have defined all my features with Display='expand' and
>> AllowAdvertise="yes" with the appropriate components refs but still  
>> don't
>> see the features on the selectiontree. It in fact shows a 2 level  
>> tree with
>> no names to the features, something is definitely not right here  
>> since I
>> have more than 2 features. Am I missing something here?
>
> Open the MSI in Orca and look at the Feature table to ensure that
> everything is populated correctly.
> -- 
> "The Direct3D Graphics Pipeline" -- DirectX 9 draft available for  
> download
>  
>
>Legalize Adulthood! 
>
> -
> This SF.net email is sponsored by: Splunk Inc.
> Still grepping through log files to find problems?  Stop.
> Now Search log events and configuration files using AJAX and a  
> browser.
> Download your FREE copy of Splunk now >> http://get.splunk.com/
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Changing strings in dialog boxes

2007-11-01 Thread Stephen Tunney
Hello, I have what might probably be an easy problem to solve, but I can not
find a way :(

 

I currently have an installer that shows ".will install PRODUCT".  I wish it
to say ". will install the PRODUCT".

 

Is there a way to override the resource strings?  I need to change this in a
few places (install cancellation, etc.)

 

Thanks,

Stephen

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Changing the default installation directory

2007-11-01 Thread 0x001A4

How would I go about changing the default installation directory from Program
Files to the C:\ or whatever drive the user has windows installed on?
-- 
View this message in context: 
http://www.nabble.com/Changing-the-default-installation-directory-tf4731406.html#a13528883
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Wix Integer Variables

2007-11-01 Thread Cryptonomicon


A so you were thinking along the lines of the preprocessor would just
produce a file with the correct values in the right place - so why wouldn't
the compiler eat it.

I was just delving into perl to get perl to read a file of file names and
produce the correctly formatted components. Am glad I wont have to now.



-- 
View this message in context: 
http://www.nabble.com/Wix-Integer-Variables-tf4730515.html#a13528217
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Wix Integer Variables

2007-11-01 Thread Karim MacDonald


Cryptonomicon wrote:
> 
> I am guessing that 
> 
> 
> and
> 
>  Guid="C4AB05E7-BE8D-40F2-891F-583750779D05" DiskId="1" Win64=$(var.Is64)>
> 
> will cause pain grief and misery?
> 
Not for me it didn't :) I tried this (actually: Win64="$(var.Win64)"), got
the squiggly blue lines and gave up for other things. Then a while later I
actually thought about it and tried pressing Compile. Sure enough it all
works fine! Makes it all very easy to have a single source for compiling up
32-/64-bit installers. I also have a Guid="$(var.Guid)" line (referring to a
fragment-local Guid variable) in each 32-/64-bit component, as I think
otherwise there's scope for messing up component rules.

Cryptonomicon wrote:
> 
> or is there a variation on 
> 
> 
> 
> 
> I have missed?
> 
Getting rid of the squiggly blue lines would be even better so I'd be
interested in an answer to this too!

-K
-- 
View this message in context: 
http://www.nabble.com/Wix-Integer-Variables-tf4730515.html#a13528211
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Uninstall removing edited files

2007-11-01 Thread Craig0ss

Hey

Basically my installer installs certain standard letters for use with the
software, if i change the standard letter to incorperate client specific
details and then uninstall the product the modified file is removed, is
there a way to check if the file has been modified and do not delete it on
uninstall?

Thanks 

Criag0ss
-- 
View this message in context: 
http://www.nabble.com/Uninstall-removing-edited-files-tf4730727.html#a13527018
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


Re: [WiX-users] Heat with self-registration dlls!

2007-11-01 Thread Karim MacDonald


Sajo Jacob wrote:
> 
> Thanks! that explains the exe's but how about the dlls with this issue?
> 
64-bit DLLs? I don't know how heat.exe even manages to load and call
DllRegisterServer on 64-bit DLLs (it's a 32-bit .exe in the WiX download),
but it definitely doesn't produce what you'd expect. However, running heat
against the 32-bit version of the DLL produces the right output, and the
resultant Component can then simply be marked as Win64="yes".

Karim

-- 
View this message in context: 
http://www.nabble.com/Heat-with-self-registration-dlls%21-tf4727548.html#a13526933
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Wix Integer Variables

2007-11-01 Thread Cryptonomicon

I am guessing that 

 


  


  



and



will cause pain grief and misery?

or is there a variation on 




I have missed?

-- 
View this message in context: 
http://www.nabble.com/Wix-Integer-Variables-tf4730515.html#a13526479
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Several Installed Versions at once - Production - Pre release etc

2007-11-01 Thread Cryptonomicon

I am putting together a package of number crunching code that will be opened
sourced and I need to run parallel versions.  I envision that users will be
running the validated release version and may also be playing with a non
validated version (by validation i mean the number crunching routines
produce the right numbers - which look remarkably like the wrong answers)

So what I need to do is come up with a process via which users can install -
remove - upgrade etc one version and not touch the other. In fact I could
see production users who have been roped into UAT in other scenarios may
need parallel versions running on the same machine without a risk of the
test application frying production data.

Is it the product code or the upgrade code I need to do this?

Or more simply if  I has a unique upgrade code for each of Development Test
Beta and Production would these all look like separate applications?

I put a (Beta) (Dev) (Test) etc after the product name to distinguish them -
I am assuming that changing the product name doesn't really matter
-- 
View this message in context: 
http://www.nabble.com/Several-Installed-Versions-at-once---Production---Pre-release-etc-tf4730376.html#a13526103
Sent from the wix-users mailing list archive at Nabble.com.


-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


[WiX-users] Silent Installation

2007-11-01 Thread gunass
sai

-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems?  Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now >> http://get.splunk.com/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users