Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Blair]

That is an excellent idea. To extend it to a logical conclusion:

All of the app (except for the shell extensions) goes under
ProgramFilesFolder\"Company"\"Product" (and this is the directory that the
user can change)

The 32-bit shell extension always goes under CommonFilesFolder\"Company",
and the 64-bit extension always goes under CommonFiles64Folder\"Company".

You can use the $(sys.PLATFORM) value to exclude the 64-bit component from
being compiled into your 32-bit MSI and you will be able to use the exact
same sources for both the 32-bit and the 64-bit MSIs.

-Original Message-
From: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] 
Sent: Tuesday, September 22, 2009 6:09 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

The way I've attacked this scenario is with two separate packages and
a little bit of file duplication on the x64 system to prevent having
to completely rework the application. No problems with the ICE tests
either :)

32-bit system
  - everything gets installed to Program Files\ACME

64-bit system
 - 32-bit components get installed to Program Files (x86)\ACME
 - 64-bit components get installed to Program Files\Common Files\ACME
 - some files are duplicated between both the x64 and x86 locations to
keep things simple, components marked as appropriate for the
destination location.



On Wed, Sep 23, 2009 at 10:26 AM, Blair  wrote:
> Heath has a really good blog post about what happens if you work with
64-bit
> components in a 32-bit MSI package. The major limitation is that you can't
> use a 64-bit directory since a Windows Installer supplied directory
> reflection will always kick in on a 32-bit MSI. I found that reading it
> about 5 times over several weeks leads to a better understanding of what
he
> discovered vs. just one read-through.
>
> ICE80 is designed to make sure you don't build a 32-bit MSI that accesses
> 64-bit regions of the OS (since your 32-bit app can't normally reach
them).
> Have you run your Wise-generated MSI through either smoke or Orca's
> validation? You will see the ICE80 error there if wise is generating a
> 32-bit marked MSI. Just because Wise lets you doesn't mean it builds
> "clean".
>
> You will need both 32-bit and 64-bit extensions installed on 64-bit Oss,
to
> support 32-bit applications.
>
> The "correct" way is to build a 64-bit MSI for 64-bit OSs where all of
your
> components except for the 64-bit extension are 32-bit components, AND
where
> you place the 64-bit file in a 64-bit directory "by default". That doesn't
> mean you don't allow the user to change the installation locations, it
just
> means you have two installation locations (one for the 32-bit code and one
> for the 64-bit code). You could force the 64-bit location to the user's
> expressed preference IF the user changed it via a custom action.
>
> For just one component that writes one file and one registry key, that may
> seem a bit much, however. Heath noted that a 64-bit component in a 32-bit
> MSI will do two things: 1) the directory will be changed to the matching
> 32-bit directory, and 2) the registry won't be changed (you get the 64-bit
> registry). But, you will always get ICE80 issues when you do that, since
the
> 32-bit directory isn't "supposed to" contain 64-bit code.
>
> One option is to build the 32-bit MSI with the 64-bit component. You
> absolutely must add a "VersionNT64" condition on your 64-bit component
> "GSIShell64" (there will never be any use of the 64-bit extension on a
> 32-bit OS) and you will need to suppress the ICE80 during light and ensure
> that you don't have any additional ICE80 errors or warnings in subsequent
> builds by regularly running smoke (or Orca) on your MSI and checking the
> results. It isn't "kosher" but it will work.
>
> I generally don't advocate this type of solution, but I also don't view
all
> the ICE tests as written as always entirely practical either. You may not
be
> able to get/retain a Logo doing this, since that requires a generally
clean
> ICE validation, so that should be weighed into your calculations.
>
> -Original Message-
> From: Nate Hekman [mailto:hek...@geo-slope.com]
> Sent: Tuesday, September 22, 2009 9:14 AM
> To: WiX-users@lists.sourceforge.net
> Subject: [WiX-users] Installing 64-bit shell extension with a 32-bit app
>
> I have a 32-bit application that include a 32-bit shell extension dll
> that handles thumbnails and a few other shell extensions.  I want to add
> a 64-bit version of that same dll to the mix to get the same thumbnails
> et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue line
> with [BINDIR] in the Value is the line that causes me trouble when I get
> to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
> 

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Sascha Beaumont]

The way I've attacked this scenario is with two separate packages and
a little bit of file duplication on the x64 system to prevent having
to completely rework the application. No problems with the ICE tests
either :)

32-bit system
  - everything gets installed to Program Files\ACME

64-bit system
 - 32-bit components get installed to Program Files (x86)\ACME
 - 64-bit components get installed to Program Files\Common Files\ACME
 - some files are duplicated between both the x64 and x86 locations to
keep things simple, components marked as appropriate for the
destination location.



On Wed, Sep 23, 2009 at 10:26 AM, Blair  wrote:
> Heath has a really good blog post about what happens if you work with 64-bit
> components in a 32-bit MSI package. The major limitation is that you can't
> use a 64-bit directory since a Windows Installer supplied directory
> reflection will always kick in on a 32-bit MSI. I found that reading it
> about 5 times over several weeks leads to a better understanding of what he
> discovered vs. just one read-through.
>
> ICE80 is designed to make sure you don't build a 32-bit MSI that accesses
> 64-bit regions of the OS (since your 32-bit app can't normally reach them).
> Have you run your Wise-generated MSI through either smoke or Orca's
> validation? You will see the ICE80 error there if wise is generating a
> 32-bit marked MSI. Just because Wise lets you doesn't mean it builds
> "clean".
>
> You will need both 32-bit and 64-bit extensions installed on 64-bit Oss, to
> support 32-bit applications.
>
> The "correct" way is to build a 64-bit MSI for 64-bit OSs where all of your
> components except for the 64-bit extension are 32-bit components, AND where
> you place the 64-bit file in a 64-bit directory "by default". That doesn't
> mean you don't allow the user to change the installation locations, it just
> means you have two installation locations (one for the 32-bit code and one
> for the 64-bit code). You could force the 64-bit location to the user's
> expressed preference IF the user changed it via a custom action.
>
> For just one component that writes one file and one registry key, that may
> seem a bit much, however. Heath noted that a 64-bit component in a 32-bit
> MSI will do two things: 1) the directory will be changed to the matching
> 32-bit directory, and 2) the registry won't be changed (you get the 64-bit
> registry). But, you will always get ICE80 issues when you do that, since the
> 32-bit directory isn't "supposed to" contain 64-bit code.
>
> One option is to build the 32-bit MSI with the 64-bit component. You
> absolutely must add a "VersionNT64" condition on your 64-bit component
> "GSIShell64" (there will never be any use of the 64-bit extension on a
> 32-bit OS) and you will need to suppress the ICE80 during light and ensure
> that you don't have any additional ICE80 errors or warnings in subsequent
> builds by regularly running smoke (or Orca) on your MSI and checking the
> results. It isn't "kosher" but it will work.
>
> I generally don't advocate this type of solution, but I also don't view all
> the ICE tests as written as always entirely practical either. You may not be
> able to get/retain a Logo doing this, since that requires a generally clean
> ICE validation, so that should be weighed into your calculations.
>
> -Original Message-
> From: Nate Hekman [mailto:hek...@geo-slope.com]
> Sent: Tuesday, September 22, 2009 9:14 AM
> To: WiX-users@lists.sourceforge.net
> Subject: [WiX-users] Installing 64-bit shell extension with a 32-bit app
>
> I have a 32-bit application that include a 32-bit shell extension dll
> that handles thumbnails and a few other shell extensions.  I want to add
> a 64-bit version of that same dll to the mix to get the same thumbnails
> et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue line
> with [BINDIR] in the Value is the line that causes me trouble when I get
> to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit d

Re: [WiX-users] Vista Standard User and perMachine install

[Sascha Beaumont]

>From the documentation:

The Privileged property indicates whether the installation is
performed in the context of elevated privileges. The installer sets
this property if the user has administrator privileges, if the
application has been assigned by a system administrator, or if both
the user and machine policies AlwaysInstallElevated are set to true.

I'd check the MSI logs to see if AlwaysInstallElevated is set true for
both machine and user.


On Sat, Sep 19, 2009 at 8:30 AM, warne warne  wrote:
>
> Is there a property I could check for that is set when either a XP Limited or 
> Vista Standard user runs my installer?
>
> I tried 'AdminUser' & 'Privileged but it seems they are always '1' regardless 
> if I run the setup logged in as an administrator or not.
>
> thanks very much,
>
> _
> View your other email accounts from your Hotmail inbox. Add them now.
> http://clk.atdmt.com/UKM/go/167688463/direct/01/
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ARP support info in Vista: not shown

[Blair]

See
http://blogs.msdn.com/windows_installer_team/archive/2007/07/06/configuring-
windows-vista-software-explorer.aspx

In Vista, that link is populated from ARPURLINFOABOUT. ARPHELPLINK is called
"Help Link" on that OS.

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: Tuesday, September 22, 2009 5:07 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] ARP support info in Vista: not shown

Hi Palbinder,


Thanks for your reply. I'm not quite sure you're asking me to double check
"Programs & Features", or you're having the same problem and asking experts
in the forum?

Anyways, I did double checked the "Programs & Features", I did enable the
"Support Link" field. It's empty in the field. However, in XP and Windows 7,
we do have the company URL displayed correctly. Does anybody know what the
problem is?

Thanks.




From: Pally Sandher 
To: General discussion for Windows Installer XML toolset.

Sent: Tuesday, September 22, 2009 3:53:12 AM
Subject: Re: [WiX-users] ARP support info in Vista: not shown

Vista doesn't support it? You're not viewing the "Programs & Features"
Control panel in the right view mode to see it (default view mode may
not show it)? It's a bug in Vista which is fixed in Windows 7?

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer



-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: 22 September 2009 00:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ARP support info in Vista: not shown

We use Wix 3.0.


We have this code to show support url in ARP:



In XP and Windows 7, it works - we can see the url when checking ARP.
But in Vista, the support info url field is empty. In the log of the
Vista installation, the ARPHELPLINK is setup:
Property(C): ARPHELPLINK = http://www.thecompany.com


What's the problem here?

Thanks.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your
favourite sites. Download it now
http://ca.toolbar.yahoo.com.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Blair]

Heath has a really good blog post about what happens if you work with 64-bit
components in a 32-bit MSI package. The major limitation is that you can't
use a 64-bit directory since a Windows Installer supplied directory
reflection will always kick in on a 32-bit MSI. I found that reading it
about 5 times over several weeks leads to a better understanding of what he
discovered vs. just one read-through.

ICE80 is designed to make sure you don't build a 32-bit MSI that accesses
64-bit regions of the OS (since your 32-bit app can't normally reach them).
Have you run your Wise-generated MSI through either smoke or Orca's
validation? You will see the ICE80 error there if wise is generating a
32-bit marked MSI. Just because Wise lets you doesn't mean it builds
"clean".

You will need both 32-bit and 64-bit extensions installed on 64-bit Oss, to
support 32-bit applications.

The "correct" way is to build a 64-bit MSI for 64-bit OSs where all of your
components except for the 64-bit extension are 32-bit components, AND where
you place the 64-bit file in a 64-bit directory "by default". That doesn't
mean you don't allow the user to change the installation locations, it just
means you have two installation locations (one for the 32-bit code and one
for the 64-bit code). You could force the 64-bit location to the user's
expressed preference IF the user changed it via a custom action.

For just one component that writes one file and one registry key, that may
seem a bit much, however. Heath noted that a 64-bit component in a 32-bit
MSI will do two things: 1) the directory will be changed to the matching
32-bit directory, and 2) the registry won't be changed (you get the 64-bit
registry). But, you will always get ICE80 issues when you do that, since the
32-bit directory isn't "supposed to" contain 64-bit code.

One option is to build the 32-bit MSI with the 64-bit component. You
absolutely must add a "VersionNT64" condition on your 64-bit component
"GSIShell64" (there will never be any use of the 64-bit extension on a
32-bit OS) and you will need to suppress the ICE80 during light and ensure
that you don't have any additional ICE80 errors or warnings in subsequent
builds by regularly running smoke (or Orca) on your MSI and checking the
results. It isn't "kosher" but it will work.

I generally don't advocate this type of solution, but I also don't view all
the ICE tests as written as always entirely practical either. You may not be
able to get/retain a Logo doing this, since that requires a generally clean
ICE validation, so that should be weighed into your calculations.

-Original Message-
From: Nate Hekman [mailto:hek...@geo-slope.com] 
Sent: Tuesday, September 22, 2009 9:14 AM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] Installing 64-bit shell extension with a 32-bit app

I have a 32-bit application that include a 32-bit shell extension dll
that handles thumbnails and a few other shell extensions.  I want to add
a 64-bit version of that same dll to the mix to get the same thumbnails
et al working in 64-bit Windows Explorer.

 

