Re: [WiX-users] Solved! RE: RegistrySearch returning strange value

[Arnette, Bill]

Just an FYI...

We ran into a different manifestation of this problem on a couple of HP
computers.   In this case the Uninstall\@InstallLocation was
\Hewlett-Packard\ and caused the installation to fail very early with a
"Can't find network location \Hewlett-Packard\"  (or something like
that) error dialog.

Bill

-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com] 
Sent: Friday, February 15, 2013 12:53 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

That's cool.  I was contemplating putting in special code to work around
it but I think it will be such a rare occurrence that it wouldn't be
worth the time/effort.

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Friday, February 15, 2013 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

That's correct.

-----Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: 15 February 2013 16:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

So it appears you leave it as a customer support issue instead of
guarding against it in your installer?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Thursday, February 14, 2013 6:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

Yep, the Canon installers are the scourge of the deployment world ;) Us
too.
Sorry I didn't see your message in time.
http://kb.sdl.com/#tab:homeTab:crumb:7:artId:4654

-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: 13 February 2013 18:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Solved! RE: RegistrySearch returning strange value

Solved!

It seems that (an older version) of Canon Easy Web-Print EX which
shipped with the (in our case) Pixma MG8120 was putting its Uninstall
values directly beneath the Uninstall key instead of in its own
product-specific key and didn't clear them on uninstall.   

So for a new install of our product, [PREVIOUSVERSIONSINSTALLED]
resolved to an empty string thus causing my AppSearch to resolve to
HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\@InstallLocatio
n where it happily found the erroneous InstallLocation value.

The current version of the Canon software on their web site creates the
correct Uninstall key/value hierarchy so I was unable to reproduce it on
my machine.  

These people ran into the same issue but were unable to figure it out..
http://community.mediabrowser.tv/permalinks/2650/cronos-install-error

Is there any way to get AppSearch to log what path it is searching or at
what path it found a valid value?   That would have helped tremendously
in this case.


-----Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: Wednesday, February 13, 2013 11:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch returning strange value

Hi all,

 

I ran into the strangest problem on a customer's machine today.   He was
installing a new version (MAJOR upgrade) of our software which has the
authoring below.   We set INSTALLDIR from UPGRADEDIR if a previous
version is installed (SetUpgradeInstallDir custom action) and make the
installation folder read-only (conditioned on UPGRADEDIR<>"") on the
[Admin]FolderForm to force the new version to be installed to the same
location.  

 

On this particular customer's computer, UPGRADEDIR was set to some other
application (in fact a Canon software component).   This would happen
even if I uninstalled the older version of my application and the Canon
software.  

 

My first thought was that for some reason our UpgradeCode was the same
as the Canon software; though we should be able to have GUID collision
like that.
But after downloading and examining the Canon software's installer, it
does not even appear to be Windows Installer based.

 

I am going to modify the conditions to also require
PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an
upgrade, but why would the RegistrySearch return some other
application's Uninstall key?

 

WiX version is 3.0.  Installation target is Win7 64-bit.
Application/installer is 32-bit.

 

Thanks in advance for any insight you can provide.

 

Bill

 

 





  



 



 

 



  

  



 

 

 



 

   . . .

  NOT Installed

  

  

 

 

  . . .



 

 

 







 

   . . .

 

 

 



--**--
This email and any files transmitted with it a

Re: [WiX-users] Solved! RE: RegistrySearch returning strange value

[Arnette, Bill]

That's cool.  I was contemplating putting in special code to work around
it but I think it will be such a rare occurrence that it wouldn't be
worth the time/effort.

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Friday, February 15, 2013 12:34 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

That's correct.

-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: 15 February 2013 16:55
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

So it appears you leave it as a customer support issue instead of
guarding against it in your installer?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: Thursday, February 14, 2013 6:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

Yep, the Canon installers are the scourge of the deployment world ;) Us
too.
Sorry I didn't see your message in time.
http://kb.sdl.com/#tab:homeTab:crumb:7:artId:4654

-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: 13 February 2013 18:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Solved! RE: RegistrySearch returning strange value

Solved!

It seems that (an older version) of Canon Easy Web-Print EX which
shipped with the (in our case) Pixma MG8120 was putting its Uninstall
values directly beneath the Uninstall key instead of in its own
product-specific key and didn't clear them on uninstall.   

So for a new install of our product, [PREVIOUSVERSIONSINSTALLED]
resolved to an empty string thus causing my AppSearch to resolve to
HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\@InstallLocatio
n where it happily found the erroneous InstallLocation value.

The current version of the Canon software on their web site creates the
correct Uninstall key/value hierarchy so I was unable to reproduce it on
my machine.  

These people ran into the same issue but were unable to figure it out..
http://community.mediabrowser.tv/permalinks/2650/cronos-install-error

Is there any way to get AppSearch to log what path it is searching or at
what path it found a valid value?   That would have helped tremendously
in this case.


-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: Wednesday, February 13, 2013 11:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch returning strange value

Hi all,

 

I ran into the strangest problem on a customer's machine today.   He was
installing a new version (MAJOR upgrade) of our software which has the
authoring below.   We set INSTALLDIR from UPGRADEDIR if a previous
version is installed (SetUpgradeInstallDir custom action) and make the
installation folder read-only (conditioned on UPGRADEDIR<>"") on the
[Admin]FolderForm to force the new version to be installed to the same
location.  

 

On this particular customer's computer, UPGRADEDIR was set to some other
application (in fact a Canon software component).   This would happen
even if I uninstalled the older version of my application and the Canon
software.  

 

My first thought was that for some reason our UpgradeCode was the same
as the Canon software; though we should be able to have GUID collision
like that.
But after downloading and examining the Canon software's installer, it
does not even appear to be Windows Installer based.

 

I am going to modify the conditions to also require
PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an
upgrade, but why would the RegistrySearch return some other
application's Uninstall key?

 

WiX version is 3.0.  Installation target is Win7 64-bit.
Application/installer is 32-bit.

 

Thanks in advance for any insight you can provide.

 

Bill

 

 





  



 



 

 



  

  



 

 

 



 

   . . .

  NOT Installed

  

  

 

 

  . . .



 

 

 







 

   . . .

 

 

 



--**--
This email and any files transmitted with it are confidential and
intended solely for the use of Signalscape, Inc. and the addressed
individual or entity.  If you have received this email in error please
delete it.
Information in this email may be subject to the Privacy Act of
1974 and any unauthorized review, use, disclosure, or distribution is
strictly prohibited.  Any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of the
company.

--
Free Next-Gen Firewall Hardware Offer
Buy your S

Re: [WiX-users] Solved! RE: RegistrySearch returning strange value

[Arnette, Bill]

So it appears you leave it as a customer support issue instead of
guarding against it in your installer?

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: Thursday, February 14, 2013 6:57 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Solved! RE: RegistrySearch returning strange
value

Yep, the Canon installers are the scourge of the deployment world ;) Us
too.
Sorry I didn't see your message in time.
http://kb.sdl.com/#tab:homeTab:crumb:7:artId:4654

-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: 13 February 2013 18:59
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Solved! RE: RegistrySearch returning strange value

Solved!

It seems that (an older version) of Canon Easy Web-Print EX which
shipped with the (in our case) Pixma MG8120 was putting its Uninstall
values directly beneath the Uninstall key instead of in its own
product-specific key and didn't clear them on uninstall.   

So for a new install of our product, [PREVIOUSVERSIONSINSTALLED]
resolved to an empty string thus causing my AppSearch to resolve to
HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\@InstallLocatio
n where it happily found the erroneous InstallLocation value.

The current version of the Canon software on their web site creates the
correct Uninstall key/value hierarchy so I was unable to reproduce it on
my machine.  

These people ran into the same issue but were unable to figure it out..
http://community.mediabrowser.tv/permalinks/2650/cronos-install-error

Is there any way to get AppSearch to log what path it is searching or at
what path it found a valid value?   That would have helped tremendously
in this case.


-Original Message-----
From: Arnette, Bill [mailto:bi...@signalscape.com]
Sent: Wednesday, February 13, 2013 11:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch returning strange value

Hi all,

 

I ran into the strangest problem on a customer's machine today.   He was
installing a new version (MAJOR upgrade) of our software which has the
authoring below.   We set INSTALLDIR from UPGRADEDIR if a previous
version is installed (SetUpgradeInstallDir custom action) and make the
installation folder read-only (conditioned on UPGRADEDIR<>"") on the
[Admin]FolderForm to force the new version to be installed to the same
location.  

 

On this particular customer's computer, UPGRADEDIR was set to some other
application (in fact a Canon software component).   This would happen
even if I uninstalled the older version of my application and the Canon
software.  

 

My first thought was that for some reason our UpgradeCode was the same
as the Canon software; though we should be able to have GUID collision
like that.
But after downloading and examining the Canon software's installer, it
does not even appear to be Windows Installer based.

 

I am going to modify the conditions to also require
PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an
upgrade, but why would the RegistrySearch return some other
application's Uninstall key?

 

WiX version is 3.0.  Installation target is Win7 64-bit.
Application/installer is 32-bit.

 

Thanks in advance for any insight you can provide.

 

Bill

 

 





  



 



 

 



  

  



 

 

 



 

   . . .

  NOT Installed

  

  

 

 

  . . .



 

 

 







 

   . . .

 

 

 



--**--
This email and any files transmitted with it are confidential and
intended solely for the use of Signalscape, Inc. and the addressed
individual or entity.  If you have received this email in error please
delete it.
Information in this email may be subject to the Privacy Act of
1974 and any unauthorized review, use, disclosure, or distribution is
strictly prohibited.  Any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of the
company.

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the
hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--**--
This email and any files transmitted with it are confidential and
intended solely for the use of Signalscape, Inc. and the addressed
individual or entity.  If you have received this email in error please
delete it.
Information in this email may be subject to the Privacy Act of
1974 and any unauthorized review, use, disclosure, or distribution is
strictly prohibited.  Any views 

[WiX-users] Solved! RE: RegistrySearch returning strange value

[Arnette, Bill]

Solved!

It seems that (an older version) of Canon Easy Web-Print EX which
shipped with the (in our case) Pixma MG8120 was putting its Uninstall
values directly beneath the Uninstall key instead of in its own
product-specific key and didn't clear them on uninstall.   

So for a new install of our product, [PREVIOUSVERSIONSINSTALLED]
resolved to an empty string thus causing my AppSearch to resolve to
HKLM:Software\Microsoft\Windows\CurrentVersion\Uninstall\@InstallLocatio
n where it happily found the erroneous InstallLocation value.

The current version of the Canon software on their web site creates the
correct Uninstall key/value hierarchy so I was unable to reproduce it on
my machine.  

These people ran into the same issue but were unable to figure it out..
http://community.mediabrowser.tv/permalinks/2650/cronos-install-error

Is there any way to get AppSearch to log what path it is searching or at
what path it found a valid value?   That would have helped tremendously
in this case.


-Original Message-
From: Arnette, Bill [mailto:bi...@signalscape.com] 
Sent: Wednesday, February 13, 2013 11:42 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] RegistrySearch returning strange value

Hi all,

 

I ran into the strangest problem on a customer's machine today.   He was
installing a new version (MAJOR upgrade) of our software which has the
authoring below.   We set INSTALLDIR from UPGRADEDIR if a previous
version is installed (SetUpgradeInstallDir custom action) and make the
installation folder read-only (conditioned on UPGRADEDIR<>"") on the
[Admin]FolderForm to force the new version to be installed to the same
location.  

 

On this particular customer's computer, UPGRADEDIR was set to some other
application (in fact a Canon software component).   This would happen
even if I uninstalled the older version of my application and the Canon
software.  

 

My first thought was that for some reason our UpgradeCode was the same
as the Canon software; though we should be able to have GUID collision
like that.  But after downloading and examining the Canon software's
installer, it does not even appear to be Windows Installer based.

 

I am going to modify the conditions to also require
PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an
upgrade, but why would the RegistrySearch return some other
application's Uninstall key?

 

WiX version is 3.0.  Installation target is Win7 64-bit.
Application/installer is 32-bit.

 

Thanks in advance for any insight you can provide.

 

Bill

 

 





  



 



 

 



  

  



 

 

 



 

   . . .

  NOT Installed

  

  

 

 

  . . .



 

 

 







 

   . . .

 

 

 



--**--
This email and any files transmitted with it are confidential and
intended solely for the use of Signalscape, Inc. and the addressed
individual or entity.  If you have received this email in error please
delete it.  Information in this email may be subject to the Privacy Act
of
1974 and any unauthorized review, use, disclosure, or distribution is
strictly prohibited.  Any views or opinions presented in this email are
solely those of the author and do not necessarily represent those of the
company.

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 and get the
hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--**--
This email and any files transmitted with it are confidential and 
intended solely for the use of Signalscape, Inc. and the addressed 
individual or entity.  If you have received this email in error please 
delete it.  Information in this email may be subject to the Privacy Act of 
1974 and any unauthorized review, use, disclosure, or distribution is 
strictly prohibited.  Any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of 
the company.

--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] RegistrySearch returning strange value

[Arnette, Bill]

Hi all,

 

I ran into the strangest problem on a customer's machine today.   He was
installing a new version (MAJOR upgrade) of our software which has the
authoring below.   We set INSTALLDIR from UPGRADEDIR if a previous
version is installed (SetUpgradeInstallDir custom action) and make the
installation folder read-only (conditioned on UPGRADEDIR<>"") on the
[Admin]FolderForm to force the new version to be installed to the same
location.  

 

On this particular customer's computer, UPGRADEDIR was set to some other
application (in fact a Canon software component).   This would happen
even if I uninstalled the older version of my application and the Canon
software.  

 

My first thought was that for some reason our UpgradeCode was the same
as the Canon software; though we should be able to have GUID collision
like that.  But after downloading and examining the Canon software's
installer, it does not even appear to be Windows Installer based.

 

