Re: [WiX-users] Ping Server from dialog
Thanks for the offer Blair but I'll probably just write a configuration tool instead. This is like striping an engine with a set of cutlery. It is very annoying that the asynchronous return types do have meaningful return values, surely this is a pretty common thing people want to do. -Original Message- From: Blair [mailto:os...@live.com] Sent: 23 September 2009 00:40 To: Simon Topley Subject: RE: [WiX-users] Ping Server from dialog From the POV of Windows Installer, an action succeeds or fails. It is up to the action if it wants to set properties instead. From the POV of CAQuietExec, it exists for the sole purpose of preventing the flashing command-prompt-style windows you get calling command-line applications directly from Windows Installer. It intends to extend the same calling model. You need a modified version of CAQuietExec that sets a property with the result code of the external application instead of using the result code to return action success or failure. You could write it yourself, or someone else could write one for you. I'll send you one for US$25.00 licensed with the CPL (same license as the WiX toolset). -Original Message- From: Simon Topley [mailto:simon.top...@wallingfordsoftware.com] Sent: Tuesday, September 22, 2009 9:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Ping Server from dialog 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: Control Id=Install Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Text=amp;Next gt; Publish Event=NewDialog Value=[WixUI_RMSPortInput_Next]1/Publish Publish Event=DoAction Value=pingISAServer1/Publish /Control 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. Property Id=QtExecCmdLine Value=quot;ping.exequot; /n 1 [ISASERVER]/ CustomAction Id=pingServer BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check/ Binary Id=wixca src=wixca.dll/ InstallExecuteSequence Custom Action='pingServer' After=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence 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
Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app
I think you're all missing the point here. The issue is not where he installs his files to, his problem is writing to the registry. Nate putting all your x86 x64 DLL's in the same directory is fine. You can do this in both a x86 MSI and a x64 MSI. They can both install to the same path under Program Files (x86) if you so wish. You do not have to separate your x64 x86 DLL's regardless of what people have been saying unless your application requires you to. What you cannot do is access the 64-bit areas of the registry from an x86 MSI (your x86 MSI will always be redirected to the Wow6432Node area). You can however access both the 32-bit and 64-bit areas of the registry from an x64 MSI but you can only install it on an x64 O/S. Hence if you want x86 O/S users to be able to install your application, you need to make an x86 MSI for them while the x64 O/S users use the x64 MSI. If you want to make changes to the 64-bit areas of the registry, author an x64 MSI. If you don't need to, stick with using a one-size fits all x86 MSI. 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 Virtual Environment** 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: Blair [mailto:os...@live.com] Sent: 23 September 2009 02:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app 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 os...@live.com 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
Re: [WiX-users] How to schedule RemoveFile
If the file is generated by a custom action during install, you should have custom actions to remove it during uninstall rollback too. See http://msdn.microsoft.com/en-us/library/aa371101(VS.85).aspx for suppressing the reboot prompt. 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 Virtual Environment** 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: Blair [mailto:os...@live.com] Sent: 23 September 2009 00:49 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] How to schedule RemoveFile 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Vista Standard User and perMachine install
I use the Privileged property in a LaunchCondition to do exactly that Warne it works without fail. Tested it on XP, XP64, Vista Vista64 Virtual machines with user accounts which are only members of the User group it always works. If you're checking during InstallExecute the MSI needs to be elevated at that point otherwise it can't make any per-machine changes so it'll always return true or as Sascha says the machine itself may be the issue. This is one of the things VM's are so good at. See http://www.joyofsetup.com/2007/09/24/test-your-setups-virtually/ 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 Virtual Environment** 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: Sascha Beaumont [mailto:sascha.beaum...@gmail.com] Sent: 23 September 2009 01:51 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Vista Standard User and perMachine install 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 warne...@hotmail.com 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, -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Default website gets removed on Uninstall
Hi All,
I am working with latest version of Wix installer. Refer the below code:
Component Id=DefaultWebSite Guid={8444A473-DF8D-4b27-84DA-7D3EE087A510}
KeyPath=yes Permanent=yes
Condition![CDATA[IISVERSIONFORADMIN=#7]]/Condition
!--DefaultWebSite--
iis:WebSite Id='DefaultWebSite' Description='Default Web Site'
Directory='ADMINAPPLICATION'
ConfigureIfExists='no'
iis:WebAddress Id='AllUnassigned' Port='80' /
/iis:WebSite
/Component
Component Id=IISApplication Guid=FFA12D9C-5AEC-45f8-AA7D-5C4CEC7FA466
KeyPath=yes
iis:WebVirtualDir Id=VirtualDir Alias=[ADMINVIRTUALDIRECTORY]
Directory=ADMINAPPLICATION WebSite=DefaultWebSite
iis:WebApplication Id=AdminApplication21
Name=[ADMINVIRTUALDIRECTORY]
!-- Required to run the application under the .net 2.0 framework
--
iis:WebApplicationExtension Extension=ad CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=adprototype
CheckPath=yes Script=yes
Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=asax CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ascx CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ashx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=asmx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=aspx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=axd CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=browser CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=cd CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=compiled CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=config CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=csproj CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=dd CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=exclude CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=java CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=jsl CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=ldb CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=ldd CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=lddprototype
CheckPath=yesScript=yes
Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ldf CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=licx CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=master CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=mdb CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=mdf CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=msgx CheckPath=no
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension
[WiX-users] Default Website gets removed in uninstall in VISTA
Hi,
I am working with latest version of Wix installer. Refer the below code:
Component Id=DefaultWebSite Guid={8444A473-DF8D-4b27-84DA-7D3EE087A510}
KeyPath=yes Permanent=yes
Condition![CDATA[IISVERSIONFORADMIN=#7]]/Condition
!--DefaultWebSite--
iis:WebSite Id='DefaultWebSite' Description='Default Web Site'
Directory='ADMINAPPLICATION'
ConfigureIfExists='no'
iis:WebAddress Id='AllUnassigned' Port='80' /
/iis:WebSite
/Component
Component Id=IISApplication Guid=FFA12D9C-5AEC-45f8-AA7D-5C4CEC7FA466
KeyPath=yes
iis:WebVirtualDir Id=VirtualDir Alias=[ADMINVIRTUALDIRECTORY]
Directory=ADMINAPPLICATION WebSite=DefaultWebSite
iis:WebApplication Id=AdminApplication21
Name=[ADMINVIRTUALDIRECTORY]
!-- Required to run the application under the .net 2.0 framework
--
iis:WebApplicationExtension Extension=ad CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=adprototype
CheckPath=yes Script=yes
Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=asax CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ascx CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ashx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=asmx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=aspx CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=axd CheckPath=no
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=browser CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=cd CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=compiled CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=config CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=csproj CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=dd CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=exclude CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=java CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=jsl CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=ldb CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=ldd CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=lddprototype
CheckPath=yesScript=yes
Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST /
iis:WebApplicationExtension Extension=ldf CheckPath=yes
Script=yes Executable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=licx CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=master CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=mdb CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=mdf CheckPath=yes
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension Extension=msgx CheckPath=no
Script=yesExecutable=[FRAMEWORKROOT]v2.0.50727\aspnet_isapi.dll
Verbs=GET,HEAD,POST/
iis:WebApplicationExtension
[WiX-users] Changing Media Id to be greater than 1 gets error LGHT0094
Hi, Using WiX 3.0, I get the following error when changing Media Id to be greater than 1: Media Id='5' Cabinet='kkk.cab' EmbedCab='yes' DiskPrompt='CD-ROM #1' / error LGHT0094 : Unresolved reference to symbol 'Media:1' in section 'Fragment:'. According to the help pages, Disk identifier for Media table must be equal to or greater than 1, but it only works when the value is 1. Are we allowed to change this Id? Thanks, Shibo -- View this message in context: http://n2.nabble.com/Changing-Media-Id-to-be-greater-than-1-gets-error-LGHT0094-tp3698631p3698631.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Changing Media Id to be greater than 1 gets error LGHT0094
If you have Diskid=1 on your Components you're going to need a Media Element with Id=1 otherwise where will those files be stored when light tries to compile your MSI? You don't need anything other than Id=1 unless you have a need for multiple cabs in which case you need multiple Media Elements with the Id's (and thus the DiskId's in your components) specified accordingly. 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 Virtual Environment** 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: shibo [mailto:szheng...@googlemail.com] Sent: 23 September 2009 11:03 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Changing Media Id to be greater than 1 gets error LGHT0094 Hi, Using WiX 3.0, I get the following error when changing Media Id to be greater than 1: Media Id='5' Cabinet='kkk.cab' EmbedCab='yes' DiskPrompt='CD-ROM #1' / error LGHT0094 : Unresolved reference to symbol 'Media:1' in section 'Fragment:'. According to the help pages, Disk identifier for Media table must be equal to or greater than 1, but it only works when the value is 1. Are we allowed to change this Id? Thanks, Shibo -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 patch gives me Error reading file dialog
Bob, I have got a response from MSI newsgroup. It looks like that problem is caused by file sequence numbers. In my base and upgrade images, different files shares the same sequence numbers. The error reading file is a new file, but has the same sequence number as an old file in the base image. I use PatchWizard as it is easy to create wxs file, diff is much better now due to unique file ids in WiX 3.0, but it looks like sequence is still a problem. I have tried to use WiX only patching, but this does not support deleting files. I reckon that I have to work out deleted files and list them in the patch wxs file. Maybe this is the only option that works? Thanks, Shibo -- View this message in context: http://n2.nabble.com/Installing-patch-gives-me-Error-reading-file-dialog-tp3662429p3698786.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Will give that a try. Thx! -Original Message- From: Chad Petersen [mailto:chad.peter...@harlandfs.com] Sent: Tuesday, September 22, 2009 5:31 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] remove website on uninstall 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! Directory Id=TARGETDIR Name=SourceDir Component Id=NewWebsiteConfigASP Guid=MYGUID iis:WebSite Id=IISWebsite Description=[WEBSITEDESCRIPTION] Directory=TARGETDIR AutoStart=yes ConfigureIfExists=yes StartOnInstall=yes iis:WebAddress Id=IISWebAddress Port=[WEBSITEPORT] IP=[WEBSITEIP] Header=[WEBSITEHOSTHEADER] / iis:WebDirProperties Id=IISWebDirProperties Execute=yes Read=yes DefaultDocuments=default.aspx,index.aspx,index.htm,index.html,default.h tm,default.html / iis:WebDir Id=IISAppDataWebDir Path=App_Data iis:WebDirProperties Id=IISAppDataWebDirProperties Write=yes Read=yes DefaultDocuments=default.aspx,index.aspx,index.htm,index.html,default.h tm,default.html / /iis:WebDir iis:WebApplication Id=WebApplication Name=[WEBAPPLICATIONNAME] WebAppPool=WebAppPool /iis:WebApplication /iis:WebSite iis:WebAppPool Id=WebAppPool Name=[WEBAPPLICATIONPOOLNAME] Identity=networkService / ConditionTARGETMODE = NewWebsite AND SCRIPTLANGUAGE = ASP/Condition /Component Component Id=ExistingWebsiteConfigASP Guid=MYGUID iis:WebSite Id=IISWebsiteExisting Description=[WEBSITEDESCRIPTION] ConfigureIfExists=no Directory=TARGETDIR iis:WebAddress Id=IISWebAddressExisting Port=[WEBSITEPORT] IP=[WEBSITEIP] Header=[WEBSITEHOSTHEADER] / iis:WebVirtualDir Id=WebVirtualDirectory Alias=[VIRTUALDIRECTORYNAME] Directory=TARGETDIR iis:WebDirProperties Id=IISWebVirtualDirPropertiesExisting Execute=yes Read=yes DefaultDocuments=default.aspx,index.aspx,index.htm,index.html,default.h tm,default.html / iis:WebApplication Id=WebApplicationExisting Name=[WEBAPPLICATIONNAME] WebAppPool=WebAppPoolExisting /iis:WebApplication /iis:WebVirtualDir /iis:WebSite ConditionTARGETMODE = ExistingWebsite AND SCRIPTLANGUAGE = ASP/Condition iis:WebAppPool Id=WebAppPoolExisting Name=[WEBAPPLICATIONPOOLNAME] Identity=networkService / /Component -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 BlackBerryreg; 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
Re: [WiX-users] Major Upgrade install - why are files missing?
The merge module is largely generated automatically - basically the tool that makes the WiX source for the merge module scans an installed JRE and generates one component per folder, there is nothing more to it. There was no concern about supporting any form of minor upgrade. When the WiX code is generated everything gets a new GUID. We only generate new WiX code for the merge module when we migrate to a new version of the JRE. But in the case that is failing it is the very same merge module used by both installers anyway - As I understand it, it is impossible for the module to break the rules on itself. I will try to reproduce the issue and generate logs. Thanks, Scott On Mon, Sep 21, 2009 at 2:02 PM, Blair os...@live.com wrote: I would be interested in seeing the design of the merge module as well as install logs. With my previous employer we designed and had written much of such a tool (integrated into our evolving build system). I have plans to write such a tool, if there is interest I could push it up in the list. -Original Message- From: Scott Palmer [mailto:swpal...@gmail.com] Sent: Monday, September 21, 2009 6:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Major Upgrade install - why are files missing? Getting back to the original problem. The files that were missing after my major upgrade install were in a merge module that I created that was the same in both products and therefore followed the component rules (since there were no changes to the install path or content of any components). Would the incorrect scheduling of the RemoveExistingProducts task affect more than just the VC 2005 redistributables? It's going to be a tremendous effort to educate all of the people on the team about the component rules so they can properly update the WiX code for the installer when they add new files to the project. There doesn't appear to be any good way to verify that the rules are being followed either. Is there a tool that can compare my .msi files (V1.msi vs. V2.msi) and warn me about possible violations to the component rules? I would think that component guids could be compared between the two msi files and if the number of files in a component or the install path has changed detailed warnings could be shown. Thanks for your help, Scott -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language patching
I've hit upon a problem and thing it's to do with the defined ProductLanguage property of my MSI, but would appreciate some advice to see if I'm chasing the right path. I have a package that is entirely US English, but I have several transforms for other languages, French for example. This is all handled by the bootstrapper in the traditional way. One of the key elements of the package is that I have language specific features (including those for the different loc dlls that translate the UI of the application) that are conditionally installed depending on the ProductLanguage property, which is appropriately set by the transform - in the French case, transforming 1033 into 1036. When it comes to patching, the loc dlls are not updating despite the log of the patch creation knowing they have changed. The actual MSP execution log says that the versions are the same and that there's nothing to do - this is bogus. My thought is that since my admin extractions from which the patch were made have a ProductLanguage of 1033, that the patch, when applied to an installation where the ProductLanguage is 1036, is deliberately skipping dlls that have their language defined as anything other than 1033. There is some evidence to support this since the main exe/dlls are patching, it is just the loc dlls that have the French locale defined and that are being skipped. Curiously, one of the loc dlls has changed from French to English by mistake and this DOES patch, but not in a delta patch, only when specified to include as a whole file. Has anyone have any experience of this? I've considered setting the ProductLanguage of my MSI to 0 (zero) and to create another transform for the English case to change it to 1033 - or perhaps to define all langages in the ProductLanguage property and use something else in my component conditions. Many thanks for any input. Gareth -- View this message in context: http://n2.nabble.com/Multi-language-patching-tp3700410p3700410.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
This (http://blogs.msdn.com/heaths/archive/2008/01/15/different-packages-are-requ ired-for-different-processor-architectures.aspx) is Heath's blog post. After reading it last year, I tested the case of what happens to a 64-bit component containing registry values in a 32-bit package, and they access the 64-bit registry. Even RegSearch works this way (marked 64-bit, it accesses the 64-bit registry). It is the file system that is redirected, even for 64-bit components. Much can be done on a machine that could lead to problems in the future (witness so much pain moving from XP to Vista WRT the tightened security you get by default). That is part of the reason for the Logo programs: to help ensure best practices are followed. It is best practice to offer two packages: one for 32-bit architectures and one for 64-bit architectures, and to not allow the 32-bit package to be installed on a 64-bit architecture if you must install 64-bit anything on those 64-bit architectures. If you are willing to risk the pain of future issues (and the need to test new OSs before they are released) you can try taking advantage of the fact that 32-bit MSIs are allowed access to 64-bit registry AS LONG AS YOU CONDITION THE COMPONENTS. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Wednesday, September 23, 2009 2:34 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app I think you're all missing the point here. The issue is not where he installs his files to, his problem is writing to the registry. Nate putting all your x86 x64 DLL's in the same directory is fine. You can do this in both a x86 MSI and a x64 MSI. They can both install to the same path under Program Files (x86) if you so wish. You do not have to separate your x64 x86 DLL's regardless of what people have been saying unless your application requires you to. What you cannot do is access the 64-bit areas of the registry from an x86 MSI (your x86 MSI will always be redirected to the Wow6432Node area). You can however access both the 32-bit and 64-bit areas of the registry from an x64 MSI but you can only install it on an x64 O/S. Hence if you want x86 O/S users to be able to install your application, you need to make an x86 MSI for them while the x64 O/S users use the x64 MSI. If you want to make changes to the 64-bit areas of the registry, author an x64 MSI. If you don't need to, stick with using a one-size fits all x86 MSI. 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 Virtual Environment** 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: Blair [mailto:os...@live.com] Sent: 23 September 2009 02:43 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Installing 64-bit shell extension with a 32-bit app 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 os...@live.com 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
[WiX-users] Multi language admin extractions
There are a few threads on how to go about creating multi language packages that are essentially all about creating transforms and making a bootstrapper that applies the right one. I have stumbled across a problem when using this method in admin extractions. When you run my installer with the /a switch for an admin extraction, you can also choose to apply the appropriate transform for your chosen language. I actually have an option in my bootstrapper that offers admin extractions, so applying a localisation transform to an admin extraction is really easy for me. However, the resulting MSI is not in the chosen language, and when distributed it is in the default language and not the chosen one. This is a big problem when your localisation transform also translates some directory names because they appear in the UI of the application you're installing. So, if you apply a localisation transform when you admin extract, you also have to apply the same transform when you distribute or your package won't install. Is there any way to tell your package when it has a transform applied during the admin extraction, to re-use that transform when distributed? Thanks for any input, Gareth -- View this message in context: http://n2.nabble.com/Multi-language-admin-extractions-tp3700529p3700529.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
The Request is the expected-intended state (based on conditions and parent features). Null means it shouldn't be touched. I'm interested in knowing why it says Installed: Absent on the upgrade. The SchedXmlFile action has access to just two of the three values (Installed and Action?) and has to determine what it should do based on that. There is supposed to be a formula between all three that works like this: Installed: Absent; Action: Local = install Installed: Local; Action: Absent = remove Installed: Local; Action: Local = upgrade or repair (install again) Installed: Local; Action: Null = leave alone (it was already installed, and wasn't changed in this upgrade) Installed: Absent; Action: Absent = don't install I would assume that the following would also mean leave alone: Installed: Absent; Action: Null See the MsiGetComponentState() api for the view available to SchedXmlFile. I wonder if adding LOGVERBOSE=1 to your commandline and looking in the log around SchedXmlFile will give more information (http://www.joyofsetup.com/2008/07/15/verbose-logging-from-wcautil) about why it is executing for that component. -Original Message- From: si [mailto:sshnug...@gmail.com] Sent: Wednesday, September 23, 2009 1:01 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] XmlFile being executed when feature condition should fail What does the log say about the WebConfigSqlDbSqlAuthComponent component while running CostFinalize? Also, is your upgrade Major or Minor/Small? Hi Blair, All our upgrades are Major. As for the component, the only reference in the log is: New Install: Action ended 16:58:44: CostFinalize. Return value 1. MSI (s) (FC:08) [16:58:44:731]: Doing action: InstallValidate Action 16:58:44: InstallValidate. Validating install Action start 16:58:44: InstallValidate. [snip] MSI (s) (FC:08) [16:58:44:734]: Component: WebConfigSqlDbWinAuthComponent; Installed: Absent; Request: Local; Action: Local MSI (s) (FC:08) [16:58:44:734]: Component: WebConfigSqlDbSqlAuthComponent; Installed: Absent; Request: Local; Action: Null Upgrade: Action ended 17:12:57: CostFinalize. Return value 1. MSI (s) (D8:20) [17:12:57:359]: Doing action: InstallValidate Action 17:12:57: InstallValidate. Validating install Action start 17:12:57: InstallValidate. [snip] MSI (s) (D8:20) [17:12:57:363]: Component: WebConfigSqlDbWinAuthComponent; Installed: Absent; Request: Null; Action: Null MSI (s) (D8:20) [17:12:57:363]: Component: WebConfigSqlDbSqlAuthComponent; Installed: Absent; Request: Null; Action: Null So the Action value in the upgrade looks correct, but I'm wondering why the Request value is null, is this a clue? Thanks, Simon -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 execute .Net Framework Condition at Last
It seems to me that you have a mish-mash of terminology here. If your bootstrapper is checking for .Net Framework as a prerequisit of your package, then this will always happen before you get to your launch conditions as the bootstrapper will handle this before running your MSI and getting to the LaunchConditions action. -- View this message in context: http://n2.nabble.com/How-to-execute-Net-Framework-Condition-at-Last-tp3693467p3700648.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Quote-in-quotes problem in ExeCommand, a WiX bug, or am I missing something?
You can use XML escape characters. In this case, replace your internal quotes with quot; and it'll all come out in the wash without the compiler thinking that the parameter definition has closed. Other common chars are... amp; for lt; for gt; for apos; for ' -- View this message in context: http://n2.nabble.com/Quote-in-quotes-problem-in-ExeCommand-a-WiX-bug-or-am-I-missing-something-tp3669429p3700693.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 patch gives me Error reading file dialog
Leave the file alone (so it doesn't get physically added to the patch) and set the component that file belongs to as Transient with a condition of 0. That will cause the file to be removed from the disk when the patch is applied. I hope you are not trying to patch more than one released MSI. Only release patches and the original MSI (not updated MSIs) until your next baseline reset. -Original Message- From: shibo [mailto:szheng...@googlemail.com] Sent: Wednesday, September 23, 2009 7:24 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing patch gives me Error reading file dialog Hi, Further reading Peter's blog: http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patc hes.aspx WiX only patch is not feasible when deleting file / renaming file is involved. I put one file under one component so that GUIDs are generated automatically and consistently. Peter's blog says that the the entire component must be removed, which leads to remove the entire feature. Are there any successful patching stories out there invloving file deletions? I have reached dead ends using two patching methods. Any help is greatly appreciated. Kind regards, Shibo -- View this message in context: http://n2.nabble.com/Installing-patch-gives-me-Error-reading-file-dialog-tp3 662429p3699956.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language admin extractions
Use a bootstrapper. -Original Message- From: Gareth [mailto:gmor...@serif.com] Sent: Wednesday, September 23, 2009 8:52 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi language admin extractions There are a few threads on how to go about creating multi language packages that are essentially all about creating transforms and making a bootstrapper that applies the right one. I have stumbled across a problem when using this method in admin extractions. When you run my installer with the /a switch for an admin extraction, you can also choose to apply the appropriate transform for your chosen language. I actually have an option in my bootstrapper that offers admin extractions, so applying a localisation transform to an admin extraction is really easy for me. However, the resulting MSI is not in the chosen language, and when distributed it is in the default language and not the chosen one. This is a big problem when your localisation transform also translates some directory names because they appear in the UI of the application you're installing. So, if you apply a localisation transform when you admin extract, you also have to apply the same transform when you distribute or your package won't install. Is there any way to tell your package when it has a transform applied during the admin extraction, to re-use that transform when distributed? Thanks for any input, Gareth -- View this message in context: http://n2.nabble.com/Multi-language-admin-extractions-tp3700529p3700529.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language patching
We avoided this headache by having our bootstrapper install two MSIs (one for core and one for loc) for each product. This way we could install as many LOCs as we wanted and we could write patches against any/all that needed to be upgraded without these issues. It does require bootstrapping the patches to help ensure that changes that affect both core and loc are properly applied to all, and it helps to use MSI 4.5 to avoid having to track the applications yourself to avoid having to remove a patch if the application fails at a later stage in your bootstrapper. -Original Message- From: Gareth [mailto:gmor...@serif.com] Sent: Wednesday, September 23, 2009 8:33 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Multi language patching I've hit upon a problem and thing it's to do with the defined ProductLanguage property of my MSI, but would appreciate some advice to see if I'm chasing the right path. I have a package that is entirely US English, but I have several transforms for other languages, French for example. This is all handled by the bootstrapper in the traditional way. One of the key elements of the package is that I have language specific features (including those for the different loc dlls that translate the UI of the application) that are conditionally installed depending on the ProductLanguage property, which is appropriately set by the transform - in the French case, transforming 1033 into 1036. When it comes to patching, the loc dlls are not updating despite the log of the patch creation knowing they have changed. The actual MSP execution log says that the versions are the same and that there's nothing to do - this is bogus. My thought is that since my admin extractions from which the patch were made have a ProductLanguage of 1033, that the patch, when applied to an installation where the ProductLanguage is 1036, is deliberately skipping dlls that have their language defined as anything other than 1033. There is some evidence to support this since the main exe/dlls are patching, it is just the loc dlls that have the French locale defined and that are being skipped. Curiously, one of the loc dlls has changed from French to English by mistake and this DOES patch, but not in a delta patch, only when specified to include as a whole file. Has anyone have any experience of this? I've considered setting the ProductLanguage of my MSI to 0 (zero) and to create another transform for the English case to change it to 1033 - or perhaps to define all langages in the ProductLanguage property and use something else in my component conditions. Many thanks for any input. Gareth -- View this message in context: http://n2.nabble.com/Multi-language-patching-tp3700410p3700410.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language admin extractions
I've never heard of a bootstrapper being part of an admin extraction before. Is this an approach you take? Doesn't it mean that in the standard case you'd be installing a bootstrapper in a really weird place for it to appear in the right place for the extraction's case. Also, if a network administrator were to distribute the extracion via GPO or via the RM CC3 Management Console (whatever's appropriate for their setup) the bootstrapper would be ignored anyway - both those network solutions would only grab the MSI. Cheers, G -- View this message in context: http://n2.nabble.com/Multi-language-admin-extractions-tp3700529p3700836.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Installation directory must be on a local hard drive. error
A client is getting this error when installing an updated version of our installer: Installation directory must be on a local hard drive. They're getting this message even though they're installing onto their C drive. Here's my setup - I'm using Wix 3.0.5419.0: !-- setup interface -- Property Id=WIXUI_INSTALLDIR Value=INSTALLDIR/ UIRef Id=WixUI_InstallDir / WixVariable Id='WixUIBannerBmp'Value='bannrbmp.bmp' / WixVariable Id='WixUIDialogBmp'Value='dlgbmp.bmp' / WixVariable Id='WixUILicenseRtf' Value='License.rtf' / !-- set Add/Remove Program Icon -- Property Id='ARPPRODUCTICON' Value='AppIcon1.exe'/ !-- run CPU check -- InstallExecuteSequence Custom Action='CheckCpuAction' Before='LaunchConditions'/ /InstallExecuteSequence InstallUISequence Custom Action='CheckCpuAction' Before='LaunchConditions'/ /InstallUISequence -- View this message in context: http://n2.nabble.com/Installation-directory-must-be-on-a-local-hard-drive-error-tp3700846p3700846.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 patch gives me Error reading file dialog
Forgot to mention: you will probably want to make the patch non-removable to avoid having to make two patches. -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, September 23, 2009 9:16 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Installing patch gives me Error reading file dialog Leave the file alone (so it doesn't get physically added to the patch) and set the component that file belongs to as Transient with a condition of 0. That will cause the file to be removed from the disk when the patch is applied. I hope you are not trying to patch more than one released MSI. Only release patches and the original MSI (not updated MSIs) until your next baseline reset. -Original Message- From: shibo [mailto:szheng...@googlemail.com] Sent: Wednesday, September 23, 2009 7:24 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Installing patch gives me Error reading file dialog Hi, Further reading Peter's blog: http://blogs.msdn.com/pmarcu/archive/2009/05/19/wix-removing-files-with-patc hes.aspx WiX only patch is not feasible when deleting file / renaming file is involved. I put one file under one component so that GUIDs are generated automatically and consistently. Peter's blog says that the the entire component must be removed, which leads to remove the entire feature. Are there any successful patching stories out there invloving file deletions? I have reached dead ends using two patching methods. Any help is greatly appreciated. Kind regards, Shibo -- View this message in context: http://n2.nabble.com/Installing-patch-gives-me-Error-reading-file-dialog-tp3 662429p3699956.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language patching
So, you've seen this behaviour before and agree that there's an MSI limitation relating to language specific files in a multi language package? I'm just really interested to know if the patch failures I've seen are because of the language specifications. Blair-2 wrote: We avoided this headache... -- View this message in context: http://n2.nabble.com/Multi-language-patching-tp3700410p3700931.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Upgrade Installs and Component Rules
Further to what Blair says, you can check this topic:
http://msdn.microsoft.com/en-gb/library/aa368267(VS.85).aspx
This has some rather helpful flow diagrams that explain the logic
under a few different scenarios.
2009/9/23 Blair os...@live.com:
For V2:
 1: Change ProductCode(s) (make this a major upgrade)
 2: Make certain that C1 and C2 share the same condition and directory. In
the future, if you ever need them to have different conditions/directories,
you will be forced to rename R1 (placing the renamed R1 in some new
not-yet-created component and retire/remove C1 from your authoring
entirely).
Component Id='C1' ...
 File Id='R1' Keypath='yes' .../
/Component
Component Id='C1-prime' ...
 !-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
 !-- if R2 is a registry key --RemoveRegistryKey Action='removeOnInstall'
.../
 !-- you are out of luck if it us just a registry value --
 ... Id='R3'/
/Component
Blair
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Wednesday, September 23, 2009 6:43 AM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] Upgrade Installs and Component Rules
And if R1 does not have a version resource? Most of the files involved will
not have version resources. Â They will be text/XML, arbitrary binary data,
or .jar files.
Scott
On Mon, Sep 21, 2009 at 2:19 PM, Blair os...@live.com wrote:
If you're reasonably certain that you will never need R2 again:
I assume V1 looks like this:
Component Id='C1' ...
 File Id='R1' Keypath='yes' .../
 ... Id='R2'/
 ... Id='R3'/
/Component
For V2:
Preferred
  1: Change ProductCode(s) (make this a major upgrade)
  2: Force an updated version resource in R1 (sorry)
Component Id='C1' ...
 File Id='R1' Keypath='yes' .../
 !-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
 !-- if R2 is a file --RemoveFile Id='R2' On='install' Name='...'/
 !-- if R2 is a registry key --RemoveRegistryKey
Action='removeOnInstall'
.../
 !-- you are out of luck if it us just a registry value --
 ... Id='R3'/
/Component
I can work on the extra credit latter...
-Original Message-
From: Scott Palmer [mailto:swpal...@gmail.com]
Sent: Monday, September 21, 2009 7:46 AM
To: General discussion for Windows Installer XML toolset.
Subject: [WiX-users] Upgrade Installs and Component Rules
In version 1 of my application I have a component C1 which contains
multiple
resources.
 C1 = { R1, R2, R3 }
The file R1 is the key path for C1.
The rest of the application requires that the resources are installed with
the same path and names in V1 and V2.
In version 2 of my application I need to install a newer version of R3.
What's the right thing to do?
Version 2 of my application no longer needs R2.
What is the right thing to do?
(Extra credit: How does this change if R2 was the key path for the
component?)
The problems I'm having are that I can't change the name or path to the
resources because the application requires them to be found at a
particular
path - that's a pretty basic requirement that I don't think is
unreasonable.
 That seems to mean that I can never split the resources into different
components and I can never remove a resource, because...
The component rules at
http://msdn.microsoft.com/en-us/library/aa367849(VS.85).aspx state:
Introduce a new component and assign it a unique component code when
making
any of the following changes:
 - Any change that has not been shown by testing to be compatible with
 previous versions of the component. In this case, you must also change
the
 name or target location of every resource in the component.
 - A change in the name or target location of any file, registry key,
 shortcut, or other resource in the component. In this case, you must
also
 change the name or target location of every resource in the component.
 - The addition or removal of any file, registry key, shortcut, or other
 resource from the component. *In this case, you must also change the
name
 or target location of every resource in the component.*
That last item to me says - you can't change components ever without
breaking your application. Â In what universe is it possible or practical
to
change the name or target location of every resource in the component
without breaking the application?
It seems that the only way to make an installer that can be upgraded is to
limit things to one resource per component. Â Is that right?
The component rules also state:
A new version of a component is assigned the same component code as
another
existing component. Modifying a component without changing the component
code is only optional in the following cases:
 - The changes to the component have been proven by testing to be
backward
 compatible with all previous versions of the component.
 - The author can guarantee that the new version of the
[WiX-users] Logonasservice user property not working
I am trying to use the LogonAsService property of User to grant the appropriate rights to a service account, but am still getting Service 'Connector' (Connector) failed to start. Verify that you have sufficient privileges to start system services. Does something look wrong in the below service.xml code? ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Name=Connector Service Id=383399A4-5AC1-4454-B8EF-E03C26A50454 Language=1033 Version=1.0.0.0 Manufacturer=IT UpgradeCode=05A9B21B-C2B8-4be0-ABAC-538C5A82E9C5 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=ServiceInstall.cab EmbedCab=yes / Property Id='ExecXmlFile' Hidden='yes' / Property Id='SERVICEPASSWORD' Hidden='yes' Secure='yes' / Directory Id=TARGETDIR Name=SourceDir FileSource=C:\ Directory Id=ProgramFilesFolder Name=Program Files Directory Id=FolderService Name=Connector Service Component Id=InstallService Guid=13BD0DDC-C08C-496a-AD44-2CAF6614B1B4 util:User Id=ServiceAccountUser Domain=[SERVICEDOMAIN] Name=[SERVICEUSERNAME] CreateUser=no LogonAsService=yes UpdateIfExists=yes/ File Id=SVCA01 Name=ConnectorCore.dll Source=SourceFiles\ConnectorCore.dll KeyPath=no/ File Id=SVCA02 Name=ConnectorService.exe Source=SourceFiles\ConnectorService.exe KeyPath=yes/ File Id=SVCA03 Name=ConnectorService.exe.config Source=SourceFiles\ConnectorService.exe.config KeyPath=no/ ServiceInstall Id=Connector Name=Connector DisplayName=Connector Type=ownProcess Start=auto ErrorControl=normal Description=Connector Service Account=[SERVICEDOMAIN]\[SERVICEUSERNAME] Password=[SERVICEPASSWORD] / ServiceControl Id=StartService Name=Connector Start=install Wait=no / ServiceControl Id=StopService Name=Connector Stop=both Wait=yes Remove=uninstall / /Component /Directory /Directory /Directory Feature Id=MainFeature Title=MainInstallation Level='1' ComponentRef Id=InstallService/ /Feature /Product /Wix -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Logonasservice user property not working
I am trying to use the LogonAsService property of User to grant the appropriate rights to a service account, but am still getting Service 'Connector' (Connector) failed to start. Verify that you have sufficient privileges to start system services. Does something look wrong in the below service.xml code? ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Name=Connector Service Id=383399A4-5AC1-4454-B8EF-E03C26A50454 Language=1033 Version=1.0.0.0 Manufacturer=IT UpgradeCode=05A9B21B-C2B8-4be0-ABAC-538C5A82E9C5 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=ServiceInstall.cab EmbedCab=yes / Property Id='ExecXmlFile' Hidden='yes' / Property Id='SERVICEPASSWORD' Hidden='yes' Secure='yes' / Directory Id=TARGETDIR Name=SourceDir FileSource=C:\ Directory Id=ProgramFilesFolder Name=Program Files Directory Id=FolderService Name=Connector Service Component Id=InstallService Guid=13BD0DDC-C08C-496a-AD44-2CAF6614B1B4 util:User Id=ServiceAccountUser Domain=[SERVICEDOMAIN] Name=[SERVICEUSERNAME] CreateUser=no LogonAsService=yes UpdateIfExists=yes/ File Id=SVCA01 Name=ConnectorCore.dll Source=SourceFiles\ConnectorCore.dll KeyPath=no/ File Id=SVCA02 Name=ConnectorService.exe Source=SourceFiles\ConnectorService.exe KeyPath=yes/ File Id=SVCA03 Name=ConnectorService.exe.config Source=SourceFiles\ConnectorService.exe.config KeyPath=no/ ServiceInstall Id=Connector Name=Connector DisplayName=Connector Type=ownProcess Start=auto ErrorControl=normal Description=Connector Service Account=[SERVICEDOMAIN]\[SERVICEUSERNAME] Password=[SERVICEPASSWORD] / ServiceControl Id=StartService Name=Connector Start=install Wait=no / ServiceControl Id=StopService Name=Connector Stop=both Wait=yes Remove=uninstall / /Component /Directory /Directory /Directory Feature Id=MainFeature Title=MainInstallation Level='1' ComponentRef Id=InstallService/ /Feature /Product /Wix -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Cannot install in any other drive, except c drive
Hi, I have a strange problem with my installer. When I select a drive other than C drive for installation. The installation is failing. Can you please let me know, what could be the problem? Thanks Regards, Srivardhan. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Question regarding Wix version 3.5 installation
Hi all, Are majority of the people using WIX version 3.5? I tried installing WIX version 3.5 on top of 3.0 version; after the installation of 3.5 I can't load any of the projects in visual studio; that I was working or developed using previous version (wix 3.0). Checking the error message returned by VS 2008, I copied the following files in C:\Program Files\MSBuild\Microsoft\WiX\v3.0 WixTasks.dll wix.targets wix.ca.targets This allowed me to load all the projects (setup and custom action projects) or even the setup project. Once the project was loaded, I tried compiling the whole solution (which contains the setup project and Custom action project). And was unable to compile the Custom action that was part of the solution... and these are the errors I am getting in VS 2008 when I try compiling: Error 3 The command ..\sdk\MakeSfxCA.exe C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\obj\x86\Debug\Pre InstallCustomAction.CA.dll ..\sdk\x86\SfxCA.dll C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\obj\x86\Debug\Pre InstallCustomAction.dll C:\Program Files\Windows Installer XML v3.5\SDK\Microsoft.Deployment.WindowsInstaller.dll;C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\CustomAction.conf ig exited with code 3. Error 1 The ExactAssemblyVersions parameter is not supported by the Light task. Verify the parameter exists on the task, and it is a settable public instance property. C:\Program Files\MSBuild\Microsoft\WiX\v3.5\Wix.targets Error 2 The Light task could not be initialized with its input parameters. C:\Program Files\MSBuild\Microsoft\WiX\v3.5\Wix.targets MakeSfxCA.exe is present under the WIX 3.5 installation directory... but for some weird reason VS is not showing the fully qualified path to MakeSfxCA.exe(normally under 3.0 release version, you would see the whole path where MakeSfxCA.exe is); in the output window I saw the following error which was different from the error window ..\sdk\MakeSfxCA.exe C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\obj\x86\Debug\Pre InstallCustomAction.CA.dll ..\sdk\x86\SfxCA.dll C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\obj\x86\Debug\Pre InstallCustomAction.dll C:\Program Files\Windows Installer XML v3.5\SDK\Microsoft.Deployment.WindowsInstaller.dll;C:\Documents and Settings\Owner\My Documents\Visual Studio 2008\Projects\Wix Samples\WixSetupSamplesCustomUI\PreInstallCustomAction\CustomAction.conf ig The system cannot find the path specified. Is there something I need to do before I can compile a wix 3.0 solution/project files under WIX v3.5? Or should I revert back to 3.0 version of wix. (I tried installing wix 3.5 because of sample code I found over the web, which required 3.5) Any help would be appreciated on this. Thanks khan -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] warning LGHT1076: ICE68 when adding ngen step to installed .dll files
Hi all. I'm migrating our wix2 install to wix3. In the process, I'm reinstating the netfx tags on some .dll files to get them ngen'ed as part of the install, eg: File Id='Controls.dll' Name='Controls.dll' DiskId='1' Source='..\bin\Controls.dll' netfx:NativeImage Id=NGenControls.dll Priority=0 Platform=32bit / /File With the netfx tag added, I get the following warning from light: light -nologo -ext WixUIExtension -ext WixNetFxExtension Resolver-One.wixobj C:\delivery\Dev\wix30_public\src\ext\NetFxExtension\wixlib\NetFxExtension.wxs(819): warning LGHT1076: ICE68: This package has elevated commit in CustomAction table (Action=NetFxExecuteNativeImageCommitInstall) but it has a schema less than 150. Running the produced .msi file, the dll files are installed, and they are scheduled for ngen on priority 3. I'd really like to be able to ngen them synchronously, as part of the install, as we did with Wix2. I can't understand the above warning, and haven't been able to Google anything useful either. Does anyone have any clues, or suggestions of what I should be reading up on? Many thanks, Jonathan -- Jonathan Hartley Made of meat. http://tartley.com tart...@tartley.com +44 7737 062 225 twitter/skype: tartley -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Generally speaking, if people want that degree of control over the result they don't use a pre-existing program because this is the kind of frustration they run into. I've run into this type of ping problem before, and found a C++ example on the internet. So in this case I'd be sticking that code into a C++ custom action call and have it set whatever properties were needed. However, I don't think it's common (or at least it shouldn't be, IMO) to be in a situation where (for example) an install cannot proceed because it can't ping some server somewhere. If you're configuring something to point to a server during the install you probably need a configuration tool later anyway in case the server name changes, so just do it there. This is the whole installation vs configuration thing, and if you are now doing in a post-install step then I think you're doing the right thing, FWIW. Phil Wilson -Original Message- From: Simon Topley [mailto:simon.top...@wallingfordsoftware.com] Sent: Wednesday, September 23, 2009 2:10 AM To: Blair Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Ping Server from dialog Thanks for the offer Blair but I'll probably just write a configuration tool instead. This is like striping an engine with a set of cutlery. It is very annoying that the asynchronous return types do have meaningful return values, surely this is a pretty common thing people want to do. -Original Message- From: Blair [mailto:os...@live.com] Sent: 23 September 2009 00:40 To: Simon Topley Subject: RE: [WiX-users] Ping Server from dialog From the POV of Windows Installer, an action succeeds or fails. It is up to the action if it wants to set properties instead. From the POV of CAQuietExec, it exists for the sole purpose of preventing the flashing command-prompt-style windows you get calling command-line applications directly from Windows Installer. It intends to extend the same calling model. You need a modified version of CAQuietExec that sets a property with the result code of the external application instead of using the result code to return action success or failure. You could write it yourself, or someone else could write one for you. I'll send you one for US$25.00 licensed with the CPL (same license as the WiX toolset). -Original Message- From: Simon Topley [mailto:simon.top...@wallingfordsoftware.com] Sent: Tuesday, September 22, 2009 9:41 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Ping Server from dialog 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: Control Id=Install Type=PushButton X=236 Y=243 Width=56 Height=17 Default=yes Text=amp;Next gt; Publish Event=NewDialog Value=[WixUI_RMSPortInput_Next]1/Publish Publish Event=DoAction Value=pingISAServer1/Publish /Control 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. Property Id=QtExecCmdLine Value=quot;ping.exequot; /n 1 [ISASERVER]/ CustomAction Id=pingServer BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check/ Binary Id=wixca src=wixca.dll/ InstallExecuteSequence Custom Action='pingServer' After=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence Disclaimer: This electronic communication and its
Re: [WiX-users] Logonasservice user property not working
If you comment out the StartService ServiceControl, can you start the service after you install? -Original Message- From: Elena Powell [mailto:epow...@microsoft.com] Sent: Wednesday, September 23, 2009 10:23 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Logonasservice user property not working I am trying to use the LogonAsService property of User to grant the appropriate rights to a service account, but am still getting Service 'Connector' (Connector) failed to start. Verify that you have sufficient privileges to start system services. Does something look wrong in the below service.xml code? ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; xmlns:util=http://schemas.microsoft.com/wix/UtilExtension; Product Name=Connector Service Id=383399A4-5AC1-4454-B8EF-E03C26A50454 Language=1033 Version=1.0.0.0 Manufacturer=IT UpgradeCode=05A9B21B-C2B8-4be0-ABAC-538C5A82E9C5 Package InstallerVersion=200 Compressed=yes / Media Id=1 Cabinet=ServiceInstall.cab EmbedCab=yes / Property Id='ExecXmlFile' Hidden='yes' / Property Id='SERVICEPASSWORD' Hidden='yes' Secure='yes' / Directory Id=TARGETDIR Name=SourceDir FileSource=C:\ Directory Id=ProgramFilesFolder Name=Program Files Directory Id=FolderService Name=Connector Service Component Id=InstallService Guid=13BD0DDC-C08C-496a-AD44-2CAF6614B1B4 util:User Id=ServiceAccountUser Domain=[SERVICEDOMAIN] Name=[SERVICEUSERNAME] CreateUser=no LogonAsService=yes UpdateIfExists=yes/ File Id=SVCA01 Name=ConnectorCore.dll Source=SourceFiles\ConnectorCore.dll KeyPath=no/ File Id=SVCA02 Name=ConnectorService.exe Source=SourceFiles\ConnectorService.exe KeyPath=yes/ File Id=SVCA03 Name=ConnectorService.exe.config Source=SourceFiles\ConnectorService.exe.config KeyPath=no/ ServiceInstall Id=Connector Name=Connector DisplayName=Connector Type=ownProcess Start=auto ErrorControl=normal Description=Connector Service Account=[SERVICEDOMAIN]\[SERVICEUSERNAME] Password=[SERVICEPASSWORD] / ServiceControl Id=StartService Name=Connector Start=install Wait=no / ServiceControl Id=StopService Name=Connector Stop=both Wait=yes Remove=uninstall / /Component /Directory /Directory /Directory Feature Id=MainFeature Title=MainInstallation Level='1' ComponentRef Id=InstallService/ /Feature /Product /Wix -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Multi language patching
Not necessarily exactly this issue. In MSI, the order that the various transforms are applied is key. When I investigated using transforms, I didn't discover the page on MSDN that describes the order that combining transforms and patches on a commandline (or later, when adding more patches) would present themselves (I don't recall if I found that page later on or not, because in the end the complexity involved wasn't something I wanted to tackle at the time). It is possible to setup transforms (including those in patches) to ignore the language settings of their targets, but that isn't always a good idea, especially if you don't have total control over the way others carry out deployments of your code (they would succeed at applying your German patch on your French transform, which is likely never a good thing). As a result, we stepped back and thought about how else we could address our goals, and in the end the only transforms we use are those embedded inside the patches we use for servicing. We use an external UI (no dialogs in the MSIs) and thus avoid all the issues surrounding MSI and its weak IU primitives and font problems associated with using UTF-8 (required in the MSIs to deploy in several languages we support). Our latest move is to use separate MSIs for the loc-specific stuff to reduce our servicing costs as well as our deployment costs associated with adding new languages post-release and to enable MUI deployments (more than one language installed side-by-side). It has the benefit of reducing build times by 4-6 hours as well. Our software has a consumer rather than an enterprise orientation, so Group Policy deployment wasn't considered an issue, but if both MSIs are present and included in the push, it should still work. MSI 4.5 would help there with the transactional chaining it provides as it can reference both MSIs in the transaction. -Original Message- From: Gareth [mailto:gmor...@serif.com] Sent: Wednesday, September 23, 2009 9:48 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Multi language patching So, you've seen this behaviour before and agree that there's an MSI limitation relating to language specific files in a multi language package? I'm just really interested to know if the patch failures I've seen are because of the language specifications. Blair-2 wrote: We avoided this headache... -- View this message in context: http://n2.nabble.com/Multi-language-patching-tp3700410p3700931.html Sent from the wix-users mailing list archive at Nabble.com. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Cannot install in any other drive, except c drive
What error does it give? What does a verbose log say? -Original Message- From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com] Sent: Wednesday, September 23, 2009 11:17 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Cannot install in any other drive, except c drive Hi, I have a strange problem with my installer. When I select a drive other than C drive for installation. The installation is failing. Can you please let me know, what could be the problem? Thanks Regards, Srivardhan. -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] warning LGHT1076: ICE68 when adding ngen step to installed .dll files
Do you really need to support Windows Me or earlier? In your Package element, set the InstallerVersion attribute to 200 or higher. -Original Message- From: Jonathan Hartley [mailto:tart...@tartley.com] Sent: Wednesday, September 23, 2009 11:04 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] warning LGHT1076: ICE68 when adding ngen step to installed .dll files Hi all. I'm migrating our wix2 install to wix3. In the process, I'm reinstating the netfx tags on some .dll files to get them ngen'ed as part of the install, eg: File Id='Controls.dll' Name='Controls.dll' DiskId='1' Source='..\bin\Controls.dll' netfx:NativeImage Id=NGenControls.dll Priority=0 Platform=32bit / /File With the netfx tag added, I get the following warning from light: light -nologo -ext WixUIExtension -ext WixNetFxExtension Resolver-One.wixobj C:\delivery\Dev\wix30_public\src\ext\NetFxExtension\wixlib\NetFxExtension.wx s(819): warning LGHT1076: ICE68: This package has elevated commit in CustomAction table (Action=NetFxExecuteNativeImageCommitInstall) but it has a schema less than 150. Running the produced .msi file, the dll files are installed, and they are scheduled for ngen on priority 3. I'd really like to be able to ngen them synchronously, as part of the install, as we did with Wix2. I can't understand the above warning, and haven't been able to Google anything useful either. Does anyone have any clues, or suggestions of what I should be reading up on? Many thanks, Jonathan -- Jonathan Hartley Made of meat. http://tartley.com tart...@tartley.com +44 7737 062 225 twitter/skype: tartley -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] performance counters are not being uninstalled
I have a wix project that installs performance counters using the util:PerformanceCategory and util:PerformanceCounter elements. The performance counters are installed as expected. However, when uninstalling, the performance counters are sometimes left installed on the machine. Here is an example of the pattern we are using: Component Id='perfCounters' Guid='C0D623E8-F04C-48A7-9F2D-5F996891AE24' KeyPath='yes' util:PerformanceCategory Id=PerfCounterCategory Name=ProductPerfCounters MultiInstance=yes util:PerformanceCounter Name=Requests per second Type=rateOfCountsPerSecond64 / util:PerformanceCounter Name=Request count Type=numberOfItems64 / /util:PerformanceCategory /Component Does anyone know why the performance counters are left installed sometimes? Is there a way to 'force' them to be uninstalled using wix? Joshua Thor Holm SDE | AdECN | Microsoft 805-566-2645 | joh...@microsoft.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Creating Local Security Groups
I'm trying to create a local security group, and not having much luck. I currently have a couple of CA's, one defining the property for the location of net.exe, then one to invoke the call: CustomAction Id=SetCmdLine_CreatePMGroup Property=QtExecCmdLine Value=quot;[SystemFolder]net.exe localgroup PowerMonitorUsers /add / CustomAction Id=QtExec_PowerMonitorUsersGroupCreate BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=ignore Impersonate=no / /Fragment I'm getting a return code of 1. I'm thinking it has to do something with elevation, however looking at the table directly, the CA for PowerMonitorUsersGroupCreate is type 3137, which is setting the msidbCustomActionTypeNoImpersonate bit. Has anyone created a Local Security group and populated it before? -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] performance counters are not being uninstalled
When uninstalling, what does a verbose log say about the states of the perfCounters component (look around CostFinalize in the log). -Original Message- From: Josh Holm [mailto:joh...@microsoft.com] Sent: Wednesday, September 23, 2009 1:27 PM To: wix-users@lists.sourceforge.net Cc: Peter Moresi; Aaron Allin Subject: [WiX-users] performance counters are not being uninstalled I have a wix project that installs performance counters using the util:PerformanceCategory and util:PerformanceCounter elements. The performance counters are installed as expected. However, when uninstalling, the performance counters are sometimes left installed on the machine. Here is an example of the pattern we are using: Component Id='perfCounters' Guid='C0D623E8-F04C-48A7-9F2D-5F996891AE24' KeyPath='yes' util:PerformanceCategory Id=PerfCounterCategory Name=ProductPerfCounters MultiInstance=yes util:PerformanceCounter Name=Requests per second Type=rateOfCountsPerSecond64 / util:PerformanceCounter Name=Request count Type=numberOfItems64 / /util:PerformanceCategory /Component Does anyone know why the performance counters are left installed sometimes? Is there a way to 'force' them to be uninstalled using wix? Joshua Thor Holm SDE | AdECN | Microsoft 805-566-2645 | joh...@microsoft.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Creating Local Security Groups
Where is that return code reported? Is the group created? Actions that are successful (because the EXE returns 0 or the DLL returns ERROR_SUCCESS) has a report in the log of returning 1 because the return codes from EXE/DLL are translated into the script return codes reported on this page: http://msdn.microsoft.com/en-us/library/aa371254(VS.85).aspx. As an example, I have a DLL custom action (named BLMSetPropertyKnownFolders_x64) that returns ERROR_SUCCESS and this is how it shows up in the log: MSI (s) (B0:A0) [18:30:03:821]: Doing action: BLMSetPropertyKnownFolders_x64 Action start 18:30:03: BLMSetPropertyKnownFolders_x64. MSI (s) (B0:B0) [18:30:03:904]: Invoking remote custom action. DLL: C:\Windows\Installer\MSIC822.tmp, Entrypoint: SetPropertyKnownFolders SetPropertyKnownFolders: Initialized. MSI (s) (B0!1C) [18:30:04:036]: PROPERTY CHANGE: Adding KDOCUMENTS property. Its value is 'C:\Users\Blair\Documents\'. Action ended 18:30:04: BLMSetPropertyKnownFolders_x64. Return value 1. That return value means: msiDoActionStatusSuccess IDOK = 1 Action completed successfully. -Original Message- From: James Lucero [mailto:jluc...@microsoft.com] Sent: Wednesday, September 23, 2009 1:29 PM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Creating Local Security Groups I'm trying to create a local security group, and not having much luck. I currently have a couple of CA's, one defining the property for the location of net.exe, then one to invoke the call: CustomAction Id=SetCmdLine_CreatePMGroup Property=QtExecCmdLine Value=quot;[SystemFolder]net.exe localgroup PowerMonitorUsers /add / CustomAction Id=QtExec_PowerMonitorUsersGroupCreate BinaryKey=WixCA DllEntry=CAQuietExec Execute=deferred Return=ignore Impersonate=no / /Fragment I'm getting a return code of 1. I'm thinking it has to do something with elevation, however looking at the table directly, the CA for PowerMonitorUsersGroupCreate is type 3137, which is setting the msidbCustomActionTypeNoImpersonate bit. Has anyone created a Local Security group and populated it before? -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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
Thanks Blair. Sorry I missed the real error. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 22, 2009 12:57 PM To: Lian Jiang Cc: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Return='ignore' causes ICE68: invalid custom action type for action 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: CustomAction Id=InstallWindowsFeatures Property=InstallWindowsFeaturesDeferred Value='[WindowsFolder]Sysnative\dism.exe /online /NoRestart /enable-feature /featurename:NetFx3 /featurename:Xps-Foundation-Xps-Viewer /featurename:InkSupport /featurename:DesktopExperience /featurename:SearchEngine-Server-Package /featurename:Indexing-Service-Package' Execute='immediate' / CustomAction Id=InstallWindowsFeaturesDeferred BinaryKey='WixCA' DllEntry=CAQuietExec Execute=deferred Return='ignore' Impersonate=no / 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: CustomAction Id=InstallWindowsFeatures Property=InstallWindowsFeaturesDeferred Value='[WindowsFolder]Sysnative\dism.exe /online ..' Execute='immediate'/ CustomAction Id=InstallWindowsFeaturesDeferred BinaryKey='WixCA' DllEntry=CAQuietExec64 Execute=deferred Return='ignore' Impersonate=no / 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
Re: [WiX-users] Return='ignore' causes ICE68: invalid custom action type for action
Happens to all of us a few times. Those log files are NOT user-friendly/easy to read. A hint for everyone: Look for a localized equivalent of Action ended hh:mm:ss: ActionName. Return value n. in your log where hh:mm:ss is the clock time, ActionName is the action you are interested in seeing, and n is from the following chart: 0 Action not executed. 1 Action completed successfully. 2 Premature termination by user. 3 Unrecoverable error. 4 Suspended sequence to be resumed later. 5 Skip remaining actions. Not an error. Most errors are reported as '3' and successes as '1'. -Blair -Original Message- From: Lian Jiang [mailto:lji...@microsoft.com] Sent: Wednesday, September 23, 2009 2:15 PM To: Blair Cc: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Return='ignore' causes ICE68: invalid custom action type for action Thanks Blair. Sorry I missed the real error. -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, September 22, 2009 12:57 PM To: Lian Jiang Cc: 'General discussion for Windows Installer XML toolset.' Subject: RE: [WiX-users] Return='ignore' causes ICE68: invalid custom action type for action 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: CustomAction Id=InstallWindowsFeatures Property=InstallWindowsFeaturesDeferred Value='[WindowsFolder]Sysnative\dism.exe /online /NoRestart /enable-feature /featurename:NetFx3 /featurename:Xps-Foundation-Xps-Viewer /featurename:InkSupport /featurename:DesktopExperience /featurename:SearchEngine-Server-Package /featurename:Indexing-Service-Package' Execute='immediate' / CustomAction Id=InstallWindowsFeaturesDeferred BinaryKey='WixCA' DllEntry=CAQuietExec Execute=deferred Return='ignore' Impersonate=no / 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: CustomAction Id=InstallWindowsFeatures
Re: [WiX-users] Cannot install in any other drive, except c drive
From: Sunkesula, Srivardhan [mailto:srivardhan.sunkes...@netapp.com] I have a strange problem with my installer. When I select a drive other than C drive for installation. The installation is failing. Can you please let me know, what could be the problem? Thanks Regards, Srivardhan. You've probably got something wrong in one of your WiX source files. A verbose log of the installation failing might help you see what's wrong; if it doesn't help you, it might help someone here help you. See also http://www.catb.org/~esr/faqs/smart-questions.html -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Restore set of files on uninstall.
I have to restore some set of files on uninstall of my servicepack msi. How can I achieve this.?? Thanks, Bala Ganesh, G. Senior Systems Engineer, Contact :- 9841403532 This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED.If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. For Information on Adrenalin, call toll-free 1-800-425-4252 | Write to i...@myadrenalin.com | Visit www.myadrenalin.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Restore set of files on uninstall.
What is the source of the files your servicepack MSI replaced? Did your servicepack MSI remove that previous product(s) or simply overwrite their files? Has your servicepack MSI already been shipped? -Original Message- From: Bala Ganesh [mailto:balaganes...@myadrenalin.com] Sent: Wednesday, September 23, 2009 8:35 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Restore set of files on uninstall. I have to restore some set of files on uninstall of my servicepack msi. How can I achieve this.?? Thanks, Bala Ganesh, G. Senior Systems Engineer, Contact :- 9841403532 This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED.If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. For Information on Adrenalin, call toll-free 1-800-425-4252 | Write to i...@myadrenalin.com | Visit www.myadrenalin.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; 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] Restore set of files on uninstall.
ServicePack not yet shipped. Servicepack MSI just overwrite some (.dll) files, so while uninstall I have to restore all the overwrited dll with the old one. Bala Ganesh, G. Senior Systems Engineer, Contact :- 9841403532 -Original Message- From: Blair [mailto:os...@live.com] Sent: Thursday, September 24, 2009 10:18 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Restore set of files on uninstall. What is the source of the files your servicepack MSI replaced? Did your servicepack MSI remove that previous product(s) or simply overwrite their files? Has your servicepack MSI already been shipped? -Original Message- From: Bala Ganesh [mailto:balaganes...@myadrenalin.com] Sent: Wednesday, September 23, 2009 8:35 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Restore set of files on uninstall. I have to restore some set of files on uninstall of my servicepack msi. How can I achieve this.?? Thanks, Bala Ganesh, G. Senior Systems Engineer, Contact :- 9841403532 This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED.If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. For Information on Adrenalin, call toll-free 1-800-425-4252 | Write to i...@myadrenalin.com | Visit www.myadrenalin.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; 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 BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This email (including any attachments) is intended for the sole use of the intended recipient/s and may contain material that is CONFIDENTIAL AND PRIVATE COMPANY INFORMATION. Any review or reliance by others or copying or distribution or forwarding of any or all of the contents in this message is STRICTLY PROHIBITED.If you are not the intended recipient, please contact the sender by email and delete all copies; your cooperation in this regard is appreciated. For Information on Adrenalin, call toll-free 1-800-425-4252 | Write to i...@myadrenalin.com | Visit www.myadrenalin.com -- Come build with us! The BlackBerryreg; 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#45;12, 2009. Register now#33; http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