Can someone tell me (or point me to documentation) what the proper way
is to do this?

 

Here's what I've been using for the 32-bit dll.  The RegistryValue line
with [BINDIR] in the Value is the line that causes me trouble when I get
to 64-bit.

 

 

  





  

  





  



  



 

[BINDIR] is defined earlier in the .wxs file as:

 

  



  

  



  



  

 

So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
er32's value is "C:\Program Files
(x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".

 

Then I add the 64-bit dll similarly.  The file needs to be placed in the
same bin folder as the 32-bit version, but I want to be editing the
64-bit portion of the Registry, so I add Win64="yes" to the Component.

 

 

  





  

  





  



  



 

This gives me an error on the RegistryValue line with [BINDIR] in the
Value:

 

Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
BINDIR.

 

I've done a lot of googling and most responses are "you shouldn't be
installing 64-bit dlls with a 32-bit app".  But that's absolutely not
true, as these dlls are used by the shell, not by my application.  There
must be other people with this same problem.  What's the solution?

 

Thanks for any help!

 

 

Nate

 


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile app

Re: [WiX-users] RemoveFile after merged

[Blair]

Can you instead put your temp file in the Binary table and have your action 
that merges its content extract, use, and delete that file?

-Original Message-
From: puyo puy [mailto:puyo...@yahoo.com] 
Sent: Monday, September 21, 2009 12:33 AM
To: wix users
Subject: [WiX-users] RemoveFile after merged

Hello,





I want to deploy a temp file and merge a file already
installed and delete that temp file at the end of installation.  I want to know 
how to make sure the temp file was
delete after merged?  I know that we can
use RemoveFile element when a component selected but this done before merge.
The following are the procedures that I expected to happen.

 

1.  
Deploy the temp file under current user’s temp
folder.

2.  
Merge the content of temp file with local after
InstallFinalize sequence.

3.  
Remove the temp file from temp folder.

 

I want to create a custom action to delete temp file after
merged but RemoveFile only available under component.

 

Thanks for your help in advance.

Jeff  





  
__
Get more done like never before with Yahoo!7 Mail.
Learn more: http://au.overview.mail.yahoo.com/
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ARP support info in Vista: not shown

[little.forest]

Hi Palbinder,


Thanks for your reply. I'm not quite sure you're asking me to double check 
"Programs & Features", or you're having the same problem and asking experts in 
the forum?

Anyways, I did double checked the "Programs & Features", I did enable the 
"Support Link" field. It's empty in the field. However, in XP and Windows 7, we 
do have the company URL displayed correctly. Does anybody know what the problem 
is?

Thanks.




From: Pally Sandher 
To: General discussion for Windows Installer XML toolset. 

Sent: Tuesday, September 22, 2009 3:53:12 AM
Subject: Re: [WiX-users] ARP support info in Vista: not shown

Vista doesn't support it? You're not viewing the "Programs & Features"
Control panel in the right view mode to see it (default view mode may
not show it)? It's a bug in Vista which is fixed in Windows 7?

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer



-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: 22 September 2009 00:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ARP support info in Vista: not shown

We use Wix 3.0.


We have this code to show support url in ARP:



In XP and Windows 7, it works - we can see the url when checking ARP.
But in Vista, the support info url field is empty. In the log of the
Vista installation, the ARPHELPLINK is setup:
Property(C): ARPHELPLINK = http://www.thecompany.com


What's the problem here?

Thanks.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



  __
Yahoo! Canada Toolbar: Search from anywhere on the web, and bookmark your 
favourite sites. Download it now
http://ca.toolbar.yahoo.com.
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to determine the wixlibrary for DeleteServices and InstallServices?

[Blair]

They are standard Windows Installer actions. They have their own elements to
refer to them.

By default, they already have a condition (which you probably would wish to
retain). So, you should include that condition with yours, which would make
your authoring become:


  VersionNT AND NOT PATCH
  VersionNT AND NOT PATCH


-Original Message-
From: Vidya Kukke [mailto:vku...@microsoft.com] 
Sent: Tuesday, September 22, 2009 1:46 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] How to determine the wixlibrary for DeleteServices
and InstallServices?

Anyone?

-Original Message-
From: Vidya Kukke [mailto:vku...@microsoft.com] 
Sent: Tuesday, September 22, 2009 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to determine the wixlibrary for DeleteServices and
InstallServices?

Hi,

I have a requirement to not run DeleteServices and InstallServices during
PATCH installation. I wanted to add these CAs as part of my msi with the
'NOT PATCH' condition. However I get a light error with an unresolved
reference for these CAs.  What is the best way to determine which library a
CA is part of?

Thanks
Vidya

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] How to schedule RemoveFile

[Blair]

What does your custom action do that requires it to generate a file in the
SYSTEM folder, and does it even have to run during uninstallation?

There are impacts that can occur changing the relative order of the
"standard" actions.

-Original Message-
From: Arvind Aiyar [mailto:arvind.ai...@microsoft.com] 
Sent: Tuesday, September 22, 2009 10:29 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] How to schedule RemoveFile

I need to delete a file foo.dll from the SYSTEM folder on uninstall. This
foo.dll is generated by a Custom Action in the installer. Since foo.dll is
not part of the originally installed files so I use the RemoveFile to do
this and specify the file to be deleted on uninstall. However, since it's a
system file, I get the reboot will be required dialog. Is there a way to
suppress this ? Or maybe schedule the RemoveFile until later when my Custom
Action is done using it ?

-Arvind


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile being executed when feature condition should fail

[Blair]

What does the log say about the WebConfigSqlDbSqlAuthComponent component while 
running CostFinalize?

Also, is your upgrade Major or Minor/Small?

-Original Message-
From: si [mailto:sshnug...@gmail.com] 
Sent: Monday, September 21, 2009 11:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XmlFile being executed when feature condition should 
fail

>> Long story short: XmlFile is being executed during upgrades when I
>> only want it executed on new installations.
>>
>
> The owning component controls whether XmlFile is run; conditionalize it
> so it doesn't run during upgrade.

Thanks for the reply Bob, unfortunately I already tried this with no luck:


  NOT Installed AND USEINTEGRATEDSECURITY = 1
  



  NOT Installed AND NOT USEINTEGRATEDSECURITY = 1>
  


I tried both "NOT Installed" and "NOT UPGRADEFOUND" for the component
condition, neither worked.

I was wondering if it may be because the custom UI we show for
collecting sql credentials wasn't being shown on upgrades, so the
property values would be null, but I don't understand why the
connectionString attribue is empty, rather than
"Database=;Server=;uid=;pwd;" which is what I would've expected if the
properties were empty.

Looking, through the upgrade log file, it appears that
ExecXmlFileRollback action is being called:

MSI (s) (28:A8) [16:09:22:671]: Doing action: SchedXmlFile
Action 16:09:22: SchedXmlFile.
Action start 16:09:22: SchedXmlFile.
MSI (s) (28:14) [16:09:22:677]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI8A93.tmp, Entrypoint: SchedXmlFile
MSI (s) (28!1C) [16:09:22:719]: PROPERTY CHANGE: Adding
ExecXmlFileRollback property. Its value is '0€C:\Program Files
(x86)\blah\\web.config�...@xx[snip]
MSI (s) (28!1C) [16:09:22:720]: Doing action: ExecXmlFileRollback
Action 16:09:22: ExecXmlFileRollback.
Action start 16:09:22: ExecXmlFileRollback.
ExecXmlFileRollback:
Action ended 16:09:22: ExecXmlFileRollback. Return value 1.
MSI (s) (28!1C) [16:09:22:726]: PROPERTY CHANGE: Adding ExecXmlFile
property. Its value is '1€0€C:\Program Files
(x86)\Blah\\Web.config€4€0€/configuration/connectionStrings/a...@name='Database']/@connectionString€€Database=Blah;Server=(local);Integrated
Security=SSPI;'.
MSI (s) (28!1C) [16:09:22:727]: Doing action: ExecXmlFile
Action 16:09:22: ExecXmlFile.
Action start 16:09:22: ExecXmlFile.
ExecXmlFile:
Action ended 16:09:22: ExecXmlFile. Return value 1.
Action ended 16:09:22: SchedXmlFile. Return value 1.


Another potential issue is that we create the web.config on install
using CopyFile, and run SchedXmlFile after DuplicateFiles.  I don't
think this would cause a problem, but figured it was worth a mention.

Thanks again.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] remove website on uninstall

[Chad Petersen]

How about having it write a verbose log during the uninstall and then
look to see if it indicates in the log why it likes that Component so
much? It's helped me over similar hurdles in the past.

-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com] 
Sent: Tuesday, September 22, 2009 3:25 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] remove website on uninstall

Hi Dominique,

Thanks for the feedback!  I think I already have it in a component (see
snippet below).  Please let me know if this is what you mean, or if you
have any other suggestions.

Thanks in advance for any ideas or suggestions!


  

  
  
  

  
  
  


TARGETMODE = "NewWebsite" AND SCRIPTLANGUAGE =
"ASP"
  
  

  
  



  

TARGETMODE = "ExistingWebsite" AND SCRIPTLANGUAGE =
"ASP"

  

-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] 
Sent: Tuesday, September 22, 2009 4:53 PM
To: General discussion for Windows Installer XML toolset.;
WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] remove website on uninstall

If you move the WebSite declaration inside a Component it should delete
it on uninstall.

Be aware though that if your WebSite somehow maps to "Default Web Site"
then it will delete that as well.


Dominique.


-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com]
Sent: Tue 9/22/2009 7:49 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] remove website on uninstall
 
Hi,

 

I created an msi install for website and database using wix 3.0.5217.0.
All works great for install.  But, I'm having trouble trying to figure
out how to delete the website on uninstall.  Has anyone done that?  If
so, any suggestions would be greatly appreciated.

 

Thanks, Craig


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.ne

Re: [WiX-users] remove website on uninstall

[Scharp, Craig]

Hi Dominique,

Thanks for the feedback!  I think I already have it in a component (see
snippet below).  Please let me know if this is what you mean, or if you
have any other suggestions.

Thanks in advance for any ideas or suggestions!


  

  
  
  

  
  
  


TARGETMODE = "NewWebsite" AND SCRIPTLANGUAGE =
"ASP"
  
  

  
  



  

TARGETMODE = "ExistingWebsite" AND SCRIPTLANGUAGE =
"ASP"

  

-Original Message-
From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] 
Sent: Tuesday, September 22, 2009 4:53 PM
To: General discussion for Windows Installer XML toolset.;
WiX-users@lists.sourceforge.net
Subject: Re: [WiX-users] remove website on uninstall

If you move the WebSite declaration inside a Component it should delete
it on uninstall.

Be aware though that if your WebSite somehow maps to "Default Web Site"
then it will delete that as well.


Dominique.


-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com]
Sent: Tue 9/22/2009 7:49 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] remove website on uninstall
 
Hi,

 

I created an msi install for website and database using wix 3.0.5217.0.
All works great for install.  But, I'm having trouble trying to figure
out how to delete the website on uninstall.  Has anyone done that?  If
so, any suggestions would be greatly appreciated.

 

Thanks, Craig


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay 
ahead of the curve. Join us from November 9-12, 2009. Register
now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Error 1648 Installing Patch

[JWalker]

Hi,
I have a patch built using the WiX-only approach. I can view it in Orca with 
the original MSI, and everything looks good. But when I go to apply the patch, 
the installer displays the message "No valid sequence could be found for the 
set of patches". The values are all correct in the MsiPathSequence table (patch 
family "TestPatchFamily", sequence "1.0.0.1", the product code, and attributes 
"0"). Does anyone have any idea what could be causing this error? Here is an 
excerpt from the log:
MSI (c) (DC:C4) [13:11:50:579]: Validating transform 'RTM.1' with validation 
bits 0x922
MSI (c) (DC:C4) [13:11:50:579]: Transform 'RTM.1' is valid.
MSI (c) (DC:C4) [13:11:50:579]: PATCH SEQUENCER: QFE patch 
E:\Installer\Patches\TestPatch.msp is applicable.
MSI (c) (DC:C4)
 [13:11:50:579]: PATCH SEQUENCE ERROR: E:\Installer\Patches\TestPatch.msp patch 
is missing sequencing info!
MSI (c) (DC:C4) [13:11:50:579]: SequencePatches returns error 1648.
No valid sequence could be found for the set of patches.

I don't know whether this might be a factor, but we do some post-processing of 
the heat-generated .wxs files to put each component in its own fragment. The 
MSI file installs fine... Many Thanks!



  
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] verbose log files

[Mike Rerick]

I ran into an interesting problem with the log files generated by my
installer.