I am going to modify the conditions to also require
PREVIOUSVERSIONSINSTALLED to be non-NULL to determine that this is an
upgrade, but why would the RegistrySearch return some other
application's Uninstall key?

 

WiX version is 3.0.  Installation target is Win7 64-bit.
Application/installer is 32-bit.

 

Thanks in advance for any insight you can provide.

 

Bill

 

 





  



 



 

 



  

  



 

 

 



 

   . . .

  NOT Installed

  

  

 

 

  . . .



 

 

 







 

   . . .

 

 

 



--**--
This email and any files transmitted with it are confidential and 
intended solely for the use of Signalscape, Inc. and the addressed 
individual or entity.  If you have received this email in error please 
delete it.  Information in this email may be subject to the Privacy Act of 
1974 and any unauthorized review, use, disclosure, or distribution is 
strictly prohibited.  Any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of 
the company.
--
Free Next-Gen Firewall Hardware Offer
Buy your Sophos next-gen firewall before the end March 2013 
and get the hardware for free! Learn more.
http://p.sf.net/sfu/sophos-d2d-feb
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Heat.exe, "suppress COM" usage (-scom)

[Arnette, Bill]

Use -scom -sreg to suppress all COM and registry info if you are only
after file information.

-Original Message-
From: Hoover, Jacob [mailto:jacob.hoo...@greenheck.com] 
Sent: Tuesday, January 08, 2013 4:29 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Heat.exe, "suppress COM" usage (-scom)

While it may not be optimal, you could use an XSLT to remove the
unwanted elements. If I had to guess, the scom element simply tells heat
to use the MSI Registry table instead of the TypeLib (and related)
tables.  I seem to remember a post by Rob and maybe an ICE saying not to
use the TypeLib due to versioning issues.  

So, if you leave out the scom from the command line, you should be able
to write an XSLT to only copy elements if they don't have TypeLib for an
element.

Untested quick hack to follow:


http://www.w3.org/1999/XSL/Transform";
  xmlns:msxsl="urn:schemas-microsoft-com:xslt"
  xmlns:wix="http://schemas.microsoft.com/wix/2006/wi";
  exclude-result-prefixes="msxsl wix">
  
  

  

  

  

  
  

-Original Message-
From: JohnB [mailto:john.bu...@telvent.com]
Sent: Tuesday, January 08, 2013 2:43 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Heat.exe, "suppress COM" usage (-scom)

I'm harvesting a directory/file structure.  I do not want COM visible
files to be COM registered - this is for a server-side product that
doesn't use registry-based COM.  Some of the assemblies are COM visible,
so heat harvests registry information.  I tried adding the "suppress
COM" (-scom) option, but it still harvests COM registration information.
It would also be nice if it didn't try to load dependencies while
harvesting.  I just want directories/files.

The heat call I'm making is:
heat.exe dir  -dr  -nologo -srd -suid -scom -svb6 -wx
-o 

I'm curious what the -scom flag is supposed to do.  The only
documentation I can find is the usage statement "suppress COM elements".
If I compare with/without, the differences I see are that without the
flag there are Class and ProgID elements, but with the flag there are,
instead, additional RegistryValue elements that appear to do the same
job.  Perhaps someone can shed some light on what -scom is intended for?



--
View this message in context:
http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Heat-exe-s
uppress-COM-usage-scom-tp7582733.html
Sent from the wix-users mailing list archive at Nabble.com.


--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and
experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and
experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--**--
This email and any files transmitted with it are confidential and 
intended solely for the use of Signalscape, Inc. and the addressed 
individual or entity.  If you have received this email in error please 
delete it.  Information in this email may be subject to the Privacy Act of 
1974 and any unauthorized review, use, disclosure, or distribution is 
strictly prohibited.  Any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of 
the company.

--
Master SQL Server Development, Administration, T-SQL, SSAS, SSIS, SSRS
and more. Get SQL Server skills now (including 2012) with LearnDevNow -
200+ hours of step-by-step video tutorials by Microsoft MVPs and experts.
SALE $99.99 this month only - learn more at:
http://p.sf.net/sfu/learnmore_122512
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Registry search and condition message in installer

[Arnette, Bill]

Wouldn't your x86 search need to search the WoW6432Node of HKLM to be
correct?

HKLM:\Software\Wow6432Node\Microsoft\Windows\CurrentVersion\Uninstall


But also, it seems to me that you should be using the MSI API
(MsiGetProductInfo specifically) in a custom action to get information
about other installed applications instead of querying hard-coded
registry entries.  

Bill

-Original Message-
From: Steven Ogilvie [mailto:steven.ogil...@titus.com] 
Sent: Wednesday, December 19, 2012 10:34 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Registry search and condition message in
installer

John, Rob, Peter,

Thanks so much for your help... the below from John works like a charm!
Can't get my head around the logic but it works...

Steve

-Original Message-
From: John Ludlow [mailto:john.ludlow...@gmail.com]
Sent: December-19-12 9:24 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Registry search and condition message in
installer

That would only work at build time, if you were compiling an x86 MSI and
an x64 MSI.

I think you just need to extend your condition to something like this:

   Installed OR (SQLSYNCX64SEARCH > "0" AND VersionNT64) OR (NOT
VersionNT64)

   Installed OR (SQLSYNCX86SEARCH > "0" AND NOT VersionNT64) OR
(VersionNT64)


On 19 December 2012 13:32, Steven Ogilvie 
wrote:
> Then I will have to use $(var.Platform) <> "x86" that should work
>
> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: December-19-12 5:11 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Registry search and condition message in 
> installer
>
> VersionNT64 is undefined on a 32-bit OS so Installed OR
(SQLSYNCX64SEARCH > "0" AND VersionNT64) would be
> FALSE or (something AND FALSE)   === FALSE
> which would cause the message to display.
>
> -Original Message-
> From: Steven Ogilvie [mailto:steven.ogil...@titus.com]
> Sent: 19 December 2012 04:19
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Registry search and condition message in 
> installer
>
> Oops I should have said as well...
>
> The 32 bit version is checked and correct since it is installed so the

> logic is correct for the 32 bit check of  Id="SQLSYNCX86SEARCH" Value="0"> it's the 64bit check that is failing 
> on the 32 bit OS
>
> -Original Message-
> From: Rob Mensching [mailto:r...@robmensching.com]
> Sent: December-18-12 7:19 PM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Registry search and condition message in 
> installer
>
> I always use a verbose log file to check the values of Properties
since that where I usually make my mistakes.
>
>
> On Tue, Dec 18, 2012 at 3:14 PM, StevenOgilvie 
wrote:
>
>> I have a 32 bit installer, it can run on a 32 bit or a 64 bit OS...
>> On the 32 bit OS only the 32 bit pre requisites are run, but on the
>> 64 bit OS both 32/64 bit pre requisites are run.
>>
>> The installer verifies that the pre requisites are installed (ya its 
>> overkill but that is another story)...
>>
>> On a 64 bit machine all works fine, on a 32 bit OS I am running into 
>> errors where the condition message displays even though it shouldn't,

>> I have been playing around with this for too long, what am I doing 
>> wrong? thanks in advance...
>>
>> Registry check:
>>
>> 
>>   >
>>
>>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{7AC8EF88-D99
> 6-4D47-
> B40C-4DD93E307481}"
>>   Name="DisplayVersion"
>>   Root="HKLM"
>>   Type="raw"
>>   Win64="no"/>
>>   
>>
>> 
>>   >
>>
>>
> Key="SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\{A4E269C1-168
> D-40D3-
> 9ABD-57FE4D4DB537}"
>>   Name="DisplayVersion"
>>   Root="HKLM"
>>   Type="raw"
>>   Win64="yes"/>
>>   
>>
>> Condition Message:
>> http://www.microsoft.com/en-us/download/default.aspx
>> then restart the $(var.ProductName) setup.">
>>   < ! [ CDATA [Installed OR (SQLSYNCX86SEARCH > "0")]]>
>> 
>> http://www.microsoft.com/en-us/download/default.aspx
>> then restart the $(var.ProductName) setup.">
>>   < ! [CDATA [(Installed OR (SQLSYNCX64SEARCH > "0" AND
VersionNT64)]]>
>> 
>>
>> BTW I have added spaces < ! [ CDATA because nabble doesn't like this
>> :) Steve
>>
>>
>>
>> --
>> View this message in context:
>> http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Registr
>> y -search-and-condition-message-in-installer-tp7582450.html
>> Sent from the wix-users mailing list archive at Nabble.com.
>>
>>
>> -
>> -
>>  LogMeIn Rescue: Anywhere, Anytime Remote support for IT. 
>> Free Trial Remotely access PCs and mobile devices and p

[WiX-users] How to handle flavor upgrades

[Arnette, Bill]

What would be the recommended way to handle "flavor" upgrades such as
from an Express version of an application to a Pro version?

 



--**--
This email and any files transmitted with it are confidential and 
intended solely for the use of Signalscape, Inc. and the addressed 
individual or entity.  If you have received this email in error please 
delete it.  Information in this email may be subject to the Privacy Act of 
1974 and any unauthorized review, use, disclosure, or distribution is 
strictly prohibited.  Any views or opinions presented in this email are 
solely those of the author and do not necessarily represent those of 
the company.
--
Keep yourself connected to Go Parallel: 
INSIGHTS What's next for parallel hardware, programming and related areas?
Interviews and blogs by thought leaders keep you ahead of the curve.
http://goparallel.sourceforge.net
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Intentionally leaving a file behind...

[Arnette, Bill]

Mark the component as permanent and never-overwrite.
 
--
Bill Arnette
www.starwitness.com  
 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Rory Clark
Sent: Tuesday, August 21, 2007 4:57 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Intentionally leaving a file behind...


Is it possible mark as left behind if changed? Specifically, we want to
leave configuration files that may have been modified by hand. Does
WiX/Windows Installer allow that? I haven't found anything yet that says
one way or the other.
 
Thanks!
Rory
-
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] backing up the existing files while installing

[Arnette, Bill]

We tried to do this with our configuration files.  
 
The issue we faced was that because RemoveExistingProducts came early
on, the old file was removed with the old product, but we wanted it
remain untouched by the installer during an upgrade or if the user
manually uninstalled the application.
 
At first we tried using CopyFiles, but that doesn't work because you can
only schedule CopyFiles once, so you can't use it to backup and then
restore the files.  
 
We settled on making the configuration files Permanent, Never-Overwrite
in the new installer and scheduling RemoveExistingProducts after
InstallFinalize.  Because the files are Permanent, the upgrade will not
overwrite them and RemoveExistingProducts will not remove them because
there are now two products using those components so the reference count
will not go to 0 when the older version is removed.
 
--
Bill Arnette
www.starwitness.com  
 
 



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Balaji
Nidadavolu
Sent: Wednesday, August 01, 2007 9:44 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] backing up the existing files while installing



Hi,

 

Our current requirement is something like this.

 

Requirement(in WIX) : We are currently adding a component to the
existing software. While installing the component, we need to take a
backup of 2 files since they will be replaced with their latest
versions. While uninstalling the component, we need to replace the newer
versions with their older version counterparts. 

 

Can anyone please let us know if there are any properties that we can
use in WIX that need to be set, rather than writing custom actions.

 

You help is desperately sought.

 

Thank you,

 

Regards

Balaji.

 

 

 

 

 

DISCLAIMER == This e-mail may contain privileged and
confidential information which is the property of Persistent Systems
Pvt. Ltd. It is intended only for the use of the individual or entity to
which it is addressed. If you are not the intended recipient, you are
not authorized to read, retain, copy, print, distribute or use this
message. If you have received this communication in error, please notify
the sender and delete all copies of this message. Persistent Systems
Pvt. Ltd. does not accept any liability for virus infected mails.

-
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] AppSearch during UI

[Arnette, Bill]

It's not that I want to know where it was previously installed.  

It's that I want to know if a configuration file already exists in the
path the user selects (INSTALLDIR).  If the configuration file already
exists, I don't want to give the appearance that it can be changed; i.e.
I am presuming that that configuration file points to an orphaned
configuration that the user wants to adopt again.

Ex.

 - By default INSTALLDIR is set to C:\Program Files\MyApp
 - User changes the installation directory to C:\MyApp
 - User specifies the file store to be D:\MyApp\FileStore
 - The application is installed and the configuration file is written
containing FileStore=D:\MyApp\FileStore
 - User uninstalls application [1]; configuration file remains.  
 - User installs application again (new version)
 - User changes installation directory to C:\MyApp
 - Installer should detect that the configuration file already exists in
C:\MyApp and not present the UI to specify the file store location.  
 - The application is installed but the configuration file is not
overwritten.
 
[1] He didn't realize that he could just upgrade using the new installer
instead of manually uninstalling the old version first.

--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: Brian Simoneau [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, July 31, 2007 2:15 PM
To: Arnette, Bill; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] AppSearch during UI

You could write a permanent registry entry containing the path that the
user selected, then read the registry entry when the install is run
again to find out where it was installed before.

-Brian Simoneau

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arnette,
Bill
Sent: Tuesday, July 31, 2007 10:50 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] AppSearch during UI


We are trying to mitigate an admittedly pathological case during
installation.

1.  User installs application to other than default directory.  The
installation installs a permanent, never-overwrite configuration file
which (among other things) specifies a file store [1] path which is
specified by the user during installation via a dialog. [2] 2.  User
later uninstalls the application.  Because the configuration file is
permanent, it is not deleted.
3.  User installs the application again and specifies the same
installation location as the last time it was installed.  But this time,
since the configuration file exists, I don't want to show the UI that
allows them to specify the file store location and I want to use the old
configuration file (which never-overwrite already takes care of).

The problem is, I can do the AppSearch before the UI to locate the
configuration file in the default installation directory.  But if the
user changes the installation directory, how do I determine if the
configuration file exists in that new path in order to skip the file
store configuration UI?  