I have an installer that creates a database and then runs some SQL files to
build the tables, populate them and create procedures. In the SQL scripts,
all database names, table names, column names and owner names are surrounded
by square brackets ( [dbo].[tablename] ). Even if the install runs
successfully, the SQL that gets logged in the log file has the brackets and
everything between them stripped out ( [dbname].[owner].[tablename] gets
reduced to .. in the log file).

I run the installers from the command line:   msiexec /i msiname.msi
LOGVERBOSE=1 /l*v logname.log

I am using MSI 4.5 and WiX 3.0.5210.0. Everything is running on Windows XP
SP2 or SP3.

I was wondering if anyone else has seen this and if so, how do I prevent
this from happening?

Thanks

  *Mike Rerick*
  *Sr. Software Engineer*

[image: Google Docs] *ImageWare Systems, Inc.*
  9200 S.E. Sunnybrook Blvd., Suite 170
  Clackamas, OR   97015

  Office: (503) 353-8068  Fax: (503) 353-8065

The information contained in this transmission contains potentially privileged, 
export controlled and/or confidential information of Imageware Systems, Inc. or 
its customers or partners.  It is intended only to be read by the person(s) 
named above and for no other purpose.  You are hereby notified that any 
dissemination, distribution, duplication of this communication or use of its 
contents for any purpose not authorized expressly by Imageware Systems, Inc. is 
strictly prohibited and could lead to both civil and/or criminal penalties.  If 
you are not the intended recipient, you are prohibited to review the contents 
herein and please contact the sender by reply e-mail and destroy all copies of 
the original message.  To reply to our e-mail administrator directly, please 
send an e-mail to emailad...@iwsinc.com
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] remove website on uninstall

[Dominique Louis]

If you move the WebSite declaration inside a Component it should delete it on 
uninstall.

Be aware though that if your WebSite somehow maps to "Default Web Site" then it 
will delete that as well.


Dominique.


-Original Message-
From: Scharp, Craig [mailto:craig.sch...@zytax.com]
Sent: Tue 9/22/2009 7:49 PM
To: WiX-users@lists.sourceforge.net
Subject: [WiX-users] remove website on uninstall
 
Hi,

 

I created an msi install for website and database using wix 3.0.5217.0.
All works great for install.  But, I'm having trouble trying to figure
out how to delete the website on uninstall.  Has anyone done that?  If
so, any suggestions would be greatly appreciated.

 

Thanks, Craig

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


AMX

AMX UK
Auster Road
Clifton Moor
York, North Yorkshire
United Kingdom
YO30 4GD

+44 (0) 1904 343100 office
+44 (0) 1904 343101 fax

AMX South
6th Floor Salisbury House
London Wall
London
United Kingdom
EC2M 5QQ

+44 (0) 2076 529450 office
+44 (0) 8701 991661 fax

AMX Belgium
Boerenkrijglaan, 96a
B-2260
Westerlo
Belgium


+ 32 (0) 1454 2763  office
+ 32 (0) 1454 2766  fax

##
Attention: 
This e-mail message is privileged and confidential. If you are not the 
intended recipient please delete the message and notify the sender. 
Any views or opinions presented are solely those of the author.

This email was scanned and cleared by NetIQ MailMarshal.
##
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

Good suggestion, Brant.  I'll take a look at some other packages.  I see 
several in my 64-bit Program Files that just have a couple of dlls, with most 
of their files in the 32-bit area.

Nate

-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name] 
Sent: Tuesday, 22 September 2009 1:45 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

Have you looked at what things like Visual Studio do if you choose a
non-default install location (I mention it since I know it installs
32-bit and 64-bit components). My guess is that they will behave the
same. I don't think I've seen a guideline covering installation of
mixed components and where I've seen it done, 64-bit stuff goes into
ProgramFiles64Folder and 32-bit stuff goes into ProgramFilesFolder
with only one of them being customizable during installation.

By the way, the 32-bit components would be the same between 64-bit and
32-bit components so if you create two installers, the 32-bit
components should go in a merge module so component IDs remain
consistent.

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 3:32 PM, Nate Hekman  wrote:
> I just tried your suggestion, Brant, at least what I'm supposing you mean.
>
> - I set the Package's Platform='x64'
> - I extended the  section to include the ProgramFiles64Folder.  
> The Bin folder buried under there has an Id of BINDIR64.
> - I created a new  containing a Win64="yes" 
> Component, with the 64-bit dll and RegistryValues, and using [BINDIR64] in 
> the Value.
>
> Presumably that should put the 64-bit dll under the Program Files folder and 
> register it correctly, while keeping all the 32-bit components under Program 
> Files (x86).
>
> And in fact that does work.  But only if the user who's installing accepts 
> the default install path (C:\Program Files (x86)).  If they choose a 
> different install path (L:\Foo for example), then the 32-bit stuff goes to 
> L:\Foo but the 64-bit still goes to C:\Program Files.  Not what the user 
> intended.  Not good form.
>
>
> Nate
>
>
>
>
> -Original Message-
> From: Brant Gurganus [mailto:br...@gurganus.name]
> Sent: Tuesday, 22 September 2009 10:48 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app
>
> What is preventing you from installing it in the 64-bit program files
> where it is supposed to go?
>
> Brant Gurganus
> http://gurganus.name/brant
>
>
>
> On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
>> I have a 32-bit application that include a 32-bit shell extension dll
>> that handles thumbnails and a few other shell extensions.  I want to add
>> a 64-bit version of that same dll to the mix to get the same thumbnails
>> et al working in 64-bit Windows Explorer.
>>
>>
>>
>> Can someone tell me (or point me to documentation) what the proper way
>> is to do this?
>>
>>
>>
>> Here's what I've been using for the 32-bit dll.  The RegistryValue line
>> with [BINDIR] in the Value is the line that causes me trouble when I get
>> to 64-bit.
>>
>>
>>
>>    
>>
>>      > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>>
>>        > KeyPath="yes" Checksum="yes"/>
>>
>>        > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
>> Action="createAndRemoveOnUninstall">
>>
>>          
>>
>>          > Action="createAndRemoveOnUninstall">
>>
>>            > Value="[BINDIR]\gsi.shell.dll"/>
>>
>>            > Value="Apartment"/>
>>
>>          
>>
>>        
>>
>>      
>>
>>    
>>
>>
>>
>> [BINDIR] is defined earlier in the .wxs file as:
>>
>>
>>
>>      
>>
>>        
>>
>>          
>>
>>          
>>
>>            
>>
>>          
>>
>>        
>>
>>      
>>
>>
>>
>> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
>> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
>> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
>> er32's value is "C:\Program Files
>> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>>
>>
>>
>> Then I add the 64-bit dll similarly.  The file needs to be placed in the
>> same bin folder as the 32-bit version, but I want to be editing the
>> 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>>
>>
>>
>>    
>>
>>      > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>>
>>        > Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" Checksum="yes"/>
>>
>>        > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
>> Action="createAndRemoveOnUninstall">
>>
>>          
>>
>>          > Action="createAndRemoveOnUninstall">
>>
>>            > Value="[BINDIR]\gsi.shell64.dll"/>
>>
>>            > Value="Apartment"/>
>>
>>          
>>
>>        
>>
>>      
>>
>>    
>>
>>
>>
>> This gives me an error on the RegistryValue line with [BINDIR] in the
>> Value:
>>
>>
>>
>> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirecto

Re: [WiX-users] How to determine the wixlibrary for DeleteServices and InstallServices?

[Vidya Kukke]

Anyone?

-Original Message-
From: Vidya Kukke [mailto:vku...@microsoft.com] 
Sent: Tuesday, September 22, 2009 11:00 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] How to determine the wixlibrary for DeleteServices and 
InstallServices?

Hi,

I have a requirement to not run DeleteServices and InstallServices during PATCH 
installation. I wanted to add these CAs as part of my msi with the 'NOT PATCH' 
condition. However I get a light error with an unresolved reference for these 
CAs.  What is the best way to determine which library a CA is part of?

Thanks
Vidya
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom action type for action"

[Blair]

Lian,

Thank you for the log. The ignore on the InstallWindowsFeaturesDeferred is
working. The reason for the installation failure is the failure in the next
action: CheckRDSInstallationDeferred.

The apparent reason: A StrongName validation failed for
'Microsoft.SharedComputing.Setup.CustomAction, Version=1.0.194.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35'

Look further in the log and find these lines:
CustomAction CheckRDSInstallationDeferred returned actual error code 1603
(note this may not be 100% accurate if translation happened inside sandbox)
Action ended 11:15:15: InstallFinalize. Return value 3.

After this the rollback proceeds.
-Blair

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com] 
Sent: Tuesday, September 22, 2009 11:20 AM
To: os...@live.com
Subject: RE: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

Blair,

This is the error:

MSI (s) (80:34) [11:14:04:057]: Executing op:
ActionStart(Name=InstallWindowsFeaturesDeferred,,)
Action 11:14:04: InstallWindowsFeaturesDeferred. 
MSI (s) (80:34) [11:14:04:057]: Executing op:
CustomActionSchedule(Action=InstallWindowsFeaturesDeferred,ActionType=3137,S
ource=BinaryData,Target=CAQuietExec,CustomActionData="C:\Windows\Sysnative\d
ism.exe" /online /NoRestart /enable-feature /featurename:NetFx3
/featurename:Xps-Foundation-Xps-Viewer /featurename:InkSupport
/featurename:DesktopExperience /featurename:SearchEngine-Server-Package
/featurename:Indexing-Service-Package)
MSI (s) (80:24) [11:14:04:057]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI8723.tmp, Entrypoint: CAQuietExec
CAQuietExec:  
CAQuietExec:  Deployment Image Servicing and Management tool
CAQuietExec:  Version: 6.1.7100.0
CAQuietExec:  
CAQuietExec:  Image Version: 6.1.7100.0
CAQuietExec:  
CAQuietExec:  Enabling feature(s)
CAQuietExec:  The operation completed successfully.
CAQuietExec:  Error 0x80070bc2: Command line returned an error.
CAQuietExec:  Error 0x80070bc2: CAQuietExec Failed CustomAction
InstallWindowsFeaturesDeferred returned actual error code 1603 but will be
translated to success due to continue marking


I have attached the whole log file. 

This is the code:





We are using Windows Server 2008 R2 and the MSI version is 5.0.7100.0

Thanks for help!



Thanks
Lian

-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, September 21, 2009 6:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

Could you send the lines from the log starting from
InstallWindowsFeaturesDeferred returning to the second mention of "rollback"
following the above line? Also, which version of MSI?

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com]
Sent: Monday, September 21, 2009 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

Thanks Blair for your explanation.

I tried:




As you see, I removed "Return='ignore'" from InstallWidnowsFeatures and set
Return='ignore' in InstallWindowsFeaturesDeferred.

The compile can pass without ICE68 error but running msi failed because the
return value is not 0 (shown in the log).

Yes, I allow installation continue even this custom action failed.

Do I still miss anything?


Thanks
Lian


-Original Message-
From: Blair [mailto:os...@live.com]
Sent: Monday, September 21, 2009 4:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

A so-called SetProperty "custom" action is a built-in type (it is a Type 51
custom action), and setting a session property value isn't ever expected to
fail. Why do you want to set Return='ignore'? And what would you do in your
deferred action if the immediate SetProperty ever did fail?

Because you add the msidbCustomActionTypeContinue flag to your type 51
action, Windows Installer sees a type 115, and I assume it doesn't have any
codepath that supports a Type 115, which is why you get the ICE68 (to
prevent you from attempting it) and an "unsupported type" when you attempt
it anyway.

The one you may wish to ignore (if you don't wish to depend on it returning
a 0 result code) would be your deferred InstallWindowsFeaturesDeferred
action. That is the one that actually runs your dism.exe utility.

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com]
Sent: Monday, September 21, 2009 4:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Return='ignore' causes "ICE68: invalid custom action
type for action"

Hi,

I have a custom action:





When I compile, it failed due to ICE68 - Invalid custom action type for
action 'InstallWindowsFeatures'.

If I bypass ICE68 when linking, running the msi will fail with "Custom
action

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Brant Gurganus]

Have you looked at what things like Visual Studio do if you choose a
non-default install location (I mention it since I know it installs
32-bit and 64-bit components). My guess is that they will behave the
same. I don't think I've seen a guideline covering installation of
mixed components and where I've seen it done, 64-bit stuff goes into
ProgramFiles64Folder and 32-bit stuff goes into ProgramFilesFolder
with only one of them being customizable during installation.

By the way, the 32-bit components would be the same between 64-bit and
32-bit components so if you create two installers, the 32-bit
components should go in a merge module so component IDs remain
consistent.

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 3:32 PM, Nate Hekman  wrote:
> I just tried your suggestion, Brant, at least what I'm supposing you mean.
>
> - I set the Package's Platform='x64'
> - I extended the  section to include the ProgramFiles64Folder.  
> The Bin folder buried under there has an Id of BINDIR64.
> - I created a new  containing a Win64="yes" 
> Component, with the 64-bit dll and RegistryValues, and using [BINDIR64] in 
> the Value.
>
> Presumably that should put the 64-bit dll under the Program Files folder and 
> register it correctly, while keeping all the 32-bit components under Program 
> Files (x86).
>
> And in fact that does work.  But only if the user who's installing accepts 
> the default install path (C:\Program Files (x86)).  If they choose a 
> different install path (L:\Foo for example), then the 32-bit stuff goes to 
> L:\Foo but the 64-bit still goes to C:\Program Files.  Not what the user 
> intended.  Not good form.
>
>
> Nate
>
>
>
>
> -Original Message-
> From: Brant Gurganus [mailto:br...@gurganus.name]
> Sent: Tuesday, 22 September 2009 10:48 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app
>
> What is preventing you from installing it in the 64-bit program files
> where it is supposed to go?
>
> Brant Gurganus
> http://gurganus.name/brant
>
>
>
> On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
>> I have a 32-bit application that include a 32-bit shell extension dll
>> that handles thumbnails and a few other shell extensions.  I want to add
>> a 64-bit version of that same dll to the mix to get the same thumbnails
>> et al working in 64-bit Windows Explorer.
>>
>>
>>
>> Can someone tell me (or point me to documentation) what the proper way
>> is to do this?
>>
>>
>>
>> Here's what I've been using for the 32-bit dll.  The RegistryValue line
>> with [BINDIR] in the Value is the line that causes me trouble when I get
>> to 64-bit.
>>
>>
>>
>>    
>>
>>      > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>>
>>        > KeyPath="yes" Checksum="yes"/>
>>
>>        > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
>> Action="createAndRemoveOnUninstall">
>>
>>          
>>
>>          > Action="createAndRemoveOnUninstall">
>>
>>            > Value="[BINDIR]\gsi.shell.dll"/>
>>
>>            > Value="Apartment"/>
>>
>>          
>>
>>        
>>
>>      
>>
>>    
>>
>>
>>
>> [BINDIR] is defined earlier in the .wxs file as:
>>
>>
>>
>>      
>>
>>        
>>
>>          
>>
>>          
>>
>>            
>>
>>          
>>
>>        
>>
>>      
>>
>>
>>
>> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
>> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
>> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
>> er32's value is "C:\Program Files
>> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>>
>>
>>
>> Then I add the 64-bit dll similarly.  The file needs to be placed in the
>> same bin folder as the 32-bit version, but I want to be editing the
>> 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>>
>>
>>
>>    
>>
>>      > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>>
>>        > Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" Checksum="yes"/>
>>
>>        > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
>> Action="createAndRemoveOnUninstall">
>>
>>          
>>
>>          > Action="createAndRemoveOnUninstall">
>>
>>            > Value="[BINDIR]\gsi.shell64.dll"/>
>>
>>            > Value="Apartment"/>
>>
>>          
>>
>>        
>>
>>      
>>
>>    
>>
>>
>>
>> This gives me an error on the RegistryValue line with [BINDIR] in the
>> Value:
>>
>>
>>
>> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
>> BINDIR.
>>
>>
>>
>> I've done a lot of googling and most responses are "you shouldn't be
>> installing 64-bit dlls with a 32-bit app".  But that's absolutely not
>> true, as these dlls are used by the shell, not by my application.  There
>> must be other people with this same problem.  What's the solution?
>>
>>
>>
>> Thanks for any help!
>>
>>
>>
>>
>>
>> Nate
>>
>>
>>
>> 

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

I just tried your suggestion, Brant, at least what I'm supposing you mean.  

- I set the Package's Platform='x64'
- I extended the  section to include the ProgramFiles64Folder.  The 
Bin folder buried under there has an Id of BINDIR64.
- I created a new  containing a Win64="yes" 
Component, with the 64-bit dll and RegistryValues, and using [BINDIR64] in the 
Value.

Presumably that should put the 64-bit dll under the Program Files folder and 
register it correctly, while keeping all the 32-bit components under Program 
Files (x86).

And in fact that does work.  But only if the user who's installing accepts the 
default install path (C:\Program Files (x86)).  If they choose a different 
install path (L:\Foo for example), then the 32-bit stuff goes to L:\Foo but the 
64-bit still goes to C:\Program Files.  Not what the user intended.  Not good 
form.


Nate




-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name] 
Sent: Tuesday, 22 September 2009 10:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files
where it is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll
> that handles thumbnails and a few other shell extensions.  I want to add
> a 64-bit version of that same dll to the mix to get the same thumbnails
> et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue line
> with [BINDIR] in the Value is the line that causes me trouble when I get
> to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in the
> same bin folder as the 32-bit version, but I want to be editing the
> 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>
>         Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell64.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> This gives me an error on the RegistryValue line with [BINDIR] in the
> Value:
>
>
>
> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
> BINDIR.
>
>
>
> I've done a lot of googling and most responses are "you shouldn't be
> installing 64-bit dlls with a 32-bit app".  But that's absolutely not
> true, as these dlls are used by the shell, not by my application.  There
> must be other people with this same problem.  What's the solution?
>
>
>
> Thanks for any help!
>
>
>
>
>
> Nate
>
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.n

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Sergei Zhirikov]

Simon Dahlbacka wrote:
> On a 64 bit OS, I don't think a 32bit shell extension will ever be used, but
> this is just a hunch.

It depends on what you call "used". If you run a 32-bit application of your 
choice and use its "Open File" or "Save File" dialog - this is where 32-bit 
extensions come to the scene. How useful it is, of course, depends on each 
particular extension.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

> On a 64 bit OS, I don't think a 32bit shell extension will ever be
used, but
> this is just a hunch.

It will.  For example, a 32-bit thumbnail extension will be used on a
64-bit OS in the File Open dialog of a 32-bit app.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] remove website on uninstall

[Scharp, Craig]

Hi,

 

I created an msi install for website and database using wix 3.0.5217.0.
All works great for install.  But, I'm having trouble trying to figure
out how to delete the website on uninstall.  Has anyone done that?  If
so, any suggestions would be greatly appreciated.

 

Thanks, Craig

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Simon Dahlbacka]

On Tue, Sep 22, 2009 at 9:18 PM, Nate Hekman  wrote:

> David, what I want is to do this the right way.  I'm not "determined" to
> pursue any particular road yet.  Just trying to figure out what the "right
> way" is.
>
> I'd read Heath's blog article that you point out, and it certainly seems to
> indicate that what I'm trying is the wrong approach, but it's still not
> clear to me what the alternative looks like.  (I'm also curious why Wise had
> no difficulty doing what Heath says won't work.)
>
> My only requirements are:
> - On a 32-bit OS:  the 32-bit exe and 32-bit shell extension dll must be
> installed and registered.
> - On a 64-bit OS:  the 32-bit exe and 32-bit shell extension dll must be
> installed and registered, AND the 64-bit shell extension dll likewise.  (I
> was under the impression they would have to be in the same folder together,
> but if I'm wrong that's fine.  All I care about is that they BOTH get
> installed.)
>

On a 64 bit OS, I don't think a 32bit shell extension will ever be used, but
this is just a hunch.



> I'd rather only have one .msi to ship, but if that's not the "right way",
> I'll settle for shipping two.
>
> It's clear that if I must make multiple .msi files, then I can make one of
> them that's for my 32-bit users, that doesn't even include any 64-bit stuff.
>  That's easy.
>
> So what are you (and Heath) saying about my 64-bit users?  Do they have to
> first run a 32-bit .msi to install the exe and 32-bit dll, and then run a
> 64-bit m


A 64-bit installer can install 32 bit components just fine, it's just the
other way that does not.

/Simon



> Nate
>
>
>
>
> -Original Message-
> From: David Watson [mailto:dwat...@sdl.com]
> Sent: Tuesday, 22 September 2009 11:40 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit
> app
>
> Hi,
>The correct way to install 64 and 32 bit files onto a 64bit system
> is with separate packages, see...
>
> http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx
>
>
> >From what I understand you want to install everything into the same folder
> (which will get redirected automatically by windows) and then tie into
> explorer by inserting a key into the 64bit registry.
>
> If you are determined to do this from one 32bit msi then it may be possible
> if you author your own registry custom action that passes the extra
> parameters, see
> http://msdn.microsoft.com/en-us/library/aa384129(VS.85).aspx
>
> Dave
>
>
>
> -Original Message-
> From: Nate Hekman [mailto:hek...@geo-slope.com]
> Sent: 22 September 2009 18:22
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit
> app
>
> I'm new at this, so certainly correct me if I'm wrong, but installing it in
> a different folder doesn't sound kosher to me.  The user, for example, may
> have picked a completely different folder to install to, say "L:\My Install
> Folder".  In that case my BINDIR will map to "L:\My Install
> Folder\MyCompany\MyApplication\Bin".  I can't force the 64-bit dlls into a
> completely different part of their filesystem.
>
>
> -Original Message-
> From: Brant Gurganus [mailto:br...@gurganus.name]
> Sent: Tuesday, 22 September 2009 10:48 AM
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit
> app
>
> What is preventing you from installing it in the 64-bit program files where
> it is supposed to go?
>
> Brant Gurganus
> http://gurganus.name/brant
>
>
>
> On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman 
> wrote:
> > I have a 32-bit application that include a 32-bit shell extension dll
> > that handles thumbnails and a few other shell extensions.  I want to
> > add a 64-bit version of that same dll to the mix to get the same
> > thumbnails et al working in 64-bit Windows Explorer.
> >
> >
> >
> > Can someone tell me (or point me to documentation) what the proper way
> > is to do this?
> >
> >
> >
> > Here's what I've been using for the 32-bit dll.  The RegistryValue
> > line with [BINDIR] in the Value is the line that causes me trouble
> > when I get to 64-bit.
> >
> >
> >
> >
> >
> >   > Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
> >
> > > KeyPath="yes" Checksum="yes"/>
> >
> > > Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> > Action="createAndRemoveOnUninstall">
> >
> >  
> >
> >   > Action="createAndRemoveOnUninstall">
> >
> > > Value="[BINDIR]\gsi.shell.dll"/>
> >
> > > Value="Apartment"/>
> >
> >  
> >
> >
> >
> >  
> >
> >
> >
> >
> >
> > [BINDIR] is defined earlier in the .wxs file as:
> >
> >
> >
> >  
> >
> >
> >
> >  
> >
> >  
> >
> >  

Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom action type for action"

[Lian Jiang]

Blair, 

I have sent the information to your personal email.

Thanks
Lian

-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, September 21, 2009 6:35 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom action 
type for action"

Could you send the lines from the log starting from
InstallWindowsFeaturesDeferred returning to the second mention of "rollback"
following the above line? Also, which version of MSI?

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com] 
Sent: Monday, September 21, 2009 5:16 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

Thanks Blair for your explanation.

I tried:




As you see, I removed "Return='ignore'" from InstallWidnowsFeatures and set
Return='ignore' in InstallWindowsFeaturesDeferred.

The compile can pass without ICE68 error but running msi failed because the
return value is not 0 (shown in the log).

Yes, I allow installation continue even this custom action failed.

Do I still miss anything?


Thanks
Lian


-Original Message-
From: Blair [mailto:os...@live.com] 
Sent: Monday, September 21, 2009 4:46 PM
To: 'General discussion for Windows Installer XML toolset.'
Subject: Re: [WiX-users] Return='ignore' causes "ICE68: invalid custom
action type for action"

A so-called SetProperty "custom" action is a built-in type (it is a Type 51
custom action), and setting a session property value isn't ever expected to
fail. Why do you want to set Return='ignore'? And what would you do in your
deferred action if the immediate SetProperty ever did fail?

Because you add the msidbCustomActionTypeContinue flag to your type 51
action, Windows Installer sees a type 115, and I assume it doesn't have any
codepath that supports a Type 115, which is why you get the ICE68 (to
prevent you from attempting it) and an "unsupported type" when you attempt
it anyway.

The one you may wish to ignore (if you don't wish to depend on it returning
a 0 result code) would be your deferred InstallWindowsFeaturesDeferred
action. That is the one that actually runs your dism.exe utility.

-Original Message-
From: Lian Jiang [mailto:lji...@microsoft.com] 
Sent: Monday, September 21, 2009 4:27 PM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Return='ignore' causes "ICE68: invalid custom action
type for action"

Hi,

I have a custom action:





When I compile, it failed due to ICE68 - Invalid custom action type for
action 'InstallWindowsFeatures'.

If I bypass ICE68 when linking, running the msi will fail with "Custom
action InstallWindowsFeatures specifies unsupported type".

The trick is that if I change the highlighted 'ignore'Johto 'check', then
compile will pass without bypassing ICE68.