The only thing that comes to mind is to write an AppSearch-like CA that
looks for the file in the new path.  Is there an easier way?  

[1] The file store is the place where large media files are stored
outside of the XML "database". 

[2] I hear you!  The installer should not do configuration.  BUT, the
application also allows optional installation of sample data.  That
sample data needs to go in the file store which is specified in the
configuration file.  So there needs to be some level of configuration in
the installer.

--
Bill Arnette
Principal Software Developer
StarWitness Business Unit
Signalscape, Inc.
www.starwitness.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

-
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] AppSearch during UI

[Arnette, Bill]

We are trying to mitigate an admittedly pathological case during
installation.

1.  User installs application to other than default directory.  The
installation installs a permanent, never-overwrite configuration file
which (among other things) specifies a file store [1] path which is
specified by the user during installation via a dialog. [2]
2.  User later uninstalls the application.  Because the configuration
file is permanent, it is not deleted.
3.  User installs the application again and specifies the same
installation location as the last time it was installed.  But this time,
since the configuration file exists, I don't want to show the UI that
allows them to specify the file store location and I want to use the old
configuration file (which never-overwrite already takes care of).

The problem is, I can do the AppSearch before the UI to locate the
configuration file in the default installation directory.  But if the
user changes the installation directory, how do I determine if the
configuration file exists in that new path in order to skip the file
store configuration UI?  

The only thing that comes to mind is to write an AppSearch-like CA that
looks for the file in the new path.  Is there an easier way?  

[1] The file store is the place where large media files are stored
outside of the XML "database". 

[2] I hear you!  The installer should not do configuration.  BUT, the
application also allows optional installation of sample data.  That
sample data needs to go in the file store which is specified in the
configuration file.  So there needs to be some level of configuration in
the installer.

--
Bill Arnette
Principal Software Developer
StarWitness Business Unit
Signalscape, Inc.
www.starwitness.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] bootstrapper?

[Arnette, Bill]

I think there is a package for SQL Server Express for the VS 2005
bootstrapper.  I am not sure how to specify it in an MSBuild file, but
you may be able to figure that out by creating a dummy setup in VS 2005
and specifying it as a dependency and then looking at the project file.

You can also create custom packages [1] for use with the VS 2005
bootstrapper using this tool [2].  So you could use it to create a
package for ITechLogger.

[1] http://msdn2.microsoft.com/en-us/library/aa730839(vs.80).aspx
[2] http://blogs.msdn.com/misampso/archive/2004/07/08/177822.aspx

--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jcafaro10
Sent: Monday, July 30, 2007 11:46 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] bootstrapper?


I know that to install .NET I need to use a bootstrapper so I made a
.proj file and put this in it, but I need to add other things to the
bootstrapper that won't install from the msi like sql server desktop
engine and itechlogger but I'm not sure how to do that.

http://schemas.microsoft.com/developer/msbuild/2003";>
  

  Microsoft .NET Framework 2.0

  

  

  

--
View this message in context:
http://www.nabble.com/bootstrapper--tf4171003.html#a11866122
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

-
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] Error code 2753?

[Arnette, Bill]

Installed is the CURRENT state of the installation.  I.e.  You are
telling that CA to run only if the applications is currently installed
(i.e. you are uninstalling it).  You want 'NOT Installed' for your
condition. 


--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of jcafaro10
Sent: Friday, July 27, 2007 2:07 PM
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Error code 2753?


Well even if I skip the net framework install, it will still give the
error so it must be the second one.  I thought I already specified that
I want the custom action to run only on install by having it a) start on
installfinalize and b) put "Installed" in the intallexecutesequence
command. 
How do I get it to run the correct executable if not the way I'm doing
it? 
This is only my second day using wix so forgive my ignorance.


 




  
Installed
  




Wilson, Phil wrote:
> 
> There are a number of things that don't seem right here: 
> 
> 1. It's usual to get the framework installed from a boostrapper, not 
> from the MSI file. This is because it's MSI-based and therefore you 
> can break the "can't run two simultaneous MSI installs" rule. Also, at

> least one version of the framework included an MSI engine update. That

> may be the one you're installing, and it's possible that future 
> frameworks might do it again, and you get into a pseudo-deadlock 
> because you can't update the MSI engine from inside your
already-running MSI.
> 
> 2. The problems you're having are related to:
> a) Conditions. You want a custom action to run only on install, then 
> you need it conditioned that way.
> b) Repeating myself somewhat, the 2753 error is because you've got a 
> custom action type that says "run this specific executable that I'm 
> installing". MSI doesn't care if it's already on the system because 
> you didn't say "run this executable on the system", you said "run this

> executable I'm installing". If it doesn't get installed then you get 
> error 2753. If you want a custom action to run some other way, then it

> can be run from the Binary table instead of "as a program I'm 
> installing".
> 
> Phil Wilson
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> jcafaro10
> Sent: Friday, July 27, 2007 10:17 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Error code 2753?
> 
> 
> Well now if I change my InstallExecuteSequence code to look like this:
> 
>  Action="DotNetInstall"
>   After="InstallFinalize">
>   Installed
>   
> 
> 
> Typical works right, as expected, because it will only try and install