Does anybody know why I cannot use Return='ignore'?

Appreciate very much!


Thanks
Lian





--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us fro

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

David, what I want is to do this the right way.  I'm not "determined" to pursue 
any particular road yet.  Just trying to figure out what the "right way" is.

I'd read Heath's blog article that you point out, and it certainly seems to 
indicate that what I'm trying is the wrong approach, but it's still not clear 
to me what the alternative looks like.  (I'm also curious why Wise had no 
difficulty doing what Heath says won't work.)

My only requirements are:
- On a 32-bit OS:  the 32-bit exe and 32-bit shell extension dll must be 
installed and registered.
- On a 64-bit OS:  the 32-bit exe and 32-bit shell extension dll must be 
installed and registered, AND the 64-bit shell extension dll likewise.  (I was 
under the impression they would have to be in the same folder together, but if 
I'm wrong that's fine.  All I care about is that they BOTH get installed.)

I'd rather only have one .msi to ship, but if that's not the "right way", I'll 
settle for shipping two.

It's clear that if I must make multiple .msi files, then I can make one of them 
that's for my 32-bit users, that doesn't even include any 64-bit stuff.  That's 
easy.

So what are you (and Heath) saying about my 64-bit users?  Do they have to 
first run a 32-bit .msi to install the exe and 32-bit dll, and then run a 
64-bit msi to install the 64-bit dll?  Or can I somehow make the 32-bit msi 
call the 64-bit one so it's transparent to the user?

Likewise when it comes time to uninstall, will the 64-bit user have to first 
uninstall the 64-bit dll, followed by a second step to uninstall the main 
application?

My apologies if there's something really obvious I'm not grasping.  I am new to 
this and need things spelled out!

Thanks for your help.


Nate




-Original Message-
From: David Watson [mailto:dwat...@sdl.com] 
Sent: Tuesday, 22 September 2009 11:40 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

Hi,
The correct way to install 64 and 32 bit files onto a 64bit system is 
with separate packages, see...

http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx


>From what I understand you want to install everything into the same folder 
>(which will get redirected automatically by windows) and then tie into 
>explorer by inserting a key into the 64bit registry.

If you are determined to do this from one 32bit msi then it may be possible if 
you author your own registry custom action that passes the extra parameters, 
see http://msdn.microsoft.com/en-us/library/aa384129(VS.85).aspx

Dave



-Original Message-
From: Nate Hekman [mailto:hek...@geo-slope.com] 
Sent: 22 September 2009 18:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

I'm new at this, so certainly correct me if I'm wrong, but installing it in a 
different folder doesn't sound kosher to me.  The user, for example, may have 
picked a completely different folder to install to, say "L:\My Install Folder". 
 In that case my BINDIR will map to "L:\My Install 
Folder\MyCompany\MyApplication\Bin".  I can't force the 64-bit dlls into a 
completely different part of their filesystem.


-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name]
Sent: Tuesday, 22 September 2009 10:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files where it 
is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll 
> that handles thumbnails and a few other shell extensions.  I want to 
> add a 64-bit version of that same dll to the mix to get the same 
> thumbnails et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way 
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue 
> line with [BINDIR] in the Value is the line that causes me trouble 
> when I get to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program 
> Files (x86)\MyCo

[WiX-users] How to determine the wixlibrary for DeleteServices and InstallServices?

[Vidya Kukke]

Hi,

I have a requirement to not run DeleteServices and InstallServices during PATCH 
installation. I wanted to add these CAs as part of my msi with the 'NOT PATCH' 
condition. However I get a light error with an unresolved reference for these 
CAs.  What is the best way to determine which library a CA is part of?

Thanks
Vidya
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[David Watson]

Hi,
The correct way to install 64 and 32 bit files onto a 64bit system is 
with separate packages, see...

http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-required-for-different-processor-architectures.aspx


>From what I understand you want to install everything into the same folder 
>(which will get redirected automatically by windows) and then tie into 
>explorer by inserting a key into the 64bit registry.

If you are determined to do this from one 32bit msi then it may be possible if 
you author your own registry custom action that passes the extra parameters, 
see http://msdn.microsoft.com/en-us/library/aa384129(VS.85).aspx

Dave



-Original Message-
From: Nate Hekman [mailto:hek...@geo-slope.com] 
Sent: 22 September 2009 18:22
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

I'm new at this, so certainly correct me if I'm wrong, but installing it in a 
different folder doesn't sound kosher to me.  The user, for example, may have 
picked a completely different folder to install to, say "L:\My Install Folder". 
 In that case my BINDIR will map to "L:\My Install 
Folder\MyCompany\MyApplication\Bin".  I can't force the 64-bit dlls into a 
completely different part of their filesystem.


-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name]
Sent: Tuesday, 22 September 2009 10:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files where it 
is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll 
> that handles thumbnails and a few other shell extensions.  I want to 
> add a 64-bit version of that same dll to the mix to get the same 
> thumbnails et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way 
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue 
> line with [BINDIR] in the Value is the line that causes me trouble 
> when I get to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program 
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key 
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocSe
> rv
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in 
> the same bin folder as the 32-bit version, but I want to be editing 
> the 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>
>         Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" 
> Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell64.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> This gives me an error on the RegistryValue line with [BINDIR] in the
> Value:
>
>
>
> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 
> 32BitDirectory BINDIR.
>
>
>
> I've done a lot of googling and most responses are "you shouldn't be 
> installing 64-bit dlls with a 32-bit app".  But that's absolutely not 
> true, as these dlls are used by the shell, not by my application.  
> There must be other people with this same problem.  What's the solution?
>
>
>
> Thanks for any help!
>
>
>
>
>
> Nate
>
>
>
> --
>  Come build with us! The BlackBerry® Developer Conference 
> in SF, CA is the only developer event you need to attend this year. 
> Jumpstart your developing skills, take BlackBerry mobile applications 
> to market and stay ahead of the curve. Join us from November 9-12, 
> 2009. Register now! http://p.sf.net/sfu/devconf 
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

So are you saying I'd tell my users on 64-bit machines to use my "setup64.msi" 
file and my 32-bit users to use a "setup32.msi"?  Or that the main setup32.msi 
would call a setup64.msi to do the 64-bit part?

I haven't tried it, but I don't think either of those options will help.  
Remember, this is a 32-bit application, therefore it must be installed in the 
32-bit Program Files (x86) folder.  Despite Brant's question, I don't (yet) 
believe the 64-bit dll is supposed to be installed somewhere else.  So 
ultimately the 64-bit msi is going to be told to write a Registry value in the 
64-bit portion of the Registry but pointing to the 32-bit Program Files (x86) 
folder.  Ergo, same error.

Interestingly, I've accomplished what I'm trying to do using Wise with no 
problem.  I simply added the 64-bit dll to the same Bin folder as everything 
else, marked the component as 64-bit so the Registry values would be written to 
the 64-bit portion of the registry, and it works just fine.  So it does not 
seem to me to be a limitation or restriction of Windows Installer.


To clarify some things:
- The dll is being saved to disk just fine.  It's 64-bit and it's being put in 
the 32-bit Program Files folder, yes, but Windows Installer isn't complaining 
about that so I'm fine with it.
- The part that isn't working is just writing a value to the Registry.  It 
seems to me Windows Installer should let me write whatever I want.  I can write 
"foobar", I just can't write "[BINDIR]".  I could presumably hard-code it to 
"c:\program files (x86)\etc" and get no error, but of course that won't get me 
what I want.

Maybe I can avoid the problem by copying the BINDIR path to a local variable of 
some sort, so that Wix loses sight of the fact that it's a path, and just sees 
it as a string?


Ultimately though I'm trying to learn what's the "proper" Windows Installer 
solution to this problem.  A workaround would be nice, but a proper solution 
would be best.  How is a 32-bit application with a 64-bit shell extension 
*supposed* to register the extension?


Nate



-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Tuesday, 22 September 2009 11:04 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

WIN64DUALFOLDERS is I expect since the MSI is compiled as 32-bit.

Brant the solution is to have separate 32-bit and 64-bit MSI's. You can't make 
a "one-size fits all" package using Windows Installer.
 
Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer
 

-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name] 
Sent: 22 September 2009 17:48
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files where it 
is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll 
> that handles thumbnails and a few other shell extensions.  I want to 
> add a 64-bit version of that same dll to the mix to get the same 
> thumbnails et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way 
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue 
> line with [BINDIR] in the Value is the line that causes me trouble 
> when I get to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program 
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key 
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocSe
> rv
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in 
> the same bin folder as the 32-bit version, but I want to be editing 
> the 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>

[WiX-users] How to schedule RemoveFile

[Arvind Aiyar]

I need to delete a file foo.dll from the SYSTEM folder on uninstall. This 
foo.dll is generated by a Custom Action in the installer. Since foo.dll is not 
part of the originally installed files so I use the RemoveFile to do this and 
specify the file to be deleted on uninstall. However, since it's a system file, 
I get the reboot will be required dialog. Is there a way to suppress this ? Or 
maybe schedule the RemoveFile until later when my Custom Action is done using 
it ?

-Arvind

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Localization strings

[Danielle k]

I am creating an installtion similar to WIXUI_InstallDir with some
customizations (new dialog pages). I would like to review all the
strings that are relevant to the installer and adjust them to my
product.
How can i know what strings in the wixui_enus.xwl are relevant?
How can i know which strings will be presented in the remove and repair flows?
is there any table that relates the strings there to the dialogs\flows?

Thanks

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Property from command line not working

[Danielle k]

It worked! i tried to set the wrong property = WIXUI_INSTALLDIR
instead of INSTALLDIR
Thank you!

On Tue, Sep 22, 2009 at 6:17 PM,
 wrote:
> Send WiX-users mailing list submissions to
>        wix-us...@lists.sourceforge.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
>        https://lists.sourceforge.net/lists/listinfo/wix-users
> or, via email, send a message with subject or body 'help' to
>        wix-users-requ...@lists.sourceforge.net
>
> You can reach the person managing the list at
>        wix-users-ow...@lists.sourceforge.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of WiX-users digest..."
>
>
> Today's Topics:
>
>   1. Re: Light.exe failing with error 1719 (Kiran Kumar Kolli)
>   2. Re: Ping Server from dialog (Simon Topley)
>   3. Re: Light.exe failing with error 1719 (Peter Shirtcliffe)
>   4. Re: Property from command line not working (Khyati Mehta)
>   5.  How to execute .Net Framework Condition at Last (danimian)
>   6. Re: Ping Server from dialog (Simon Topley)
>
>
> --
>
> Message: 1
> Date: Tue, 22 Sep 2009 21:41:26 +0800
> From: Kiran Kumar Kolli 
> Subject: Re: [WiX-users] Light.exe failing with error 1719
> To: General discussion for Windows Installer XML toolset.
>        
> Message-ID:
>        
> <3bf4618448e53346854ef0f7a69dca08231a861...@aa-exmsg-c426.southpacific.corp.microsoft.com>
>
> Content-Type: text/plain; charset="us-ascii"
>
> Peter, thanks for the quick information. Also when you say "do validation 
> somewhere else", can light.exe do it again or is there some other tool which 
> can do it.
>
> -Original Message-
> From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
> Sent: 22 September 2009 18:52
> To: General discussion for Windows Installer XML toolset.
> Subject: Re: [WiX-users] Light.exe failing with error 1719
>
> The event log entry is added when light calls the windows installer service 
> to perform ice validation. I imagine that, just as you can't run the execute 
> sequence of several installers at once, you can't run several validations at 
> the same time either.
>
> I searched and found this thread that seems to support this.
> http://sourceforge.net/mailarchive/message.php?msg_id=A00CB80DE3F3D1429D
> 317D978E4B8FE14063747B48%40NA-EXMSG-C125.redmond.corp.microsoft.com
>
> Adding -sval to your light command lines will prevent the error, but it's 
> advisable to do validation somewhere else if you do.
>
> -Original Message-
> From: Kiran Kumar Kolli [mailto:kiran.ko...@microsoft.com]
> Sent: 22 September 2009 13:59
> To: wix-users@lists.sourceforge.net
> Subject: [WiX-users] Light.exe failing with error 1719
>
> In our builds we are seeing occasional failures such as follows
> 2>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\1>e:\v7sp2
> \private\source\common\sku\oslomergemodules\partner\loc\en\light.exe :
> error LGHT0217 : An unexpected external UI message was received: The Windows 
> Installer Service could not be accessed. This can occur if the Windows 
> Installer is not correctly installed. Contact your support personnel for 
> assistance.
>
> And event log at that time had the following error too
> Product:  -- Error 1719. The Windows Installer Service could not be accessed. 
> This can occur if the Windows Installer is not correctly installed. Contact 
> your support personnel for assistance.
>
> In our build environment there can be multiple light.exe running in parallel. 
> When we build each one individually we are not seeing any issues.
>
> Also while light.exe is executing its adding few event-log entries like 
> "Windows Installer installed the product. Product Name: . Product
> Version: . Product Language: . Installation success or error status: 0."
>
> Can someone help us understand what's happening here and how to fix this 
> issue.
>
> Build machine: Windows Server 2008 SP1.
>
> Thanks In advance,
> Kiran Kumar
>
> 
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA is the 
> only developer event you need to attend this year. Jumpstart your developing 
> skills, take BlackBerry mobile applications to market and stay ahead of the 
> curve. Join us from November 9-12, 2009. Register now! 
> http://p.sf.net/sfu/devconf ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
> SDL PLC confidential, all rights reserved.
> If you are not the intended recipient of this mail SDL requests and requires 
> that you delete it without acting upon or copying any of its contents, and we 
> further request that you advise us.
> SDL PLC is a public limited company registered in England and Wales.  
> Registered number: 02675207.
> Registered address: Globe House, Clivemont Road, Maiden

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