> features that were actually Installed, and if I set feature level to 
> 4, those features won't be installed.  However, on the Remove, I get 
> the
> 2753 error (trying to remove something that wasn't installed maybe?).
> 
> Complete doesn't work as expected, it does what typical does, except 
> without the 2753 error for removing.
> 
> 
> Wilson, Phil wrote:
>> 
>> This error usually refers to a custom action that's running an exe 
>> that's being installed with the product, but isn't installed for some

>> reason (perhaps because the exe is already on the system and won't be

>> replaced because of versioning rules). So it can't run the exe from 
>> your package because it's not being installed. There are other 
>> variations, but they all come down to trying to run a custom action 
>> of
> 
>> a file that you're not actually installing.
>> 
>> Phil Wilson
>> 
>> 
>> -Original Message-
>> From: [EMAIL PROTECTED]
>> [mailto:[EMAIL PROTECTED] On Behalf Of 
>> jcafaro10
>> Sent: Thursday, July 26, 2007 2:48 PM
>> To: wix-users@lists.sourceforge.net
>> Subject: [WiX-users] Error code 2753?
>> 
>> 
>> Trying to get my installer to work.  It works for the main files but 
>> there are some files I don't want to install unless I click Complete 
>> (as Opposed to typical, I'm using mondo).  It copies the files 
>> correctly regardless but when I also want it to run the ones that it 
>> copies.  I think the problem is because of TypicalDefault="advertise"
>> but isn't that how I set a feature to not be installed typically but 
>> only under comlpete? Example:
>> 
>> 
>>   > Guid="{3AF116C7-E703-4F4D-B7BC-B9D4C0E0F093}">
>>  KeyPath="yes"
>> Source="C:\tfs\ChannelBox\prereq\dotnetfx\dotnetfx.exe" />
>>   
>> 
>> --
>> > TypicalDefault="advertise">
>>  
>> --
>> > Id="DotNetInstall"
>> FileKey="dotnetfxexe"
>> ExeCommand="deferred" 
>> Return="ignore" />
>> 
>> 
>>   >   Action="DotNetInstall"
>>   After="InstallFinalize">
>> 
>>   
>> 
>> --
>> View this message in context:
>> http://www.nabble.com/Error-code-2753--

Re: [WiX-users] Conditionally edit XML file if it is installed

[Arnette, Bill]

Oops, got the sense wrong on the  element below that I was
using to try to debug this stuff.  So, nevermind that.

After resolving that, putting the conditional (SYSCONFIGFILEEXISTS) on
the XML editing component works as long as I schedule AppSearch after
CostInitialize in the InstallUISequence table. 

I guess I'll just have to use that method instead of the
conditionalizing on the XML file component state or action.


--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arnette,
Bill
Sent: Thursday, July 19, 2007 2:20 PM
To: Pierson Lee (Volt); wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Conditionally edit XML file if it is installed

Well, I'm also trying that, and I'm just not grok'ing file search. 


   
  
   




For some reason, the "SysConfig.xml exists!" message is firing even when
INSTALLDIR does not exist on the system; let alone SysConfig.xml.  

I moved AppSearch after CostFinalize to make sure that INSTALLDIR is
resolved before the AppSearch, but still nothing.

Note that I am using WiX v2 if that matters.


--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: Pierson Lee (Volt) [mailto:[EMAIL PROTECTED]
Sent: Thursday, July 19, 2007 11:59 AM
To: Arnette, Bill; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Conditionally edit XML file if it is installed

Would it be worthwhile to do a filesearch and if it doesn't exist to
then install the component and change the file (in a different feature)?

That would be the way I'd do it, but I have yet to use the
NeverOverwrite option.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arnette,
Bill
Sent: Thursday, July 19, 2007 7:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditionally edit XML file if it is installed


I am trying to have my installer edit an XML file after it is installed.
However, the XML file should not be installed or edited if it already
exists on the system.  So I am trying to condition the installation of
the XML editing component on the state/action of the component which
contains the XML file to be edited.  But its not working.

I am seeing some conflicting info in the Windows Installer documentation
that in one place states the component state can only be used in the
condition table and the sequence tables, while the Component table
documentation states that the Condition column "accepts conditional
expressions containing references to the installed states of features
and components...".

So which is it?
Any idea what I'm doing wrong?



   
 
   

   
  
  

  
  
  
   




--
Bill Arnette
Principal Software Developer
StarWitness Business Unit
Signalscape, Inc.
www.starwitness.com



-
This SF.net email is sponsored by DB2 Express Download DB2 Express C -
the FREE version of DB2 express and take control of your XML. No limits.
Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


-
This SF.net email is sponsored by: Microsoft Defy all challenges.
Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Conditionally edit XML file if it is installed

[Arnette, Bill]

Well, I'm also trying that, and I'm just not grok'ing file search. 


   
  
   




For some reason, the "SysConfig.xml exists!" message is firing even when
INSTALLDIR does not exist on the system; let alone SysConfig.xml.  

I moved AppSearch after CostFinalize to make sure that INSTALLDIR is
resolved before the AppSearch, but still nothing.

Note that I am using WiX v2 if that matters.


--
Bill Arnette
www.starwitness.com
 

-Original Message-
From: Pierson Lee (Volt) [mailto:[EMAIL PROTECTED] 
Sent: Thursday, July 19, 2007 11:59 AM
To: Arnette, Bill; wix-users@lists.sourceforge.net
Subject: RE: [WiX-users] Conditionally edit XML file if it is installed

Would it be worthwhile to do a filesearch and if it doesn't exist to
then install the component and change the file (in a different feature)?

That would be the way I'd do it, but I have yet to use the
NeverOverwrite option.

-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Arnette,
Bill
Sent: Thursday, July 19, 2007 7:14 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Conditionally edit XML file if it is installed


I am trying to have my installer edit an XML file after it is installed.
However, the XML file should not be installed or edited if it already
exists on the system.  So I am trying to condition the installation of
the XML editing component on the state/action of the component which
contains the XML file to be edited.  But its not working.

I am seeing some conflicting info in the Windows Installer documentation
that in one place states the component state can only be used in the
condition table and the sequence tables, while the Component table
documentation states that the Condition column "accepts conditional
expressions containing references to the installed states of features
and components...".

So which is it?
Any idea what I'm doing wrong?



   
 
   

   
  
  

  
  
  
   




--
Bill Arnette
Principal Software Developer
StarWitness Business Unit
Signalscape, Inc.
www.starwitness.com



-
This SF.net email is sponsored by DB2 Express Download DB2 Express C -
the FREE version of DB2 express and take control of your XML. No limits.
Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

-
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse012070mrt/direct/01/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Conditionally edit XML file if it is installed

[Arnette, Bill]

I am trying to have my installer edit an XML file after it is installed.
However, the XML file should not be installed or edited if it already
exists on the system.  So I am trying to condition the installation of
the XML editing component on the state/action of the component which
contains the XML file to be edited.  But its not working.

I am seeing some conflicting info in the Windows Installer documentation
that in one place states the component state can only be used in the
condition table and the sequence tables, while the Component table
documentation states that the Condition column "accepts conditional
expressions containing references to the installed states of features
and components...".  

So which is it? 
Any idea what I'm doing wrong?



   
 
   

   
  
  

  
  
  
   




--
Bill Arnette
Principal Software Developer
StarWitness Business Unit
Signalscape, Inc.
www.starwitness.com
 

-
This SF.net email is sponsored by DB2 Express
Download DB2 Express C - the FREE version of DB2 express and take
control of your XML. No limits. Just data. Click to get it now.
http://sourceforge.net/powerbar/db2/
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Setting icons to shortcut, works with exe but not with ico

[Arnette, Bill]

See the last paragraph in the Icon Table documentation [1]:
 
---
However, Icon files that are associated with shortcuts must be in the
EXE binary format and must be named such that their extension matches
the extension of the target. The shortcut will not work if this rule is
not followed. For example, if a shortcut is to point to a resource
having the key file Red.bar, then the icon file must also have the
extension .bar. Multiple icons can be stuffed into the same icon file as
long as all of the target files have the same extension.
---
 
Now it has been my experience that contrary to the above statement, the
file does NOT have to be in EXE format, but the Icon element Id has to
have the same extension as the target file.
 
So try this:




 
 

 
[1] http://msdn2.microsoft.com/en-us/library/aa369210.aspx
 
 
 
--
Bill Arnette
www.starwitness.com  
 
 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Maslov,
Igor
Sent: Monday, April 02, 2007 8:29 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Setting icons to shortcut,works with exe but not
with ico



Hello, 

I'm trying to do quite simple thing - set a shortcut to installed
executable. It works and if my icon is embedded in executable I can see
icon image displayed on the shortcut:

This works fine: 





 
 

But when I try to use a separate icon file, I see a symbolic image of an
icon, instead of icon image itself (the same symbolic image of an icon
that I see in Windows explorer):

This does not quite work: 





 
 

If I open my desktop folder, and select "Thumbnails" view I can see my
icon.ico picture on the shortcut, but in all other modes I just see
symbolic image of an icon.

Is there a way to make it working? 

And two more questions, that are related: 

1. I assumed that IconIndex references to the index of the image inside
.exe, .dll, or .ico files, but when I try to set nonzero IconIndex in
wxs file, the shortcut looses it's icon. 

   I can see in the editor, that file has multiple images. 

2. After shortcut is created by Windows Installer, I tried go to
"Properties/Change Icon" to find out what are the actual icon settings,
but editing of the properties was disabled.

   I did not put (at least explicitly) any user account restrictions in
my Wix files, and I use domain account with administrator privileges.

System is Windows XP. 
   Is it possible to "unlock" for edditing properties of installed
shortcut? 


I'd appreciate any help or ideas about above problems. 

Igor M 

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

Re: [WiX-users] What exactly is SourceDir?

[Arnette, Bill]

The default value for TARGETDIR [1] is C:\ but tools like VS.NET setup and 
deployment projects add a type 51 CA (set property from formatted text) to set 
TARGETDIR to [ProgramFilesFolder][Manufacturer]\[ProductName].  Also TARGETDIR 
can be specified on the command line to specify where you want the application 
installed.  So Windows Installer defaults TARGETDIR to C:\ (actually ROOTDRIVE 
property) if TARGETDIR was not specified by a certain point (CostFinalize) in 
the installation sequence.

The WiX convention seems to be to set INSTALLDIR to the above path and leave 
TARGETDIR at its default.

A VS.NET setup and deployment looks something like this in WiX:


   
  
   






   
   TARGETDIR=""



   
   TARGETDIR=""


Here's some references...
[1] TARGETDIR docs - http://msdn2.microsoft.com/en-us/library/aa372064.aspx
[2] SourceDir docs - http://msdn2.microsoft.com/en-us/library/aa371857.aspx


-Original Message-
From: [EMAIL PROTECTED] on behalf of Anthony Wieser
Sent: Sat 3/24/2007 3:01 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] What exactly is SourceDir?
 
In all of the samples you see fragments like this:


 
  

   
  
   

  
 
   

I don't really understand what the SourceDir is above, even though it seems 
to be required (you get a warning if it's not there).

Looking through the logs, the SourceDir always seems to be set to the path 
of the msi file that's run, if its on a network, or even a drive created by 
subst.

However, the TARGETDIR seems always to be set to C:\

Also, why are the other directories listed as a child of TARGETDIR, when 
they can in fact be located anywhere in the file system.  Is it just a 
pragmatic solution, that requires a single top level node for parsing?

Anthony Wieser
Wieser Software Ltd


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

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

Re: [WiX-users] Shortcut targeting file in a different component?

[Arnette, Bill]

Try Target="[#Life_Balance.exe]" in the shortcut element.



-- 
Bill Arnette 
www.signalscape.com 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Stuart A. Malone
> Sent: Wednesday, March 21, 2007 3:27 PM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Shortcut targeting file in a different component?
> 
> 
> Is it possible for a shortcut in one component to target an  
> executable file in a different component?  I can't figure out the  
> right syntax to make this work.
> 
> The reason I'm doing this is to try and give the user the option of  
> whether or not to install a desktop shortcut for our application.   
> The only way I can find of making the shortcut installation optional  
> is to put the shortcut in a separate component, and attach a  
> condition to that component.  Light seems happy with the 
> condition on  
> the component, but is complaining about my attempts to make the  
> shortcut.  I've been trying things like:
> 
>   
> 
>Source="..."/>
>
> 
> 
>   INSTALLDESKTOPSHORTCUT
>Name="Life Balance"
> Advertise="no" Icon="Application.ico" 
> Target="Life_Balance.exe"/>
> 
>   
> 
> But this is giving me errors like:
> 
>   ICE03: Not a valid foreign key; Table: Shortcut, 
> Column: Target, Key 
> (s): DesktopShortcut
> 
>   ICE18: KeyPath for Component: 'DesktopShortcut' is Directory:  
> 'INSTALLDIR'. The Directory/Component pair must be listed in the  
> CreateFolders table.
> 
>   ICE43: Component DesktopShortcut has non-advertised 
> shortcuts. It  
> should use a registry key under HKCU as its KeyPath, not a file.
> 
>   ICE57: Component 'DesktopShortcut' has both per-user 
> and per-machine  
> data with a per-machine KeyPath.
> 
> If there is a better solution for this problem, I'd love to hear it.
> 
> 
> Thanks,
> 
> --Stuart A. Malone
>Llamagraphics, Inc.
>Makers of Life Balance personal coaching software
>http://www.llamagraphics.com/
> 
> 
> 
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys-and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
&CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

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

Re: [WiX-users] vs. CA

[Arnette, Bill]

You would have to do a custom action to set the property from a property
and you can condition the execution of that.
 

 
MYOLDVER
 




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Levi
Wilson
Sent: Thursday, January 25, 2007 11:53 AM
To: Lorne Laliberte
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]  vs. CA


This does help, thank you!  One caveat to this, the old
installation has a registry key named "Path" that contains the path to
its installation directory.  The settings folder is would be in a
settings subdirectory of this.  In the  I cannot reference
this like "[MYOLDVER]\settings" since it violates the pattern of
SourceProperty.  Also, I cannot set my SourceName="settings\*.*" either
because the '\' violates that property.  I'm sorry if I'm being obtuse
about this, but do I need to set ANOTHER property as well?  What would
happen if I had this: 


  
 



Wouldn't my "MYOLDSETTINGS" property be set to "\Settings" if
"MYOLDVER" was empty?  I would try this, but I don't have an environment
setup with this yet.  Thanks for the help! 



On 1/25/07, Lorne Laliberte <[EMAIL PROTECTED]> wrote: 

You can actually put a  element inside your
 element, and set its condition
that way. The
condition will apply to the entire component, which in
this case 
contains your  element.

From the WiX docs: "Under a Component element, the
condition becomes the
condition of the component."

What you want is something like this:

 
  

   
  MYOLDVER 

  


Hope that helps. :)

Lorne Laliberte
Indigo Rose Software




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On
Behalf Of Levi
Wilson
Sent: Thursday, January 25, 2007 9:50 AM 
To: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users]  vs. CA


I forgot to mention that both versions can
coexist on the 
machine.


On 1/25/07, Levi Wilson
<[EMAIL PROTECTED] > wrote:

If I detect an older version of a
product (via a
 and set into "MYOLDVER") I would like
to take settings 
files installed for that version, and copy them into the
newer version's
settings folder.  Would the best way be to do a CA to do
this?  I saw
the  element, but it doesn't appear that you
can specify a 
condition on this.  To use the copy file would I have to
do this:


  
 
   
 
  


And then in my  tree put the
condition like 
this:

MYOLDVER

Is that correct?  Is there a better way
to do this?
Thanks in advance.







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

Re: [WiX-users] Running a file after installation

[Arnette, Bill]

Ah...  I was basing my suggestion off of  Patrick's code.  For your code try:

For (1):


For (2):


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Matador2k7
> Sent: Tuesday, January 23, 2007 10:32 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Running a file after installation
> 
> 
> Hi!
> Thanks for your help, but now I got this message when I try 
> to light my
> wixobj file.
> 
> error LGHT0112 : Unresolved reference to symbol 'Directory:INSTALLDIR'
> 
> 
> Arnette, Bill wrote:
> > 
> > Two suggestions:
> > 
> > 1) Pass the path to the batch file on the batch file 
> invocation command
> > line and then CD to that path in the script.
> > 
> > >  ExeCommand='"[INSTALLDIR]My.bat" "[INSTALLDIR]"' 
> Return='asyncNoWait'
> > />
> > 
> > And then in your my.bat file:
> >Rem Gets the path of my .bat file from the command line
> >Set MYPATH=%1%
> > 
> >Rem CD to my path
> >Cd /D %MYPATH%
> > 
> >Rem Run the driver installer
> >Setupdrv.exe installs
> > 
> > 2) Change your batch file a little to get its own location 
> and CD there.
> > 
> > > ExeCommand='[INSTALLDIR]My.bat' Return='asyncNoWait' />
> > 
> > And then in my.bat:
> >Rem Get the path of my.bat file. 
> >Rem %0 is the path to the batch file
> >Set MYPATH=%~dp0%
> > 
> >Rem CD to my path
> >Cd /D %MYPATH%
> > 
> >Rem Run the driver installer
> >Setupdrv.exe installs
> >  
> > Personally, I like #2 better.
> > 
> >> -Original Message-
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf Of 
> >> Matador2k7
> >> Sent: Tuesday, January 23, 2007 9:30 AM
> >> To: wix-users@lists.sourceforge.net
> >> Subject: Re: [WiX-users] Running a file after installation
> >> 
> >> 
> >> Hi Patrick!
> >> 
> >> First of all, thank you very much for your post, but it 
> >> didn´t work so, now,
> >> I will detail my case a little bit more:
> >> 
> >> The installer creates in the ProgramFilesFolder a folder 
> >> called UltraVNC.
> >> And, in the folder UltraVNC a new folder is created called 
> >> driver. So the
> >> structure should be: %PROGRAMFILES%\UltraVNC\driver
> >> 
> >> In the driver dir, I have an .inf file and some dll's that 
> should be
> >> installed. For this, I must use this command line: 
> >> "setupdrv.exe installs"
> >> or simply a .bat file with this command line.
> >> It is necessary that it is launched from this dir, because 
> if not, the
> >> driver will not be installed so I don't mind hard-coding it...
> >> 
> >> If I use this one: Directory="INSTALLDIR" which dir is taken? 
> >> The driver dir
> >> or the UltraVNC dir?
> >> 
> >> Thanks!
> >> 
> >> 
> >> Patrick Steele-2 wrote:
> >> > 
> >> > Try somethinbg like this:
> >> > 
> >> >  >> > ExeCommand='[INSTALLDIR]My.bat' Return='asyncNoWait' />
> >> > 
> >> > 
> >> > NOT
> >> > Installed
> >> > 
> >> > 
> >> > This way you are also not hard coding the directory 
> >> location of the batch
> >> > file and you are only running it during the install, not 
> >> the uninstall,
> >> > after all files have been added.
> >> > 
> >> > Patrick
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > 
> >> > -Original Message-
> >> > From: [EMAIL PROTECTED]
> >> > [mailto:[EMAIL PROTECTED] On Behalf 
> >> Of Matador2k7
> >> > Sent: 23 January 2007 11:35
> >> > To: wix-users@lists.sourceforge.net
> >> > Subject: [WiX-users] Running a file after installation
> >> > 
> >> > 
> >> > Hello.
> >> > I'm making an MSI installer for Ultra VNC in my company. 
> Now I got a
> >> > little
> >> > problem:
> >> > 
> >> > I copy some files into this folder: C:\ARCHIVOS DE
> >> > PROGRAMA\ULTRAVNC\DRIVER
> >> > 
> >&g

Re: [WiX-users] Running a file after installation

[Arnette, Bill]

Two suggestions:

1) Pass the path to the batch file on the batch file invocation command line 
and then CD to that path in the script.

   

And then in your my.bat file:
   Rem Gets the path of my .bat file from the command line
   Set MYPATH=%1%

   Rem CD to my path
   Cd /D %MYPATH%

   Rem Run the driver installer
   Setupdrv.exe installs

2) Change your batch file a little to get its own location and CD there.

   

And then in my.bat:
   Rem Get the path of my.bat file. 
   Rem %0 is the path to the batch file
   Set MYPATH=%~dp0%

   Rem CD to my path
   Cd /D %MYPATH%

   Rem Run the driver installer
   Setupdrv.exe installs
 
Personally, I like #2 better.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Matador2k7
> Sent: Tuesday, January 23, 2007 9:30 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Running a file after installation
> 
> 
> Hi Patrick!
> 
> First of all, thank you very much for your post, but it 
> didn´t work so, now,
> I will detail my case a little bit more:
> 
> The installer creates in the ProgramFilesFolder a folder 
> called UltraVNC.
> And, in the folder UltraVNC a new folder is created called 
> driver. So the
> structure should be: %PROGRAMFILES%\UltraVNC\driver
> 
> In the driver dir, I have an .inf file and some dll's that should be
> installed. For this, I must use this command line: 
> "setupdrv.exe installs"
> or simply a .bat file with this command line.
> It is necessary that it is launched from this dir, because if not, the
> driver will not be installed so I don't mind hard-coding it...
> 
> If I use this one: Directory="INSTALLDIR" which dir is taken? 
> The driver dir
> or the UltraVNC dir?
> 
> Thanks!
> 
> 
> Patrick Steele-2 wrote:
> > 
> > Try somethinbg like this:
> > 
> >  > ExeCommand='[INSTALLDIR]My.bat' Return='asyncNoWait' />
> > 
> > 
> > NOT
> > Installed
> > 
> > 
> > This way you are also not hard coding the directory 
> location of the batch
> > file and you are only running it during the install, not 
> the uninstall,
> > after all files have been added.
> > 
> > Patrick
> > 
> > 
> > 
> > 
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf 
> Of Matador2k7
> > Sent: 23 January 2007 11:35
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Running a file after installation
> > 
> > 
> > Hello.
> > I'm making an MSI installer for Ultra VNC in my company. Now I got a
> > little
> > problem:
> > 
> > I copy some files into this folder: C:\ARCHIVOS DE
> > PROGRAMA\ULTRAVNC\DRIVER
> > 
> > In this folder exists a file called install_silent.bat
> > 
> > Now, I'd liked to run this file AFTER installation, in 
> order to get the
> > driver installed. I'm doing it right this at the moment:
> > 
> > 
> >  ExeCommand="[DRIVER]install_silent.bat"
> > Return='asyncNoWait'/>
> > 
> > The problem is that the driver isn´t installed. Am I using the right
> > syntax for this job?
> > 
> > Thanksss!
> > --
> > View this message in context:
> > 
> http://www.nabble.com/Running-a-file-after-installation-tf3063
> 560.html#a8519908
> > Sent from the wix-users mailing list archive at Nabble.com.
> > 
> > 
> > 
> --
> ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the 
> chance to share
> > your
> > opinions on IT & business topics through brief surveys - 
> and earn cash
> > 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> > 
> --
> ---
> > Take Surveys. Earn Cash. Influence the Future of IT
> > Join SourceForge.net's Techsay panel and you'll get the 
> chance to share
> > your
> > opinions on IT & business topics through brief surveys - 
> and earn cash
> > 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> > ___
> > WiX-users mailing list
> > WiX-users@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/wix-users
> > 
> > 
> 
> -- 
> View this message in context: 
> http://www.nabble.com/Running-a-file-after-installation-tf3063
> 560.html#a8522632
> Sent from the wix-users mailing list archive at Nabble.com.
> 
> 
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> ___

Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?

[Arnette, Bill]

 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> André Pönitz
> Sent: Thursday, December 21, 2006 3:20 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Installed: Local; Request: Absent; 
> Action: Null ?
> 
> Arnette, Bill wrote:
> > Non-Windows Installer installers use the SharedDlls registry 
> > key to refcount the usage of common/shared dlls.  By default 
> > Windows Installer will only increment that refcount if it 
> > already exists so that the other installer will track the 
> > refcount properly if a WI installer installs the same file. 
> > Windows Installer also maintains its own refcount for 
> > components it tracks elsewhere.  You can force Windows 
> > Installer to create a SharedDLLs entry if it doesn't already 
> > exist with the msidbComponentAttributesSharedDllRefCount 
> > attribute on a component.
> 
> So this is what the SharedDllRefCount='yes' attribute means...
> 
> Let me try to get the consequences for me straight: if I have
> an old installer using the SharedDll mechanism and new installers
> are msi based (and will stay so for the forseeable future) I 
> would not have to explicitly use SharedDllRefCount='yes' and
> it'd still work if I install my newer version in parallel (yes,
> we do that...) to the older version and I could deinstall
> in arbitrary order.

As I understand it, yes; theoretically :)

> 
> It would not work, however, if I installed the new version first 
> and than the older one in parallel. But as that's not a 
> scenario I need to support, I'd be ok without using the
> SharedDllRefCount='yes' attribute.
> 
> Did I get that right?

Right, because unless you explicitly tell MSI to use SharedDllRefCount, the 
other/older installer is unaware that the MSI-installed product/version is 
sharing that file.


> 
> > So what that log indicates is that a non-WI installer 
> > installed that file before your product was installed and 
> > that since the SharedDlls refcount will not go to 0 after 
> > your product is uninstalled, the file will not be removed so 
> > that the other product is not broken.
> 
> Ok, that's probably exactly what happens as I have an
> older version installed (or at least not fully uninstalled)
> 
> Thanks for the explanation,
> Andre'

Glad I could help.


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

Re: [WiX-users] Installed: Local; Request: Absent; Action: Null ?

[Arnette, Bill]

Non-Windows Installer installers use the SharedDlls registry key to refcount 
the usage of common/shared dlls.  By default Windows Installer will only 
increment that refcount if it already exists so that the other installer will 
track the refcount properly if a WI installer installs the same file.  Windows 
Installer also maintains its own refcount for components it tracks elsewhere.  
You can force Windows Installer to create a SharedDLLs entry if it doesn't 
already exist with the msidbComponentAttributesSharedDllRefCount attribute on a 
component.

So what that log indicates is that a non-WI installer installed that file 
before your product was installed and that since the SharedDlls refcount will 
not go to 0 after your product is uninstalled, the file will not be removed so 
that the other product is not broken.



> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> André Pönitz
> Sent: Wednesday, December 20, 2006 6:50 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Installed: Local; Request: Absent; 
> Action: Null ?
> 
>  
> 
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of 
> > André Pönitz
> > Sent: Wednesday, December 20, 2006 12:34 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Installed: Local; Request: Absent; 
> Action: Null ?
> > 
> > 
> > 
> > Can anybody explain me why I get the 'Action: Null' 
> > "decision" in some cases, but not in all?
> > 
> > MSI (s) (68:C0) [12:28:49:678]: Component: Hasp_52; 
> > Installed: Local;   Request: Absent;   Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmProgramMenu; 
> > Installed: Local;   Request: Absent;   Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component: 
> > NetlmProgramMenuWasyTools; Installed: Local;   Request: 
> > Absent;   Action: Absent
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_1; 
> > Installed: Local;   Request: Absent;   Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_2; 
> > Installed: Local;   Request: Absent;   Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClient32_3; 
> > Installed: Local;   Request: Absent;   Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: NetlmClientHelp; 
> > Installed: Local;   Request: Absent;   Action: Null
> > MSI (s) (68:C0) [12:28:49:678]: Component: 
> > NetlmClientProgramMenu; Installed: Local;   Request: Absent;  
> >  Action: Absent
> > 
> > A difference is that the 'Client' is in an Fragment, the rest 
> > is in the main body of the installer.
> 
> 
> Some more information from the log:
> 
> MSI (s) (68:E4) [12:40:17:485]: Executing op: 
> ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137E
> AABD18C},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {E88B9844-688B-40FA-8BD3-E137EAABD18C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={E88B9844-688B-40FA-8BD3-E137E
> AABD1DA},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {E88B9844-688B-40FA-8BD3-E137EAABD1DA}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 131390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {F0A3B0D2-F9C6-C00F-8817-DAAC3131390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 231390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {F0A3B0D2-F9C6-C00F-8817-DAAC3231390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 331390C},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {F0A3B0D2-F9C6-C00F-8817-DAAC3331390C}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={F0A3B0D2-F9C6-C00F-8817-DAAC3
> 1313AAA},,BinaryType=0,PreviouslyPinned=1)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {f0a3B0D2-F9C6-C00F-8817-DAAC31313AAA}
> MSI (s) (68:E4) [12:40:17:501]: Executing op: 
> ComponentUnregister(ComponentId={E88B9844-688B-C00F-8BD3-E137E
> AA1D18C},,BinaryType=0,)
> 1: {7C474FFC-9D30-C00F-B086-5B7008640158} 2: 
> {E88B9844-688B-C00F-8BD3-E137EAA1D18C}
> 
> The not-removed componets are the ones that have the 
> 'PreviouslyPinned=1' part which a Google Search turns into
> entries in:
> 
> HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\S
> haredDlls
> 
> Now the question: By what installer mechanism do entries turn 
> up in this
> location and under which circumstances are they useful?
> 
> 
> Andre'
> 
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through 

Re: [WiX-users] Renaming a file during installation

[Arnette, Bill]

You're probably better off either:

A) Copy the file from the template in a custom action.

OR

B) Have the application copy the file from the template to the user's
application data folder if it doesn't already exist.

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Rob Hamflett
> Sent: Wednesday, November 29, 2006 11:45 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Renaming a file during installation
> 
> CopyFile has to live in a component, and it will now what the 
> destination file is called.  You could 
> end up with the two instances of the component installed, but 
> each referring to a different file. 
> If you uninstall one of the products it won't delete the file 
> because there's another product that 
> needs it.  If you remove the other product, it will delete 
> one file, but leave the other.  You could 
> also end up in trouble if the user performs a repair and you 
> replace the wrong file.
> 
> Rob
> 
> Sorin Radulescu wrote:
> > Rob, thanks for your reply.
> > 
> > I have this file that I want to rename that acts like a 
> template and I have
> > to rename it based on the user's input. I don't see a 
> problem if the user
> > specifies different names on each occasion - in fact this 
> is how it should
> > work. Is any danger in this?
> > 
> > Thank you,
> > 
> > Sorin
> > 
> > 
> > Rob Hamflett wrote:
> >> That sounds dangerous.  What if that component gets 
> installed twice, but
> >> on each occasion the user 
> >> specifies a different name?
> >>
> >> Rob
> >>
> >> Sorin Radulescu wrote:
> >>> Hello,
> >>>
> >>> I am trying to rename a file that is coming with my 
> installer. The new
> >>> name
> >>> of the file should be based on a value set by the user in 
> one of the
> >>> dialogs. So far I've tried different combinations of File 
> and CopyFile
> >>> but
> >>> with no luck.
> >>>
> >>> Is there a way to do this using WiX?
> >>>
> >>> My WiX version: 2.0.4611.0
> >>>
> >>> Thank you,
> >>>
> >>> Sorin
> >>>
> >>>
> >>
> >> 
> --
> ---
> >> Take Surveys. Earn Cash. Influence the Future of IT
> >> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share
> >> your
> >> opinions on IT & business topics through brief surveys - 
> and earn cash
> >> 
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> >> ___
> >> WiX-users mailing list
> >> WiX-users@lists.sourceforge.net
> >> https://lists.sourceforge.net/lists/listinfo/wix-users
> >>
> >>
> > 
> 
> 
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

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

Re: [WiX-users] question

[Arnette, Bill]

The issue is that we use the App Path\Path registry value to specify
additional paths for our application.  We use the full name of the
application which is longer than 8.3.  But because the verb registration
uses the short path name, the App Path entry is not found when the
application is launched by clicking on a document for our application,
and so the dependent dlls are not found.  

I could add an App Path\Path entry based on the short name, except I
don't think I can reliably deduce the short name to register.  Most
likely it will be BLAH~1.EXE, but can I guarantee that?