I'm new at this, so certainly correct me if I'm wrong, but installing it in a 
different folder doesn't sound kosher to me.  The user, for example, may have 
picked a completely different folder to install to, say "L:\My Install Folder". 
 In that case my BINDIR will map to "L:\My Install 
Folder\MyCompany\MyApplication\Bin".  I can't force the 64-bit dlls into a 
completely different part of their filesystem.


-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name] 
Sent: Tuesday, 22 September 2009 10:48 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files
where it is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll
> that handles thumbnails and a few other shell extensions.  I want to add
> a 64-bit version of that same dll to the mix to get the same thumbnails
> et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue line
> with [BINDIR] in the Value is the line that causes me trouble when I get
> to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in the
> same bin folder as the 32-bit version, but I want to be editing the
> 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>
>         Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell64.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> This gives me an error on the RegistryValue line with [BINDIR] in the
> Value:
>
>
>
> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
> BINDIR.
>
>
>
> I've done a lot of googling and most responses are "you shouldn't be
> installing 64-bit dlls with a 32-bit app".  But that's absolutely not
> true, as these dlls are used by the shell, not by my application.  There
> must be other people with this same problem.  What's the solution?
>
>
>
> Thanks for any help!
>
>
>
>
>
> Nate
>
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
_

[WiX-users] VS Schema - registering help files

[Rob Hamflett]

Hello,

I'm trying to get some documents registered with Visual Studio but I'm not 
having much luck.  I've 
got a heirarchy of namespaces to register, and then the last one actually 
contains the help files. 
I'm currently just trying to see if I can register the first namespace.  I have 
the following WiX code:




   







Is there anything hugely wrong with this?  I think I'm having trouble with the 
vs:plugcollectioni...@targettableofcontents value.  It's not required, but the 
2 examples of this I 
can find use it, but with strange values (like "FL_vsipcc_hxt_86880") 
and I'm not sure where 
they come from.  Is it needed for the top namespace?  Is it possible that 
without any actual help 
files registered, the namespace isn't showing up in Visual Studio Help?

I've seen references to adding merge modules, but these are from newsgroup 
posts that are bit old, 
and WiX doesn't complain about them not being there.  I'm just using "-ext 
WixVSExtension" on the 
command lines to candle and light.

Would a log file be of any use to anyone?  I don't really understand this VS 
help file registration 
stuff so it was no help when I tried to look through one myself.

I know the help files are OK because the current in-house method is to register 
them with h2reg, and 
that's fine.

Thanks,
Rob


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Pally Sandher]

WIN64DUALFOLDERS is I expect since the MSI is compiled as 32-bit.

Brant the solution is to have separate 32-bit and 64-bit MSI's. You can't make 
a "one-size fits all" package using Windows Installer.
 
Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 
Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 
0SP
Email Disclaimer
 

-Original Message-
From: Brant Gurganus [mailto:br...@gurganus.name] 
Sent: 22 September 2009 17:48
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

What is preventing you from installing it in the 64-bit program files where it 
is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll 
> that handles thumbnails and a few other shell extensions.  I want to 
> add a 64-bit version of that same dll to the mix to get the same 
> thumbnails et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way 
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue 
> line with [BINDIR] in the Value is the line that causes me trouble 
> when I get to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program 
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key 
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocSe
> rv
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in 
> the same bin folder as the 32-bit version, but I want to be editing 
> the 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>
>         Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" 
> Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell64.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> This gives me an error on the RegistryValue line with [BINDIR] in the
> Value:
>
>
>
> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 
> 32BitDirectory BINDIR.
>
>
>
> I've done a lot of googling and most responses are "you shouldn't be 
> installing 64-bit dlls with a 32-bit app".  But that's absolutely not 
> true, as these dlls are used by the shell, not by my application.  
> There must be other people with this same problem.  What's the solution?
>
>
>
> Thanks for any help!
>
>
>
>
>
> Nate

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] XmlFile being executed when feature condition should fail

[Wilson, Phil]

As far as I can tell, what you have there is a component declaration with a 
condition about whether it should be installed or not.  

However the issue seems to be that the custom action ' SchedXmlFile' is being 
called, so what matters is the condition you have on that custom action call, 
in the UI/Execute/event tables, wherever it's called from. 

(You may have previously posted that info, but it's been deleted from this 
response.)

Phil Wilson 


-Original Message-
From: si [mailto:sshnug...@gmail.com] 
Sent: Monday, September 21, 2009 11:54 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] XmlFile being executed when feature condition should 
fail

>> Long story short: XmlFile is being executed during upgrades when I
>> only want it executed on new installations.
>>
>
> The owning component controls whether XmlFile is run; conditionalize it
> so it doesn't run during upgrade.

Thanks for the reply Bob, unfortunately I already tried this with no luck:


  NOT Installed AND USEINTEGRATEDSECURITY = 1
  



  NOT Installed AND NOT USEINTEGRATEDSECURITY = 1>
  


I tried both "NOT Installed" and "NOT UPGRADEFOUND" for the component
condition, neither worked.

I was wondering if it may be because the custom UI we show for
collecting sql credentials wasn't being shown on upgrades, so the
property values would be null, but I don't understand why the
connectionString attribue is empty, rather than
"Database=;Server=;uid=;pwd;" which is what I would've expected if the
properties were empty.

Looking, through the upgrade log file, it appears that
ExecXmlFileRollback action is being called:

MSI (s) (28:A8) [16:09:22:671]: Doing action: SchedXmlFile
Action 16:09:22: SchedXmlFile.
Action start 16:09:22: SchedXmlFile.
MSI (s) (28:14) [16:09:22:677]: Invoking remote custom action. DLL:
C:\Windows\Installer\MSI8A93.tmp, Entrypoint: SchedXmlFile
MSI (s) (28!1C) [16:09:22:719]: PROPERTY CHANGE: Adding
ExecXmlFileRollback property. Its value is '0€C:\Program Files
(x86)\blah\\web.config�...@xx[snip]
MSI (s) (28!1C) [16:09:22:720]: Doing action: ExecXmlFileRollback
Action 16:09:22: ExecXmlFileRollback.
Action start 16:09:22: ExecXmlFileRollback.
ExecXmlFileRollback:
Action ended 16:09:22: ExecXmlFileRollback. Return value 1.
MSI (s) (28!1C) [16:09:22:726]: PROPERTY CHANGE: Adding ExecXmlFile
property. Its value is '1€0€C:\Program Files
(x86)\Blah\\Web.config€4€0€/configuration/connectionStrings/a...@name='Database']/@connectionString€€Database=Blah;Server=(local);Integrated
Security=SSPI;'.
MSI (s) (28!1C) [16:09:22:727]: Doing action: ExecXmlFile
Action 16:09:22: ExecXmlFile.
Action start 16:09:22: ExecXmlFile.
ExecXmlFile:
Action ended 16:09:22: ExecXmlFile. Return value 1.
Action ended 16:09:22: SchedXmlFile. Return value 1.


Another potential issue is that we create the web.config on install
using CopyFile, and run SchedXmlFile after DuplicateFiles.  I don't
think this would cause a problem, but figured it was worth a mention.

Thanks again.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app

[Brant Gurganus]

What is preventing you from installing it in the 64-bit program files
where it is supposed to go?

Brant Gurganus
http://gurganus.name/brant