> -Original Message-
> From: Bob Arnson [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 22, 2006 4:43 PM
> To: Mike Dimmick
> Cc: Arnette, Bill; wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users]  question
> 
> Mike Dimmick wrote:
> > It may well have problems if you use a long path with
> > spaces in it. This might be considered a bug (I'm not sure 
> if Windows
> > Installer would properly quote a [#TargetFileId] expansion). 
> 
> It doesn't add quotes, whether they're needed or not. Hence the short 
> path recommendation.
> 
> -- 
> sig://boB
> http://bobs.org
> 
> 

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

[WiX-users] question

[Arnette, Bill]

Why does Wix.chm say this about Verb/@Target?

Target file to be executed for the verb. The value should be a formatted
Property to refer to the *short path to the file*, for example:
[!TargetFileId]. Only valid for non-Advertised verbs.


I see no such restriction in the Platform SDK docs about the Verb table
Target column referring to the short path of a file.







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

Re: [WiX-users] way to create merge module and avoiding codeduplication

[Arnette, Bill]

So how do you replace a merge module with a wixlib.  A merge module has
a cab with the files to be installed in it.  AFAIK, a wixlib has no way
transporting the files to be installed to the final MSI.  So it seems to
me that to use a wixlib, you need the wixlib and the binaries to be
installed by the wixlib.  Correct?  

The problem we have is that we are trying to include some components
from an older product with a newer product.  The older product
references the binaries to be installed with a compiler variable set to
"..\stage\product\bin" while the new product references them with
"stage\product\bin".  The newer product is the staging convention going
forward.  So it seems we will have to revamp the older product's build
to stage everything like the new product.  Correct?

> -Original Message-
> From: Bob Arnson [mailto:[EMAIL PROTECTED] 
> Sent: Wednesday, November 15, 2006 7:08 PM
> To: Arnette, Bill
> Cc: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] way to create merge module and 
> avoiding codeduplication
> 
> Arnette, Bill wrote:
> > A merge module should never deliver a component containing 
> system files
> > to the main feature of an application, because this may cause the
> > Installer to validate and repair the application each time 
> the system
> > file is used. A .msi file that is intended to accept 
> components from a
> > merge module should be authored so that any components that contain
> > system files only belong to features that are separate from the main
> > feature of the application.
> >
> > If your package uses a merge module containing system files 
> that link
> > all the components from the merge module to the main feature of the
> > application, an attempt to use the system file may trigger 
> the Installer
> > to try and repair the main feature of the application. If the main
> > feature cannot be repaired, the installation may fail.
> >
> > ---
> >
> > I presume "system files" are main application files in this context.
> >   
> 
> I don't think that's the case. The original intent for merge modules 
> wasn't to do composition; it was focused on redistributable 
> components, 
> so "system files" probably means files that get installed into shared 
> directories. An advertised shortcut does a resiliency check on the 
> feature the shortcut points to, so as a general rule, the fewer 
> components in that feature, the better/faster -- regardless 
> of whether 
> they come from merge modules.
> 
> That said, merge modules are on the decline, as you can't patch all 
> consumers of a merge module. (Remember Slammer? It was so bad because 
> MSDE distributed via merge modules couldn't get the patch.) Microsoft 
> publishes very few merge modules these days. Avoid them if you can.
> 
> -- 
> sig://boB
> http://bobs.org
> 
> 
> 

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

Re: [WiX-users] way to create merge module and avoiding codeduplication

[Arnette, Bill]

If you do that, how do you resolve it against this:

http://msdn2.microsoft.com/en-us/library/aa368034.aspx:
A merge module should never deliver a component containing system files
to the main feature of an application, because this may cause the
Installer to validate and repair the application each time the system
file is used. A .msi file that is intended to accept components from a
merge module should be authored so that any components that contain
system files only belong to features that are separate from the main
feature of the application.

If your package uses a merge module containing system files that link
all the components from the merge module to the main feature of the
application, an attempt to use the system file may trigger the Installer
to try and repair the main feature of the application. If the main
feature cannot be repaired, the installation may fail.

---

I presume "system files" are main application files in this context.
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Bob Arnson
> Sent: Wednesday, November 15, 2006 2:19 AM
> To: vij
> Cc: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] way to create merge module and 
> avoiding codeduplication
> 
> vij wrote:
> > In our project we have to create MSI package of our product 
> and also 
> > need to distribute our product as redistributable merge module.
> 
> Build the merge module with your components and then consume 
> the merge 
> module in your product .msi.
> 
> -- 
> sig://boB
> http://bobs.org
> 
> 
> 
> --
> ---
> Take Surveys. Earn Cash. Influence the Future of IT
> Join SourceForge.net's Techsay panel and you'll get the 
> chance to share your
> opinions on IT & business topics through brief surveys - and earn cash
> http://www.techsay.com/default.php?page=join.php&p=sourceforge
> &CID=DEVDEV
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

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

Re: [WiX-users] Property name to be used in MsiGetProperty

[Arnette, Bill]

Forgot to add this link:

http://msdn.microsoft.com/library/en-us/msi/setup/obtaining_context_info
rmation_for_deferred_execution_custom_actions.asp?frame=true
 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Arnette, Bill
> Sent: Wednesday, November 08, 2006 11:02 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> 
> Your CAs are all deferred so there is a very small subset of 
> properties
> you can get with MsiGetProperty.  Parameters are passed to deferred
> custom actions in a property called CustomActionData.  To set
> CustomActionData, you have to use another custom action to set a
> property with the same name as the deferred custom action to a string
> with the value(s) you want to pass to the custom action.  If you have
> multiple data items you need to pass, you will need to pass 
> them like a
> command line that your CA code will parse
> 
> 
> 
> 
> Property="CA2" Value="/switch1  /arg2=value2" />
> 
> 
> BinaryKey="mycustom.dll" DllEntry="CAFunction2"
>HideTarget="no"/>
> 
> 
>
>  
> 
> 
> Then in CAFunction2() retrieve CustomActionData with:
>  MsiGetProperty (hInstall, L"CustomActionData", szActionData,
> &dwActionData);
> 
> CAFunction2 will have to parse szActionData like a commandline to
> retrieve the arguments.
> 
> 
> 
> 
> > > < 
> somecondition
> > >> 
> > > < somecondition
> > >
> > -Original Message-
> > From: [EMAIL PROTECTED] 
> > [mailto:[EMAIL PROTECTED] On Behalf Of 
> > Pallavi Patrutkar
> > Sent: Wednesday, November 08, 2006 6:01 AM
> > To: wix-users@lists.sourceforge.net
> > Cc: Rob Hamflett
> > Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> > 
> > I wrote the code according to the sample given in online MSDN doc.
> > 
> > So, you have to call MsiGetProperty() method twice.
> > In 1st call, you get the length of the actual value, passed as a 4th
> > parameter of MsiGetProperty() and return value comes as 
> > ERROR_MORE_DATA
> > which is correct according to doc.
> > In 2nd call, you have to pass this length as 4th parameter 
> and for 3rd
> > parameter, construct a string array with the size as above 
> length +1.
> > This call returns ERROR_SUCCESS, which is also according to the doc.
> > 
> > So, I am wondering whether I am using the correct string as a 2nd
> > parameter to MsiGetProperty() or not.
> > 
> > Can you tell me if there is any problem in this call as I 
> > have mentioned
> > in my previous email?
> > 
> > Regards,
> > Pallavi.
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> > Hamflett
> > Sent: Wednesday, November 08, 2006 4:17 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> > 
> > Ah, OK.  It just wasn't clear from your first post.  What's 
> the return
> > value for MsiGetProperty?
> > 
> > Rob
> > 
> > Pallavi Patrutkar wrote:
> > > Hi,
> > > 
> > > I have a customaction and property as defined below in WIX file
> > > 
> > > 
> > > 
> > > 
> > >  > > Property="CA_Arguments1"  Value="" />
> > >  > > BinaryKey="mycustom.dll" DllEntry="CAFunction1" HideTarget="no"/>
> > >   
> > > 
> > >  > > Property="CA_Arguments2"  Value="" />
> > >  > > BinaryKey="mycustom.dll" DllEntry="CAFunction2"
> > > HideTarget="no"/>
> > > 
> > > 
> > > < 
> > somecondition
> > >> 
> > >  > After="CA_SetProperty1">
> > > < 
> somecondition
> > >> 
> > > < somecondition
> > >
> > > ---
> > > I am calling method in C++ source file as below - 
> > > 
> > > MsiGetProperty (hInstall, L"CA_Arguments1", szActionData,
> > > &dwActionData);
> > > MsiGetProperty (hInstall, L"CA_Arguments2", szActionData,
> > > &dwActionData);
> > > 
> > > But, I am getting dwActionData value as zero. And I nowhere 
> > got in any
> &g

Re: [WiX-users] Property name to be used in MsiGetProperty

[Arnette, Bill]

Your CAs are all deferred so there is a very small subset of properties
you can get with MsiGetProperty.  Parameters are passed to deferred
custom actions in a property called CustomActionData.  To set
CustomActionData, you have to use another custom action to set a
property with the same name as the deferred custom action to a string
with the value(s) you want to pass to the custom action.  If you have
multiple data items you need to pass, you will need to pass them like a
command line that your CA code will parse










   
 


Then in CAFunction2() retrieve CustomActionData with:
 MsiGetProperty (hInstall, L"CustomActionData", szActionData,
&dwActionData);

CAFunction2 will have to parse szActionData like a commandline to
retrieve the arguments.




> > < somecondition
> >> 
> > < somecondition
> >
> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Pallavi Patrutkar
> Sent: Wednesday, November 08, 2006 6:01 AM
> To: wix-users@lists.sourceforge.net
> Cc: Rob Hamflett
> Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> 
> I wrote the code according to the sample given in online MSDN doc.
> 
> So, you have to call MsiGetProperty() method twice.
> In 1st call, you get the length of the actual value, passed as a 4th
> parameter of MsiGetProperty() and return value comes as 
> ERROR_MORE_DATA
> which is correct according to doc.
> In 2nd call, you have to pass this length as 4th parameter and for 3rd
> parameter, construct a string array with the size as above length +1.
> This call returns ERROR_SUCCESS, which is also according to the doc.
> 
> So, I am wondering whether I am using the correct string as a 2nd
> parameter to MsiGetProperty() or not.
> 
> Can you tell me if there is any problem in this call as I 
> have mentioned
> in my previous email?
> 
> Regards,
> Pallavi.
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> Hamflett
> Sent: Wednesday, November 08, 2006 4:17 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> 
> Ah, OK.  It just wasn't clear from your first post.  What's the return
> value for MsiGetProperty?
> 
> Rob
> 
> Pallavi Patrutkar wrote:
> > Hi,
> > 
> > I have a customaction and property as defined below in WIX file
> > 
> > 
> > 
> > 
> >  > Property="CA_Arguments1"Value="" />
> >  > BinaryKey="mycustom.dll" DllEntry="CAFunction1" HideTarget="no"/>
> > 
> > 
> >  > Property="CA_Arguments2"Value="" />
> >  > BinaryKey="mycustom.dll" DllEntry="CAFunction2"
> > HideTarget="no"/>
> > 
> > 
> > < 
> somecondition
> >> 
> >  After="CA_SetProperty1">
> > < somecondition
> >> 
> > < somecondition
> >
> > ---
> > I am calling method in C++ source file as below - 
> > 
> > MsiGetProperty (hInstall, L"CA_Arguments1", szActionData,
> > &dwActionData);
> > MsiGetProperty (hInstall, L"CA_Arguments2", szActionData,
> > &dwActionData);
> > 
> > But, I am getting dwActionData value as zero. And I nowhere 
> got in any
> > documentation that which string from the above WIX code 
> should be used
> > as 2nd argument for the above method. So, I am just 
> wondering whether
> I
> > am using correct string or not.
> > 
> > Please help.
> > 
> > Regards,
> > Pallavi.
> > 
> > 
> > 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Rob
> > Hamflett
> > Sent: Wednesday, November 08, 2006 2:33 PM
> > To: wix-users@lists.sourceforge.net
> > Subject: Re: [WiX-users] Property name to be used in MsiGetProperty
> > 
> > How are you passing a custom value to your DLL?  I thought that you
> > could only receive a handle to 
> > the MSI package.  Are you sure the property name in the DLL is
> correct?
> > 
> > Rob
> > 
> > Pallavi Patrutkar wrote:
> >> Hello,
> >>
> >>  
> >>
> >> I am trying to pass a property to a method in a DLL. But I am not 
> >> getting the actual property value in my DLL through MsiGetProperty.
> >>
> >> It returns the length of parameter as zero. But still 
> method returns 
> >> successfully.
> >>
> >> Can you tell me exactly which string from WXS file should I pass to
> > this 
> >> method as a 2^nd parameter to get the correct property value?
> >>
> >>  
> >>
> >> Thank you,
> >>
> >>  
> >>
> >> Regards,
> >>
> >> Pallavi.
> >>
> >>
> >>
> >
> --
> --
> >>
> >
> --
> --
> > -
> >> Using Tomcat but need to do more? Need to support web services,
> > security?
> >> Get stuff done quickly with pre-integrated technology to make your
> job
> > easier
> >> Download IBM WebSphere Application Server v.1.0.1 based on Apache
> > Geronimo
> >
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&;
> dat=121642
> >>
> >>
> >
> -

Re: [WiX-users] Multiple parameters in CA dll

[Arnette, Bill]

An immediate custom action has access to the property 
table, so put your parameters in properties and use MsiGetProperty to retrieve 
them in your CA.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Bahar 
  ShahSent: Friday, November 03, 2006 9:44 AMTo: 
  wix-users@lists.sourceforge.netSubject: [WiX-users] Multiple 
  parameters in CA dll
  Is there a way to pass multiple parameter to a function in a CA dll 
  ?Say I need to pass 3 paramater to a function in my dll ?Can I pass 
  parameter to CA scheduled for  imediate action and not deffered 
  Regards Bahar
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] CustomAction not being called

[Arnette, Bill]

Make sure that is the entry point of the DLL.  An exported __stdcall
function is actually decorated to be [EMAIL PROTECTED] so try setting
DllEntry to [EMAIL PROTECTED]  If that works, you can
alias the export with the with /EXPORT:[EMAIL PROTECTED]
option on the linker command line.
 
Use:
dumpbin /EXPORTS wildcaddysetup.dll

To see the decorated exported DLL entry point names.

Bill




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Jeff Jones
(HS)
Sent: Wednesday, October 18, 2006 4:13 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] CustomAction not being called


I am trying to run a custom action.  Right now that
custom action just returns ERROR_SUCCESS but every invocation fails
without even loading the dll.
Here is the log:
 
Action start 10:58:35: InstallCert.
MSI (s) (C4:14) [10:58:35:078]: Creating MSIHANDLE (1) of type
790542 for thread 2836
MSI (s) (C4:04) [10:58:35:078]: Invoking remote custom action.
DLL: C:\WINDOWS\Installer\MSI3EB5.tmp, Entrypoint:
InstallApplicationCertificate
MSI (s) (C4:BC) [10:58:35:078]: Generating random cookie.
MSI (s) (C4:BC) [10:58:35:078]: Created Custom Action Server
with PID 2476 (0x9AC).
MSI (s) (C4:38) [10:58:35:109]: Running as a service.
MSI (s) (C4:38) [10:58:35:125]: Hello, I'm your 32bit
Impersonated custom action server.
MSI (s) (C4:04) [10:58:35:125]: Closing MSIHANDLE (1) of type
790542 for thread 2836
Action ended 10:58:35: InstallCert. Return value 3.
 
I have verified the DLL has the appropriate export and here are
the related WIX tags:
 

 



 

 
Anyone have any idea what I might be doing wrong?  What does
"Return value 3" mean?  Is it ERROR_PATH_NOT_FOUND?  If so, shouldn't
the Binary tag setup the correct temporary path?
 
Jeff
 


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Install with prevous versions

[Arnette, Bill]

So your recommendation is to run the uninstaller as a deferred CA or
just in the InstallExecuteSequence? 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Wilson, Phil
> Sent: Wednesday, October 18, 2006 4:41 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Install with prevous versions
> 
> Some thoughts:
> 
> Those non-MSI uninstallers often have a quiet switch, so if there's no
> need to show the uninstall UI append that to the uninstall string. I
> know the InstallShield one does, I'd expect the Wise 
> equivalent to have
> the same. 
> 
> I don't think it's a good idea to have the uninstall custom action in
> both the UI and execute sequences. There's the general point that you
> shouldn't really be changing the system in the UI stage, and it will
> probably bite you on Vista because you probably won't have 
> the required
> privilege in the UI sequence (with UAC you'll be a standard 
> user; in the
> execute sequence you'll be elevated). 
> 
> 
> Phil Wilson 
> 
> 
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Arnette,
> Bill
> Sent: Wednesday, October 18, 2006 7:01 AM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Install with prevous versions
> 
> 
> I don't think there are any path manipulation capabilities in MSI, so
> you'll have to write a CA that sets INSTALLDIR from OLDINSTALL3 or
> OLDINSTALL4.  
> 
> You can set a property in a CA if it is an immediate (not deferred) CA
> using MsiSetProperty.  Set the CA's @Execute attribute to
> 'oncePerProcess' and schedule it in both the InstallUISequence and
> InstallExecuteSequence so that the CA will run even if the UI is
> bypassed but it will only run once if the UI is enabled.  You can
> condition the execution of the CA on whether OLDINSTALL3 or 
> OLDINSTALL4
> are non-empty.  I am not sure exactly where to schedule it 
> though; maybe
> after FindRelatedProducts?  
> 
> I have a related question.  I am working with the same issue;
> uninstalling previous versions that were not MSI installs.  
> 
> This is what I did:
> 
>  Execute="oncePerProcess" BinaryKey="MyCAs"
> DllEntry="UninstallOldProducts" />
> 
> 
> 
>Key="Software\Microsoft\Windows\CurrentVersion\Uninstall\MyApp"
> Name="DisplayName" Type="raw"/>
> 
> 
> 
>After="FindRelatedProducts">NOT Installed AND OLDPRODUCTFOUND
>  
> 
> 
>   
>After="RemoveExistingProducts">NOT Installed AND
> OLDPRODUCTFOUND
> 
> 
> The RegistrySearch checks that the old product exists on the target
> machine.
> 
> The UninstallOldProducts CA runs the old version's uninstaller (a WISE
> uninstaller) as an immediate CA but only if the old product is found.
> The CA basically just executes the ARP UninstallString.
> 
> The effect is, the user starts the installer, the old 
> installer appears
> to guide the user through uninstalling the old product, then the MSI's
> UI appears.
> 
> I don't know if this is good practice or not.  Maybe the experts could
> chime in here.  Should my bootstrapper handle the 
> uninstallation of the
> previous non-MSI installation?  Or is it OK to do this an immediate CA
> like above?  
> 
> Should the CA be scheduled somewhere else?  I didn't think doing it
> deferred would be good because the user would go through the MSI
> installer UI and then be presented with the WISE uninstaller UI.
> 
> Thoughts?
> 
> 
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of Anton 
> > Filippov
> > Sent: Wednesday, October 18, 2006 7:45 AM
> > To: wix-users@lists.sourceforge.net
> > Subject: [WiX-users] Install with prevous versions
> > 
> > Hello
> > 
> > I write installer in WiX for product.
> > This is new installer and this product already have old versions, 
> > wrote in other installer (NSIS).
> > I search for older versions like this:
> > 
> > 
> >> Key='Software\Microsoft\Windows\CurrentVersion\Uninstall\Solver4'
> > Name='UninstallString' />
> > 
> > 
> >> Key='Software\Microsoft\Windows\CurrentVersion\Uninstall\Solver3'
> > Name='UninstallString' />
> > 
> > 
> > UnsinstallString contains file path for uninstall.exe for older 
> > versions,

Re: [WiX-users] Install with prevous versions

[Arnette, Bill]

I don't think there are any path manipulation capabilities in MSI, so
you'll have to write a CA that sets INSTALLDIR from OLDINSTALL3 or
OLDINSTALL4.  

You can set a property in a CA if it is an immediate (not deferred) CA
using MsiSetProperty.  Set the CA's @Execute attribute to
'oncePerProcess' and schedule it in both the InstallUISequence and
InstallExecuteSequence so that the CA will run even if the UI is
bypassed but it will only run once if the UI is enabled.  You can
condition the execution of the CA on whether OLDINSTALL3 or OLDINSTALL4
are non-empty.  I am not sure exactly where to schedule it though; maybe
after FindRelatedProducts?  

I have a related question.  I am working with the same issue;
uninstalling previous versions that were not MSI installs.  

This is what I did:





  



  NOT Installed AND OLDPRODUCTFOUND
 


  
  NOT Installed AND
OLDPRODUCTFOUND


The RegistrySearch checks that the old product exists on the target
machine.

The UninstallOldProducts CA runs the old version's uninstaller (a WISE
uninstaller) as an immediate CA but only if the old product is found.
The CA basically just executes the ARP UninstallString.

The effect is, the user starts the installer, the old installer appears
to guide the user through uninstalling the old product, then the MSI's
UI appears.

I don't know if this is good practice or not.  Maybe the experts could
chime in here.  Should my bootstrapper handle the uninstallation of the
previous non-MSI installation?  Or is it OK to do this an immediate CA
like above?  

Should the CA be scheduled somewhere else?  I didn't think doing it
deferred would be good because the user would go through the MSI
installer UI and then be presented with the WISE uninstaller UI.

Thoughts?


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Anton Filippov
> Sent: Wednesday, October 18, 2006 7:45 AM
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Install with prevous versions
> 
> Hello
> 
> I write installer in WiX for product.
> This is new installer and this product already have old versions,
> wrote in other installer (NSIS).
> I search for older versions like this:
> 
> 
>Key='Software\Microsoft\Windows\CurrentVersion\Uninstall\Solver4'
> Name='UninstallString' />
> 
> 
>Key='Software\Microsoft\Windows\CurrentVersion\Uninstall\Solver3'
> Name='UninstallString' />
> 
> 
> UnsinstallString contains file path for uninstall.exe for older
> versions, like "C:\program Files\Solver3\uninstall.exe"
> 
> And if OLDINSTALL3 is present, I should set INSTALLDIR to OLDINSTALL3.
> OLDINSTALL4 in same way.
> 
> Question:
> How to remove "...\uninstall.exe" (can I do this without CA 
> type 1, 2, 17, 18)?
> 
> Or If I can't remove this substring standart method, how to set
> INSTALLDIR property from CA?
> As I understood, deferred CA can set only one property with 
> name, like CA Id.
> But how to set other properties?
> 
> Thank you
> 
> --
> ---
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&;
> dat=121642
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [NAnt-users] "Error loading GUID..." when using task forVS2005

[Arnette, Bill]

Drat! Did it again.  Sorry. 

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Arnette, Bill
> Sent: Tuesday, October 17, 2006 2:23 PM
> To: Kumar .S; wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] [NAnt-users] "Error loading GUID..." 
> when using task forVS2005
> 
> You are still using NAnt to drive the build, but msbuild is actually
> compiling the .Net project.  
> 
> I see that NAntContrib [1] has an  task [2] that you 
> would use
> instead of the  task or the  task.
>  
> So, after installing NAntContrib, you could do:
>  
>  
> 
> 
>   
> project="C:\Program
> Files\OMEGA\siebel\src\Transport\Transport.sln" 
>failonerror="true">
>
> 
>   
> 
>   
> 
>  
> 
> 
>  
> [1] http://nantcontrib.sourceforge.net/
> [2]
> http://nantcontrib.sourceforge.net/release/latest/help/tasks/m
> sbuild.htm
> l
>  
>  
>  
>  
>  
> 
> 
> From: Kumar .S [mailto:[EMAIL PROTECTED] 
> Sent: Tuesday, October 17, 2006 1:52 PM
> To: Arnette, Bill
> Subject: Re: [NAnt-users] "Error loading GUID..." when using 
> 
> task forVS2005
> 
> 
> 
>   Hello Arnette,
>
>   So, according to NANT wont support for VS
> 2005. Is that true. U said its not going to support. In what 
> way its not
> supporting. We wont be able to compile. VS 2005 .net applications. 
>
>   Regards,
>   Kumar
> 
> 
> --
> ---
> Using Tomcat but need to do more? Need to support web 
> services, security?
> Get stuff done quickly with pre-integrated technology to make 
> your job easier
> Download IBM WebSphere Application Server v.1.0.1 based on 
> Apache Geronimo
> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&;
> dat=121642
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
> 

-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [NAnt-users] "Error loading GUID..." when using task forVS2005

[Arnette, Bill]

You are still using NAnt to drive the build, but msbuild is actually
compiling the .Net project.  

I see that NAntContrib [1] has an  task [2] that you would use
instead of the  task or the  task.
 
So, after installing NAntContrib, you could do:
 
 


  

   

  

  

 


 
[1] http://nantcontrib.sourceforge.net/
[2]
http://nantcontrib.sourceforge.net/release/latest/help/tasks/msbuild.htm
l
 
 
 
 
 


From: Kumar .S [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 17, 2006 1:52 PM
To: Arnette, Bill
Subject: Re: [NAnt-users] "Error loading GUID..." when using 
task forVS2005



Hello Arnette,
 
So, according to NANT wont support for VS
2005. Is that true. U said its not going to support. In what way its not
supporting. We wont be able to compile. VS 2005 .net applications. 
 
Regards,
Kumar


-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [NAnt-users] "Error loading GUID..." when using task forVS2005

[Arnette, Bill]

Oops.  Replied to wrong list.  
Sorry.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Arnette, 
  BillSent: Tuesday, October 17, 2006 11:56 AMTo: 
  wix-users@lists.sourceforge.netSubject: Re: [WiX-users] 
  [NAnt-users] "Error loading GUID..." when using task 
  forVS2005
  
  I haven't done any VS 2005 work myself but you would do 
  something like 
   
  
  
     
        
  
  
   
   
   
  
  


From: Kumar .S [mailto:[EMAIL PROTECTED] 
Sent: Tuesday, October 17, 2006 11:26 AMTo: Arnette, 
BillSubject: Re: [NAnt-users] "Error loading GUID..." when using 
 task forVS2005

Hello Arnette, 
 
 
Can you send a sample script using  to build an nant project. I 
am new user of Nant. Till now I developed all my applications using nant on 
VS 2003. Now, we are moving to VS 2005. Please I am not a extensive user of 
nant. I have little time, so I request you for a sample script. Please. 

 
Regards,
    Kumar 
On 10/17/06, Arnette, 
Bill <[EMAIL PROTECTED]> 
wrote: 
Nant 
  does not support VS 2005 solution files yet.  Use the 
   taskto call msbuild on VS 2005 solution files. 
  > -Original Message-> From: [EMAIL PROTECTED]> 
  [mailto: 
  [EMAIL PROTECTED]] On Behalf> Of [EMAIL PROTECTED]> 
  Sent: Tuesday, October 17, 2006 6:14 AM> To: nant-users@lists.sourceforge.net> 
  Subject: [NAnt-users] "Error loading GUID..." when using> 
   task forVS2005>> Hi>> Why 
  can't nant find the GUID in the project file? > We have migrated a 
  project from VS 2003 to VS 2005. VS 2005 converted> the project 
  file for us.> I am using the latest 0.85 release when I 
  build.>> Part from the log 
  file:>  [exec]  [solution] 
  Starting solution build. 
  >>  [exec] BUILD FAILED - 
  0 non-fatal error(s), 1 
  warning(s)>>  [exec] Error 
  loading GUID of project> 
  'c:\home\ros\v570\20061017\TietoEnator\Ros\DesktopWebClient\Ti> 
  etoEnator. > 
  RoS.DesktopWebClient.csproj'.>  [exec] 
  Couldn't locate ProjectGuid in project> 
  'c:\home\ros\v570\20061017\TietoEnator\Ros\DesktopWebClient\Ti> 
  etoEnator.> RoS.DesktopWebClient.csproj '>>> 
  Part of the new (VS 2005) .csproj file:> > xmlns="http://schemas.microsoft.com/developer/msbuild/2003 
  ">>   
  > 
  Local> 
  8.0.50727> 
  2.0 
  > 
  {8B9487D6-D6A0-4BCD-A78B-25CA33739757}> 
  ...>>> Part of the old (VS 2003) .csproj 
  file:> > 
  > 
  ProjectType = 
  "Local"> 
  ProductVersion = 
  "7.10.3077"> 
  SchemaVersion = 
  "2.0"> ProjectGuid 
  = "{8B9487D6-D6A0-4BCD-A78B-25CA33739757}" 
  > >> 
  ...>>> ---> Richard 
  Persson> TietoEnator AS> mailto:[EMAIL PROTECTED] 
  > Office: +47 21 70 75 46> Mobile: +47 48 20 85 
  46>>> 
  --> 
  ---> Using Tomcat but need to do more? Need to support web 
  > services, security?> Get stuff done quickly with 
  pre-integrated technology to make> your job easier> Download 
  IBM WebSphere Application Server v.1.0.1 based on> Apache 
  Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&> 
  dat=121642> ___ 
  > NAnt-users mailing list> NAnt-users@lists.sourceforge.net> 
  https://lists.sourceforge.net/lists/listinfo/nant-users 
  >-Using 
  Tomcat but need to do more? Need to support web services, security?Get 
  stuff done quickly with pre-integrated technology to make your job easier 
  Download IBM WebSphere Application Server v.1.0.1 based on Apache 
  Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 
  ___NAnt-users 
  mailing listNAnt-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/nant-users
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] [NAnt-users] "Error loading GUID..." when using task forVS2005

[Arnette, Bill]

I haven't done any VS 2005 work myself but you would do 
something like 
 


   
      

 
 
 


  
  
  From: Kumar .S [mailto:[EMAIL PROTECTED] 
  Sent: Tuesday, October 17, 2006 11:26 AMTo: Arnette, 
  BillSubject: Re: [NAnt-users] "Error loading GUID..." when using 
   task forVS2005
  
  Hello Arnette, 
   
   
  Can you send a sample script using  to build an nant project. I am 
  new user of Nant. Till now I developed all my applications using nant on VS 
  2003. Now, we are moving to VS 2005. Please I am not a extensive user of nant. 
  I have little time, so I request you for a sample script. Please. 
   
  Regards,
  Kumar 
  On 10/17/06, Arnette, 
  Bill <[EMAIL PROTECTED]> 
  wrote: 
  Nant 
does not support VS 2005 solution files yet.  Use the  
taskto call msbuild on VS 2005 solution files. > 
-Original Message-> From: [EMAIL PROTECTED]> 
[mailto: 
[EMAIL PROTECTED]] On Behalf> Of [EMAIL PROTECTED]> 
Sent: Tuesday, October 17, 2006 6:14 AM> To: nant-users@lists.sourceforge.net> 
Subject: [NAnt-users] "Error loading GUID..." when using> 
 task forVS2005>> Hi>> Why can't 
nant find the GUID in the project file? > We have migrated a project 
from VS 2003 to VS 2005. VS 2005 converted> the project file for 
us.> I am using the latest 0.85 release when I build.>> 
Part from the log 
file:>  [exec]  [solution] 
Starting solution build. 
>>  [exec] BUILD FAILED - 0 
non-fatal error(s), 1 
warning(s)>>  [exec] Error 
loading GUID of project> 
'c:\home\ros\v570\20061017\TietoEnator\Ros\DesktopWebClient\Ti> 
etoEnator. > 
RoS.DesktopWebClient.csproj'.>  [exec] 
Couldn't locate ProjectGuid in project> 
'c:\home\ros\v570\20061017\TietoEnator\Ros\DesktopWebClient\Ti> 
etoEnator.> RoS.DesktopWebClient.csproj '>>> 
Part of the new (VS 2005) .csproj file:> > xmlns="http://schemas.microsoft.com/developer/msbuild/2003 
">>   
> 
Local> 
8.0.50727> 
2.0 
> 
{8B9487D6-D6A0-4BCD-A78B-25CA33739757}> 
...>>> Part of the old (VS 2003) .csproj file:> 
> > ProjectType = 
"Local"> 
ProductVersion = 
"7.10.3077"> 
SchemaVersion = 
"2.0"> ProjectGuid = 
"{8B9487D6-D6A0-4BCD-A78B-25CA33739757}" > 
>> ...>>> 
---> Richard Persson> TietoEnator AS> 
mailto:[EMAIL PROTECTED] 
> Office: +47 21 70 75 46> Mobile: +47 48 20 85 
46>>> 
--> 
---> Using Tomcat but need to do more? Need to support web 
> services, security?> Get stuff done quickly with 
pre-integrated technology to make> your job easier> Download 
IBM WebSphere Application Server v.1.0.1 based on> Apache 
Geronimo> http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&> 
dat=121642> ___ > 
NAnt-users mailing list> NAnt-users@lists.sourceforge.net> 
https://lists.sourceforge.net/lists/listinfo/nant-users 
>-Using 
Tomcat but need to do more? Need to support web services, security?Get 
stuff done quickly with pre-integrated technology to make your job easier 
Download IBM WebSphere Application Server v.1.0.1 based on Apache 
Geronimohttp://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642 
___NAnt-users 
mailing listNAnt-users@lists.sourceforge.nethttps://lists.sourceforge.net/lists/listinfo/nant-users
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] WixUI LGHT0103

[Arnette, Bill]

It is a PowerShell issue.  I have do to the same 
quoting when using NAnt when I want to pass a property on the command 
line.  Ex. Nant -D:property=value  in cmd.exe has be typed in 
PowerShell as Nant "-D:property=value".  Thinking about it, it may have to 
do with how it parses the command line for providers; ex. D: or $env:PATH or 
hklm:Software.
 
Bill

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Mike 
  DimmickSent: Monday, October 09, 2006 12:22 PMTo: Bob 
  Arnson; Christer SolskogenCc: 
  wix-users@lists.sourceforge.netSubject: Re: [WiX-users] WixUI 
  LGHT0103
  
  I'd take a guess that PowerShell is somehow messing up 
  the parsing of the : and giving the two arguments "-cultures" "en-us", and 
  that light's command-line parser then interprets "en-us" as being a source 
  file for it to process. It then fails because it can't find the 
  file.
   
  This parameter is inconsistent with -ext and -loc, as is 
  -sice: which may well suffer from the same problem under PowerShell, if that 
  is the problem. -ext and -loc expect the following argument to be an extension 
  or a localization file, respectively.
   
  -- 
  Mike Dimmick
  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of Bob 
  ArnsonSent: 09 October 2006 16:16To: Christer 
  SolskogenCc: wix-users@lists.sourceforge.netSubject: Re: 
  [WiX-users] WixUI LGHT0103
  Christer Solskogen wrote: 
  It seems like wix dont like to be run from PowerShell/Monad.

I had to run it with:
D:\bin\wix\light.exe -ext WixUIExtension "-cultures:en-us" 
HelloWorld.wixobj
  Can you post a 
  bug? I'm not sure if we can do anything to make PowerShell happy but if we 
  can, we should.-- 
sig://boB
http://bobs.org
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

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

[Arnette, Bill]

> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of 
> Sigurd Stenersen
> Sent: Monday, October 02, 2006 6:22 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] Installing machine-specific license files
> 
> Arnette, Bill wrote:
> > the [...] system will package the .msi up
> > in a self-extracting zip file for the user to download.
> 
> Why ?
> 

Why what? 

Why do I need to have the user download license files?  It's a
DirectShow based-app with custom filters.  Each and the application
filter is individually licensed and is signed with a key generated
derived from the machine-specific hash.  There some 60 licensed
components and each one has its own license file.

Why the MSI?  It's a simple way to package everything up, find where the
product is installed, and copy the license files to the product
directory.

Why a SE zip file?  Single file download/installer.

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

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

[Arnette, Bill]

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






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


-Original Message-
From: Bob Arnson [mailto:[EMAIL PROTECTED]]
Sent: Thu 9/28/2006 9:50 PM
To: Arnette, Bill
Cc: wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] Installing machine-specific license files