On Tue, Sep 22, 2009 at 12:14 PM, Nate Hekman  wrote:
> I have a 32-bit application that include a 32-bit shell extension dll
> that handles thumbnails and a few other shell extensions.  I want to add
> a 64-bit version of that same dll to the mix to get the same thumbnails
> et al working in 64-bit Windows Explorer.
>
>
>
> Can someone tell me (or point me to documentation) what the proper way
> is to do this?
>
>
>
> Here's what I've been using for the 32-bit dll.  The RegistryValue line
> with [BINDIR] in the Value is the line that causes me trouble when I get
> to 64-bit.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D">
>
>         KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> [BINDIR] is defined earlier in the .wxs file as:
>
>
>
>      
>
>        
>
>          
>
>          
>
>            
>
>          
>
>        
>
>      
>
>
>
> So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
> Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
> HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
> er32's value is "C:\Program Files
> (x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".
>
>
>
> Then I add the 64-bit dll similarly.  The file needs to be placed in the
> same bin folder as the 32-bit version, but I want to be editing the
> 64-bit portion of the Registry, so I add Win64="yes" to the Component.
>
>
>
>    
>
>       Guid="2EAEEF9B-7385-4d12-811C-68E26FB5E66D" Win64="yes">
>
>         Source="$(var.TargetDir)GSI.Shell64.dll" KeyPath="yes" Checksum="yes"/>
>
>         Key="CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}"
> Action="createAndRemoveOnUninstall">
>
>          
>
>           Action="createAndRemoveOnUninstall">
>
>             Value="[BINDIR]\gsi.shell64.dll"/>
>
>             Value="Apartment"/>
>
>          
>
>        
>
>      
>
>    
>
>
>
> This gives me an error on the RegistryValue line with [BINDIR] in the
> Value:
>
>
>
> Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
> BINDIR.
>
>
>
> I've done a lot of googling and most responses are "you shouldn't be
> installing 64-bit dlls with a 32-bit app".  But that's absolutely not
> true, as these dlls are used by the shell, not by my application.  There
> must be other people with this same problem.  What's the solution?
>
>
>
> Thanks for any help!
>
>
>
>
>
> Nate
>
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Ping Server from dialog

[Simon Topley]

me again!

Essentially my question now is how do i get meaningful return values
using "ignore" or "check" and put them in a Property without the
installer ending due to the return value?

I've managed to change the command argument with other customactions
that change the QtExecCmdLine property, which i call from the dialog in
the same way i call the CAQuietExec action.

It seems that the return values i get from these custom actions varies a
great deal based on what i put in the "return" field. Obviously that is
a foolish statement but all the same. The result I get is that Check or
ignore both get a return value of 1 regardless of the argument I use, so
if i ping localhost i get the same result as if i ping
".aiodopyhdolhrxrlaoediou". If I use the asyn return types it is more
accurate as in i get a 0 or a 1630 error, however this is not consistent
as the custom actions are smashing into each other because they are
async.


-Original Message-
From: Simon Topley 
Sent: 22 September 2009 16:17
To: 'wix-users@lists.sourceforge.net'
Subject: RE: Ping Server from dialog

I've triggered it from the dialog using DoAction:


  1
  1




I still haven't taclked putting the return value in a property, but i
notice that you don't tell CAQuietExec to use QtExecCmdLine, so when i
came to adding a second command line call I hit a wall, is there a way
to specify what property should be used by CAQuietExec?

Simon

-Original Message-
From: Simon Topley 
Sent: 22 September 2009 15:31
To: wix-users@lists.sourceforge.net
Subject: RE: Ping Server from dialog

Ok I have it running ping using CAQuietExec, I think this maybe a step
in the right direction. I just need to deal with triggering it from a
dialog button click and capturing the return value to inspect, so I can
display an appropriate message.


  
  
  
NOT
Installed
  



Disclaimer: This electronic communication and its attachments may contain 
confidential, proprietary and/or legally privileged information which are for 
the sole use of the intended recipient. If you are not the intended recipient, 
any use, distribution, or reproduction of this communication is strictly 
prohibited and may be unlawful; please contact the sender and delete this 
communication. MWH does not warrant or make any representation regarding this 
transmission whatsoever nor does it warrant that it is free from viruses or 
defects, correct or reliable. MWH is not liable for any loss or damage that 
occurs as a result of this communication entering your computer network.

The views expressed in this message are not necessarily those of MWH. This 
communication cannot form a binding agreement unless that is the express intent 
of the parties and they are authorized to make such an agreement. MWH reserves 
all intellectual property rights contained in this transmission. MWH reserves 
the right to monitor any electronic communication sent or received by its 
employees. This communication may come from a variety of legal entities within 
or associated with the MWH group.

For a full list of details for these entities please see our website at 
www.mwhglobal.com. Where business communications relate to the MWH UK Limited 
entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, 
HP13 5AJ Tel: 01494 526240 and the company is registered in England as 
registration number 01188070. Where business communications relate to the MWH 
Constructors Limited entity, the registered office is as above and the company 
is registered in England as registration number 04635724. Where business 
communications relate to the MWH Soft Limited entity, the registered office is 
as above and the company is registered in England as registration number 
6975921.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Installing 64-bit shell extension with a 32-bit app

[Nate Hekman]

I have a 32-bit application that include a 32-bit shell extension dll
that handles thumbnails and a few other shell extensions.  I want to add
a 64-bit version of that same dll to the mix to get the same thumbnails
et al working in 64-bit Windows Explorer.

 

Can someone tell me (or point me to documentation) what the proper way
is to do this?

 

Here's what I've been using for the 32-bit dll.  The RegistryValue line
with [BINDIR] in the Value is the line that causes me trouble when I get
to 64-bit.

 

 

  





  

  





  



  



 

[BINDIR] is defined earlier in the .wxs file as:

 

  



  

  



  



  

 

So on a 64-bit OS that installs the GSI.Shell.dll file into C:\Program
Files (x86)\MyCompany\MyApplication\Bin, and the Registry key
HKCR\Wow6432Node\CLSID\{5D1A01C2-BD6D-45c7-BC8E-C419E2F08B70}\InprocServ
er32's value is "C:\Program Files
(x86)\MyCompany\MyApplication\Bin\gsi.shell.dll".

 

Then I add the 64-bit dll similarly.  The file needs to be placed in the
same bin folder as the 32-bit version, but I want to be editing the
64-bit portion of the Registry, so I add Win64="yes" to the Component.

 

 

  





  

  





  



  



 

This gives me an error on the RegistryValue line with [BINDIR] in the
Value:

 

Error LGHT0204: ICE80: This 64BitCompnent GSIShell64 uses 32BitDirectory
BINDIR.

 

I've done a lot of googling and most responses are "you shouldn't be
installing 64-bit dlls with a 32-bit app".  But that's absolutely not
true, as these dlls are used by the shell, not by my application.  There
must be other people with this same problem.  What's the solution?

 

Thanks for any help!

 

 

Nate

 

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Ping Server from dialog

[Simon Topley]

I've triggered it from the dialog using DoAction:


  1
  1




I still haven't taclked putting the return value in a property, but i
notice that you don't tell CAQuietExec to use QtExecCmdLine, so when i
came to adding a second command line call I hit a wall, is there a way
to specify what property should be used by CAQuietExec?

Simon

-Original Message-
From: Simon Topley 
Sent: 22 September 2009 15:31
To: wix-users@lists.sourceforge.net
Subject: RE: Ping Server from dialog

Ok I have it running ping using CAQuietExec, I think this maybe a step
in the right direction. I just need to deal with triggering it from a
dialog button click and capturing the return value to inspect, so I can
display an appropriate message.


  
  
  
NOT
Installed
  



Disclaimer: This electronic communication and its attachments may contain 
confidential, proprietary and/or legally privileged information which are for 
the sole use of the intended recipient. If you are not the intended recipient, 
any use, distribution, or reproduction of this communication is strictly 
prohibited and may be unlawful; please contact the sender and delete this 
communication. MWH does not warrant or make any representation regarding this 
transmission whatsoever nor does it warrant that it is free from viruses or 
defects, correct or reliable. MWH is not liable for any loss or damage that 
occurs as a result of this communication entering your computer network.

The views expressed in this message are not necessarily those of MWH. This 
communication cannot form a binding agreement unless that is the express intent 
of the parties and they are authorized to make such an agreement. MWH reserves 
all intellectual property rights contained in this transmission. MWH reserves 
the right to monitor any electronic communication sent or received by its 
employees. This communication may come from a variety of legal entities within 
or associated with the MWH group.

For a full list of details for these entities please see our website at 
www.mwhglobal.com. Where business communications relate to the MWH UK Limited 
entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, 
HP13 5AJ Tel: 01494 526240 and the company is registered in England as 
registration number 01188070. Where business communications relate to the MWH 
Constructors Limited entity, the registered office is as above and the company 
is registered in England as registration number 04635724. Where business 
communications relate to the MWH Soft Limited entity, the registered office is 
as above and the company is registered in England as registration number 
6975921.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] How to execute .Net Framework Condition at Last

[danimian]

Hi,
our installation project have 4 conditions for checking the system
requirements.
1. User is Administrator or not.
2. Windows XP with SP2 is available or not.
3. .NetFramework, if not the generate Bootstrapper
4. DB2 Client is available or not.
All are working well But the problem is if we execute setup.exe, it executes
.Net Framework Condition first from code, after completing .Net Framework
installation (generating Bootstrapper) it checks other conditions.

Problem: Our requirements are first execute all other Conditions first and
last check must be on .Net Framework. How to execute .Net Framework
condition at last ???

Best Regards
Adnan
-- 
View this message in context: 
http://n2.nabble.com/How-to-execute-Net-Framework-Condition-at-Last-tp3693467p3693467.html
Sent from the wix-users mailing list archive at Nabble.com.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Property from command line not working

[Khyati Mehta]

In your command, you should specify INSTALLDIR and not TARGETDIR. I'm not
sure what are you using, as you haven't mentioned anything.
command: msiexec.exe /i "" INSTALLDIR=""

On Mon, Sep 21, 2009 at 1:33 PM, Daniel Kubovsky wrote:

> In my WIX source 2 properties are defined (both are path to folders)
> their default is directories I created in the wix. for example:
>
>   
>  
> Guid="0E9D7374-5CA0-4229-913F-292452777A38">
>   WIXUI_INSTALLDIR
>   Source="C.dll" KeyPath="yes"/>
>   .
>   .
>   
>
>   from the definition you can see that the default value is c:\p
>
>   The property is presented and set in an install dialog and it works
>  fine with UI.
>   Yet, from command line when setting the parameter to some other
> value   it still install to c:\p ignoring the parameter set.
>  Also in the logs I can see the overwriting.
>   - why is that?
>
>
>   Any ideas?
>   Thanks Inbal
>
>
> --
> Come build with us! The BlackBerry® Developer Conference in SF, CA
> is the only developer event you need to attend this year. Jumpstart your
> developing skills, take BlackBerry mobile applications to market and stay
> ahead of the curve. Join us from November 9-12, 2009. Register now!
> http://p.sf.net/sfu/devconf
> ___
> WiX-users mailing list
> WiX-users@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/wix-users
>
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Light.exe failing with error 1719

[Peter Shirtcliffe]

You can validate with Orca or, if you want an automated solution, you
can use smoke.exe from the wix tool set to validate the MSIs
sequentially in a build.

-Original Message-
From: Kiran Kumar Kolli [mailto:kiran.ko...@microsoft.com] 
Sent: 22 September 2009 14:41
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Light.exe failing with error 1719

Peter, thanks for the quick information. Also when you say "do
validation somewhere else", can light.exe do it again or is there some
other tool which can do it. 

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com]
Sent: 22 September 2009 18:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Light.exe failing with error 1719

The event log entry is added when light calls the windows installer
service to perform ice validation. I imagine that, just as you can't run
the execute sequence of several installers at once, you can't run
several validations at the same time either.

I searched and found this thread that seems to support this. 
http://sourceforge.net/mailarchive/message.php?msg_id=A00CB80DE3F3D1429D
317D978E4B8FE14063747B48%40NA-EXMSG-C125.redmond.corp.microsoft.com

Adding -sval to your light command lines will prevent the error, but
it's advisable to do validation somewhere else if you do.

-Original Message-
From: Kiran Kumar Kolli [mailto:kiran.ko...@microsoft.com]
Sent: 22 September 2009 13:59
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Light.exe failing with error 1719

In our builds we are seeing occasional failures such as follows
2>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\1>e:\v7sp2
\private\source\common\sku\oslomergemodules\partner\loc\en\light.exe :
error LGHT0217 : An unexpected external UI message was received: The
Windows Installer Service could not be accessed. This can occur if the
Windows Installer is not correctly installed. Contact your support
personnel for assistance.

And event log at that time had the following error too
Product:  -- Error 1719. The Windows Installer Service could not be
accessed. This can occur if the Windows Installer is not correctly
installed. Contact your support personnel for assistance.

In our build environment there can be multiple light.exe running in
parallel. When we build each one individually we are not seeing any
issues.

Also while light.exe is executing its adding few event-log entries like
"Windows Installer installed the product. Product Name: . Product
Version: . Product Language: . Installation success or error status: 0."

Can someone help us understand what's happening here and how to fix this
issue.

Build machine: Windows Server 2008 SP1.

Thanks In advance,
Kiran Kumar


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and
requires that you delete it without acting upon or copying any of its
contents, and we further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.
Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire
SL6 7DY, UK.



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is th

Re: [WiX-users] Ping Server from dialog

[Simon Topley]

Ok I have it running ping using CAQuietExec, I think this maybe a step
in the right direction. I just need to deal with triggering it from a
dialog button click and capturing the return value to inspect, so I can
display an appropriate message.


  
  
  
NOT
Installed
  



Disclaimer: This electronic communication and its attachments may contain 
confidential, proprietary and/or legally privileged information which are for 
the sole use of the intended recipient. If you are not the intended recipient, 
any use, distribution, or reproduction of this communication is strictly 
prohibited and may be unlawful; please contact the sender and delete this 
communication. MWH does not warrant or make any representation regarding this 
transmission whatsoever nor does it warrant that it is free from viruses or 
defects, correct or reliable. MWH is not liable for any loss or damage that 
occurs as a result of this communication entering your computer network.

The views expressed in this message are not necessarily those of MWH. This 
communication cannot form a binding agreement unless that is the express intent 
of the parties and they are authorized to make such an agreement. MWH reserves 
all intellectual property rights contained in this transmission. MWH reserves 
the right to monitor any electronic communication sent or received by its 
employees. This communication may come from a variety of legal entities within 
or associated with the MWH group.

For a full list of details for these entities please see our website at 
www.mwhglobal.com. Where business communications relate to the MWH UK Limited 
entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, 
HP13 5AJ Tel: 01494 526240 and the company is registered in England as 
registration number 01188070. Where business communications relate to the MWH 
Constructors Limited entity, the registered office is as above and the company 
is registered in England as registration number 04635724. Where business 
communications relate to the MWH Soft Limited entity, the registered office is 
as above and the company is registered in England as registration number 
6975921.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Light.exe failing with error 1719

[Kiran Kumar Kolli]

Peter, thanks for the quick information. Also when you say "do validation 
somewhere else", can light.exe do it again or is there some other tool which 
can do it. 

-Original Message-
From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] 
Sent: 22 September 2009 18:52
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Light.exe failing with error 1719

The event log entry is added when light calls the windows installer service to 
perform ice validation. I imagine that, just as you can't run the execute 
sequence of several installers at once, you can't run several validations at 
the same time either.

I searched and found this thread that seems to support this. 
http://sourceforge.net/mailarchive/message.php?msg_id=A00CB80DE3F3D1429D
317D978E4B8FE14063747B48%40NA-EXMSG-C125.redmond.corp.microsoft.com

Adding -sval to your light command lines will prevent the error, but it's 
advisable to do validation somewhere else if you do.

-Original Message-
From: Kiran Kumar Kolli [mailto:kiran.ko...@microsoft.com]
Sent: 22 September 2009 13:59
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Light.exe failing with error 1719

In our builds we are seeing occasional failures such as follows
2>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\1>e:\v7sp2
\private\source\common\sku\oslomergemodules\partner\loc\en\light.exe :
error LGHT0217 : An unexpected external UI message was received: The Windows 
Installer Service could not be accessed. This can occur if the Windows 
Installer is not correctly installed. Contact your support personnel for 
assistance.

And event log at that time had the following error too
Product:  -- Error 1719. The Windows Installer Service could not be accessed. 
This can occur if the Windows Installer is not correctly installed. Contact 
your support personnel for assistance.

In our build environment there can be multiple light.exe running in parallel. 
When we build each one individually we are not seeing any issues.

Also while light.exe is executing its adding few event-log entries like 
"Windows Installer installed the product. Product Name: . Product
Version: . Product Language: . Installation success or error status: 0."

Can someone help us understand what's happening here and how to fix this issue.

Build machine: Windows Server 2008 SP1.

Thanks In advance,
Kiran Kumar