Arnette, Bill wrote:
> So my plan is to create a WiX project that the licensing system builds
> whenever it gets a license request.  The licensing system will generate
> the license files and then build the WiX project.
> I'll create a WixLib with the components for the license files.  After
> the project is built, the licensing system will package the .msi up in a
> self-extracting zip file for the user to download.
>
> Does this seem like a reasonable thing to do with WiX/MSI? 
>  
Sure. Two things to think about:

- You'll want the license generator to generate and keep track of GUIDs
for product code (at least). Otherwise you're "flying blind."
- You should investigate the new heat harvester technology. It should be
a pretty easy job to take advantage of heat's templates.

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






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

[WiX-users] Installing machine-specific license files

[Arnette, Bill]

Our licensing system is similar to Windows Product Activation in that a
hash is created for the machine the software is licensed on, sent to us,
and we return a self-extracting executable that installs a bunch of
license files that are generated for that specific machine.   What this
means is that every machine has license files with the same name, but
which are different.  We are currently using WISE to create the
installer which installs the license files but I am looking to move it
WiX/MSI.

So my plan is to create a WiX project that the licensing system builds
whenever it gets a license request.  The licensing system will generate
the license files and then build the WiX project.
I'll create a WixLib with the components for the license files.  After
the project is built, the licensing system will package the .msi up in a
self-extracting zip file for the user to download.

Does this seem like a reasonable thing to do with WiX/MSI?  

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

Re: [WiX-users] How to create single installable exe

[Arnette, Bill]

You can create a self-extracting executable with something 
like WinZipSE. I have been using a free self-extacting executable creator called 
Zip2SecureExe [1].
 
You can also use IExpress which ships with Windows 
XP.  Just type IExpress in the Start->Run... box and follow the 
wizard.
 
[1] http://www.chilkatsoft.com/ChilkatSfx.asp
 
 

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  vijSent: Wednesday, September 20, 2006 6:01 AMTo: 
  wix-users@lists.sourceforge.netSubject: [WiX-users] How to create 
  single installable exe
  
  Hi,
   
  I have multiple msi packages created using WiX, a bootstrapper 
  setup.exe and settings.ini (settings.ini contains some configuration 
  information used by setup.exe) . 
  How can I package these files (msi packages + setup.exe + 
  settings.ini + some other resources) as a single installable 
  executalbe?
   
  Any pointers would be of great help!!
   
   
  thanks
  Vij
  
  
  All-new 
  Yahoo! Mail - Fire up a more powerful email and get things done 
faster.
-
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys -- and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] how to get parent directory of a folder

[Arnette, Bill]

If you are installing based on an already installed 
product, don't let the user browse to the installed location; they may get it 
wrong or not know where it's installed.  Instead, use a registry or 
directory search to find where the installed application resides and set the 
path in a property.   As for finding the parent directory, you will 
probably have to write a custom action that reads the property that was set from 
the search, calculates the parent directory, and sets a new property containing 
the parent directory path.  You could schedule that CA to run right after 
RegistrySearch and/or DirectorySearch.

  
  
  From: [EMAIL PROTECTED] 
  [mailto:[EMAIL PROTECTED] On Behalf Of 
  [EMAIL PROTECTED]Sent: Thursday, August 17, 2006 8:49 
  AMTo: [EMAIL PROTECTED]; 
  wix-users@lists.sourceforge.netSubject: Re: [WiX-users] how to get 
  parent directory of a folder
  
  
  Thanks for your 
  response.
  That scenario is 
  taken care of. Actually the user will chose the path for an installed product 
  that is having directory path up to 3 levels deep. 
  
   
  
  
  
  
  From: John 
  Vottero [mailto:[EMAIL PROTECTED] Sent: Thursday, August 17, 2006 6:17 
  PMTo: Swain, Bibhuti Bhusan 
  (Eq,FI&RWM); wix-users@lists.sourceforge.netSubject: RE: [WiX-users] how to get 
  parent directory of a folder
   
  What happens when the 
  user picks C:\?
  
 



From: 
[EMAIL PROTECTED] 
[mailto:[EMAIL PROTECTED] On Behalf Of 
[EMAIL PROTECTED]Sent: Thursday, August 17, 2006 7:57 
AMTo: wix-users@lists.sourceforge.netSubject: [WiX-users] how to get parent 
directory of a folder
Hi,
    
I have a requirement to install some files in a folder (chosen by user) and 
some other files to the parent of that folder. Now I am getting the folder 
by providing a browse dialog and getting in a property. Can any one tell me 
how to get the parent directory of that folder? i.e. how to modify the 
property, having the folder path, to get it’s patent 
directory.
 
Thanks
Bibhuti
-
Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] My Installer Requirements

[Arnette, Bill]

It does have to do with WiX.  WiX is what generates the MSI database.
MsiInstallProduct() is an API function that you can call from a program
to install an MSI database.  In fact, that is, among other things,
exactly what msiexec.exe does.  Internally it calls MsiInstallProduct to
install the MSI you pass on the command line [1].   

So what I am suggesting is that you write a small wizard application in
C++ that has no runtime dependencies (might I suggest using WTL?) that
after display the combined license agreements  and collecting some
information from the user, calls MsiInstallProduct() on the MSI you
created with WiX.  

As for a tutorial on writing a custom UI, I don't know of any.  But the
setup.exe sample in the Windows Installer SDK (Platform
SDK\samples\SysMgmt\Msi\setup.exe\) demonstrates calling
MsiInstallProduct() and other Windows Installer APIs.  You would be
essentially creating a bootstrapper [2].

[1] I imagine it also calls other Windows Installer API functions such
as MsiSetProperty to set the properties you specify on the command line
(REINSTALL, REINSTALLMODE, ALLUSERS, etc) and MsiSetInternalUI to set
the UI level according to the /q(bn) command line option.

[2]
http://msdn.microsoft.com/library/en-us/msi/setup/bootstrapping.asp?fram
e=true


> -Original Message-
> From: [EMAIL PROTECTED] 
> [mailto:[EMAIL PROTECTED] On Behalf Of Magus
> Sent: Wednesday, August 16, 2006 1:15 PM
> To: wix-users@lists.sourceforge.net
> Subject: Re: [WiX-users] My Installer Requirements
> 
> 
> Interesting how that doesn't seem to have anything to do with 
> wix. I have no
> idea how to write a program for MSI, I've tried finding 
> tutorials, but I
> have been unsuccessful. I am not an SQL guy either, I don't 
> know how are
> when to use MsiSetExternalUI(), exect that its not something 
> I can call from
> a custom action.  So what it seems to me that your saying is 
> that Wix cannot
> provide me with what I need to do?
> 
> Bill Arnette wrote:
> > 
> > For requirement 1, it seems your best bet may be to make a 
> small wizard
> > application that displays the Welcome/Splash screen and the combined
> > license
> > agreement.  At the end of the wizard, your MSI is run with
> > MsiInstallProduct().  The MSI would then have the other 
> dialogs such as
> > feature selection tree, installation path, etc.  
> > 
> > Maybe using MsiSetExternalUI(), your external UI handler 
> could trap the
> > back
> > button message from the first MSI dialog so that you could show your
> > license
> > dialog again.  
> > 
> > BTW, does anybody know how things like MS Flight Simulator have such
> > stylized UI in their installer (bitmap buttons, custom 
> constrols, etc)? 
> > Is
> > it an external UI or is it a complete UI that runs the MSI 
> in silent mode?
> > 
> > 
> >> -Original Message-
> >> From: [EMAIL PROTECTED] 
> >> [mailto:[EMAIL PROTECTED] On Behalf Of Magus
> >> Sent: Tuesday, August 15, 2006 2:12 PM
> >> To: wix-users@lists.sourceforge.net
> >> Subject: [WiX-users] My Installer Requirements
> >> 
> >> 
> >> Ok I've made a a lot of posts in the past, but really most of 
> >> my questions
> >> have to do what with what I am required to make the 
> installer do, so
> >> alternatives are not optional.  With that said I would like 
> >> to post what I
> >> am required to create and maybe see if anyone has any 
> >> suggestions or knows
> >> exactly what I should do, because I am at a loss.
> >> 
> >> 1.  My License agreement + Another companys license agreement 
> >> in one text
> >> field. 
> >> Problems - Other companys license must be obtained 
> >> and inserted into
> >> my license agreement at runtime.
> >> My solution - Make my own dialog in win32 to display in a
> >> Richedit2.0 control
> >> More problems - My next dialog box (created in Wix) 
> >> needs a back
> >> button
> >> Question - How do I return back to the win32 dialog 
> >> without exiting
> >> setup, 
> >> but making it so the Wix dialog goes way and then 
> >> will reappear if
> >> the user click
> >> next on my dialog box
> >> I can further clarify if I need to.
> >> 2.  Program is suppose to boot and run from DVD if user 
> chooses not to
> >> Install!  It also is suppose to put a Launcher app on the 
> >> users computer
> >> that is suppose to know if the user installed the app or not. 
> >> (probably not
> >> a wix thing but maybe someone had a similar situation)
> >> -- 
> >> View this message in context: 
> >> http://www.nabble.com/My-Installer-Requirements-tf2110611.html
> >> #a5819078
> >> Sent from the wix-users forum at Nabble.com.
> >> 
> >> 
> >> --
> >> ---
> >> Using Tomcat but need to do more? Need to support web 
> >> services, security?
> >> Get stuff done quickly with pre-integrated technology to make 
> >> your job easier
> >> Download IBM WebSphere Application Server v.1.0.1 based on 
> >>