--
Come build with us! The BlackBerry® Developer Conference in SF, CA is the 
only developer event you need to attend this year. Jumpstart your developing 
skills, take BlackBerry mobile applications to market and stay ahead of the 
curve. Join us from November 9-12, 2009. Register now! 
http://p.sf.net/sfu/devconf ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA is the 
only developer event you need to attend this year. Jumpstart your developing 
skills, take BlackBerry mobile applications to market and stay ahead of the 
curve. Join us from November 9-12, 2009. Register now! 
http://p.sf.net/sfu/devconf ___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Ping Server from dialog

[Simon Topley]

Hi Guys,

long time no see. We recently bought a company and I've been tasked with
creating an installer for their products. oh joy.

One thing they wish to do is use the installer to do all the work a
config tool could. So during installation we want to collect servers and
port numbers and test the connection to them all. I've managed to
collect all the info i need and added it to the registry etc but I'm
struggling with testing the connection to these servers. I'm happy to
just us ping, but the only way i can see to do it is to embed ping.exe
in the installer and call it with customactions. I've not really tried
this yet so I'm not sure if it will even work but it still seems a bit
of a rubbish way to do it. I'd like to avoid writing any custom code if
i could as I'm in a hurry to bang this out and move on.

Any ideas?
Disclaimer: This electronic communication and its attachments may contain 
confidential, proprietary and/or legally privileged information which are for 
the sole use of the intended recipient. If you are not the intended recipient, 
any use, distribution, or reproduction of this communication is strictly 
prohibited and may be unlawful; please contact the sender and delete this 
communication. MWH does not warrant or make any representation regarding this 
transmission whatsoever nor does it warrant that it is free from viruses or 
defects, correct or reliable. MWH is not liable for any loss or damage that 
occurs as a result of this communication entering your computer network.

The views expressed in this message are not necessarily those of MWH. This 
communication cannot form a binding agreement unless that is the express intent 
of the parties and they are authorized to make such an agreement. MWH reserves 
all intellectual property rights contained in this transmission. MWH reserves 
the right to monitor any electronic communication sent or received by its 
employees. This communication may come from a variety of legal entities within 
or associated with the MWH group.

For a full list of details for these entities please see our website at 
www.mwhglobal.com. Where business communications relate to the MWH UK Limited 
entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, 
HP13 5AJ Tel: 01494 526240 and the company is registered in England as 
registration number 01188070. Where business communications relate to the MWH 
Constructors Limited entity, the registered office is as above and the company 
is registered in England as registration number 04635724. Where business 
communications relate to the MWH Soft Limited entity, the registered office is 
as above and the company is registered in England as registration number 
6975921.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Light.exe failing with error 1719

[Peter Shirtcliffe]

The event log entry is added when light calls the windows installer
service to perform ice validation. I imagine that, just as you can't run
the execute sequence of several installers at once, you can't run
several validations at the same time either.

I searched and found this thread that seems to support this. 
http://sourceforge.net/mailarchive/message.php?msg_id=A00CB80DE3F3D1429D
317D978E4B8FE14063747B48%40NA-EXMSG-C125.redmond.corp.microsoft.com

Adding -sval to your light command lines will prevent the error, but
it's advisable to do validation somewhere else if you do.

-Original Message-
From: Kiran Kumar Kolli [mailto:kiran.ko...@microsoft.com] 
Sent: 22 September 2009 13:59
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Light.exe failing with error 1719

In our builds we are seeing occasional failures such as follows
2>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\1>e:\v7sp2
\private\source\common\sku\oslomergemodules\partner\loc\en\light.exe :
error LGHT0217 : An unexpected external UI message was received: The
Windows Installer Service could not be accessed. This can occur if the
Windows Installer is not correctly installed. Contact your support
personnel for assistance.

And event log at that time had the following error too
Product:  -- Error 1719. The Windows Installer Service could not be
accessed. This can occur if the Windows Installer is not correctly
installed. Contact your support personnel for assistance.

In our build environment there can be multiple light.exe running in
parallel. When we build each one individually we are not seeing any
issues.

Also while light.exe is executing its adding few event-log entries like
"Windows Installer installed the product. Product Name: . Product
Version: . Product Language: . Installation success or error status: 0."

Can someone help us understand what's happening here and how to fix this
issue.

Build machine: Windows Server 2008 SP1.

Thanks In advance,
Kiran Kumar


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

SDL PLC confidential, all rights reserved.
If you are not the intended recipient of this mail SDL requests and requires 
that you delete it without acting upon or copying any of its contents, and we 
further request that you advise us.
SDL PLC is a public limited company registered in England and Wales.  
Registered number: 02675207.  
Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, 
UK.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Ping Server from dialog

[Simon Topley]

Hi Guys,

long time no see. We recently bought a company and I've been tasked with
creating an installer for their products. oh joy.

One thing they wish to do is use the installer to do all the work a
config tool could. So during installation we want to collect servers and
port numbers and test the connection to them all. I've managed to
collect all the info i need and added it to the registry etc but I'm
struggling with testing the connection to these servers. I'm happy to
just us ping, but the only way i can see to do it is to embed ping.exe
in the installer and call it with customactions. I've not really tried
this yet so I'm not sure if it will even work but it still seems a bit
of a rubbish way to do it. I'd like to avoid writing any custom code if
i could as I'm in a hurry to bang this out and move on.

Any ideas?
Disclaimer: This electronic communication and its attachments may contain 
confidential, proprietary and/or legally privileged information which are for 
the sole use of the intended recipient. If you are not the intended recipient, 
any use, distribution, or reproduction of this communication is strictly 
prohibited and may be unlawful; please contact the sender and delete this 
communication. MWH does not warrant or make any representation regarding this 
transmission whatsoever nor does it warrant that it is free from viruses or 
defects, correct or reliable. MWH is not liable for any loss or damage that 
occurs as a result of this communication entering your computer network.

The views expressed in this message are not necessarily those of MWH. This 
communication cannot form a binding agreement unless that is the express intent 
of the parties and they are authorized to make such an agreement. MWH reserves 
all intellectual property rights contained in this transmission. MWH reserves 
the right to monitor any electronic communication sent or received by its 
employees. This communication may come from a variety of legal entities within 
or associated with the MWH group.

For a full list of details for these entities please see our website at 
www.mwhglobal.com. Where business communications relate to the MWH UK Limited 
entity, the registered office is Terriers House, 201 Amersham Rd, High Wycombe, 
HP13 5AJ Tel: 01494 526240 and the company is registered in England as 
registration number 01188070. Where business communications relate to the MWH 
Constructors Limited entity, the registered office is as above and the company 
is registered in England as registration number 04635724. Where business 
communications relate to the MWH Soft Limited entity, the registered office is 
as above and the company is registered in England as registration number 
6975921.


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

[WiX-users] Light.exe failing with error 1719

[Kiran Kumar Kolli]

In our builds we are seeing occasional failures such as follows
2>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\1>e:\v7sp2\private\source\common\sku\oslomergemodules\partner\loc\en\light.exe
 : error LGHT0217 : An unexpected external UI message was received: The Windows 
Installer Service could not be accessed. This can occur if the Windows 
Installer is not correctly installed. Contact your support personnel for 
assistance.

And event log at that time had the following error too
Product:  -- Error 1719. The Windows Installer Service could not be accessed. 
This can occur if the Windows Installer is not correctly installed. Contact 
your support personnel for assistance.

In our build environment there can be multiple light.exe running in parallel. 
When we build each one individually we are not seeing any issues.

Also while light.exe is executing its adding few event-log entries like 
"Windows Installer installed the product. Product Name: . Product Version: . 
Product Language: . Installation success or error status: 0."

Can someone help us understand what's happening here and how to fix this issue.

Build machine: Windows Server 2008 SP1.

Thanks In advance,
Kiran Kumar

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] ARP support info in Vista: not shown

[Pally Sandher]

Vista doesn't support it? You're not viewing the "Programs & Features"
Control panel in the right view mode to see it (default view mode may
not show it)? It's a bug in Vista which is fixed in Windows 7?

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
 
 

-Original Message-
From: little.forest [mailto:little.for...@ymail.com] 
Sent: 22 September 2009 00:36
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] ARP support info in Vista: not shown

We use Wix 3.0.


We have this code to show support url in ARP:



In XP and Windows 7, it works - we can see the url when checking ARP.
But in Vista, the support info url field is empty. In the log of the
Vista installation, the ARPHELPLINK is setup:
Property(C): ARPHELPLINK = http://www.thecompany.com


What's the problem here?

Thanks.

--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why Wix3 is much slower than Wix2?

[Kevin Gu]

Actually, what I want to know is whether Wix team has a perf testing on the 
speed between wix3 and wix2?
And what's the result? 


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


-Original Message-
From: Kevin Gu [mailto:k...@microsoft.com] 
Sent: Tuesday, September 22, 2009 5:38 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Why Wix3 is much slower than Wix2?

Pally,

 Thanks for your reply.

 After further testing, it seems that with -sval switch wix3 can be as 
quick as wix2.

 For example, building a set of wxs without -sval takes 3:00. While with 
-sval, only 1:30.


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Tuesday, September 22, 2009 5:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Why Wix3 is much slower than Wix2?

The only steps which I've seen that take a significant length of time
are the indexing and subsequent cabbing of files.
Are you 100% sure your WiX v2.0 project had the exact same number of
files and the same Media attributes as your WiX v3.0 project? Changing
the compression level down to low or none & not embedding the cab file
in the MSI will cut down significantly on the time light.exe takes as
will removing files from the File table.

Also make sure you're using v3.0.5419.0.

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
 

-Original Message-
From: Kevin Gu [mailto:k...@microsoft.com] 
Sent: 22 September 2009 07:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Why Wix3 is much slower than Wix2?

Hi All,

It seems that the light.exe in Wix3 is much slower than Wix2. Does
anyone know the reason? Or is there any way to speed up the linking
processing in Wix3?

I've tried to use -sval to turn off the ICE validation. But it seems
that the ICE validation doesn't take much time. So what is the most time
consuming step in Wix3?


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why Wix3 is much slower than Wix2?

[Kevin Gu]

Pally,

 Thanks for your reply.

 After further testing, it seems that with -sval switch wix3 can be as 
quick as wix2.

 For example, building a set of wxs without -sval takes 3:00. While with 
-sval, only 1:30.


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


-Original Message-
From: Pally Sandher [mailto:pally.sand...@iesve.com] 
Sent: Tuesday, September 22, 2009 5:22 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Why Wix3 is much slower than Wix2?

The only steps which I've seen that take a significant length of time
are the indexing and subsequent cabbing of files.
Are you 100% sure your WiX v2.0 project had the exact same number of
files and the same Media attributes as your WiX v3.0 project? Changing
the compression level down to low or none & not embedding the cab file
in the MSI will cut down significantly on the time light.exe takes as
will removing files from the File table.

Also make sure you're using v3.0.5419.0.

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
 

-Original Message-
From: Kevin Gu [mailto:k...@microsoft.com] 
Sent: 22 September 2009 07:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Why Wix3 is much slower than Wix2?

Hi All,

It seems that the light.exe in Wix3 is much slower than Wix2. Does
anyone know the reason? Or is there any way to speed up the linking
processing in Wix3?

I've tried to use -sval to turn off the ICE validation. But it seems
that the ICE validation doesn't take much time. So what is the most time
consuming step in Wix3?


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users

Re: [WiX-users] Why Wix3 is much slower than Wix2?

[Pally Sandher]

The only steps which I've seen that take a significant length of time
are the indexing and subsequent cabbing of files.
Are you 100% sure your WiX v2.0 project had the exact same number of
files and the same Media attributes as your WiX v3.0 project? Changing
the compression level down to low or none & not embedding the cab file
in the MSI will cut down significantly on the time light.exe takes as
will removing files from the File table.

Also make sure you're using v3.0.5419.0.

Palbinder Sandher 
Software Deployment & IT Administrator
T: +44 (0) 141 945 8500 
F: +44 (0) 141 945 8501 

http://www.iesve.com 
**Design, Simulate + Innovate with the **
Integrated Environmental Solutions Limited. Registered in Scotland No.
SC151456 
Registered Office - Helix Building, West Of Scotland Science Park,
Glasgow G20 0SP
Email Disclaimer
 

-Original Message-
From: Kevin Gu [mailto:k...@microsoft.com] 
Sent: 22 September 2009 07:09
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] Why Wix3 is much slower than Wix2?

Hi All,

It seems that the light.exe in Wix3 is much slower than Wix2. Does
anyone know the reason? Or is there any way to speed up the linking
processing in Wix3?

I've tried to use -sval to turn off the ICE validation. But it seems
that the ICE validation doesn't take much time. So what is the most time
consuming step in Wix3?


Thanks,
Kevin GU | SDE | CSAT China | 8621-61518167


--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and
stay ahead of the curve. Join us from November 9-12, 2009. Register
now! http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users



--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay 
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users