Re: [WiX-users] Wix 3.0 FileSearch
Hi Blair, Thank you for your help. I checked the log file. AppSearch(property EXE_EXISTS) was set before INSTALLDIR but CA_RunEXE was called after INSTALLDIR set. Execute Sequences: 1. AppSearch property EXE_EXISTS assigned 2. Property INSTALLDIR assigned 2. CA_RunEXE custom action evaluated but not called becase the codition failed. Custom Action=CA_RunEXE After=InstallInitializeEXE_EXISTS/Custom If I execute msiexec with INSTALLDIR parameter e.g.: msiexec /i test.msi /l*vx test.log installdir=C:\Program Files\Company\Product\ my custom action call sucessfully. Can anyone know how to fix this problem? Thanks Jeff --- On Mon, 14/9/09, Blair os...@live.com wrote: From: Blair os...@live.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: 'General discussion for Windows Installer XML toolset.' wix-users@lists.sourceforge.net Received: Monday, 14 September, 2009, 9:17 PM INSTALLDIR may be set before your CA_RunEXE custom action runs (it will be set by the time the standard action CostFinalize runs if it wasn't set explicitly before, because CostFinalize populates all the properties identified in the Directory table) but it may not be set when the standard AppSearch runs, and that was the question Sebastian asked. Can you confirm that INSTALLDIR is set before the AppSearch action runs? Please search a debug verbose log for INSTALLDIR to see when it is first set, and if that is before AppSearch or after. -Original Message- From: puyo puy [mailto:puyo...@yahoo.com] Sent: Monday, September 14, 2009 1:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 3.0 FileSearch Hi, Can someone from WIX confirm that is a bug or I did something wrong. Thanks Jeff --- On Fri, 11/9/09, puyo puy puyo...@yahoo.com wrote: From: puyo puy puyo...@yahoo.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Received: Friday, 11 September, 2009, 9:29 AM Hi Sebastian Thank you for your quick reply. Yes, I'm sure that INSTALLDIR was set before called. I added extract custom action before execute CA_RunEXE to display the property INSTALLDIR to the log file and I can see the value is correct. I copy that value and replaced Path=[INSTALLDIR] to Path=C:\Program Files\Company\Product\ and it works. Function LogMsg Dim rec Set rec = Session.Installer.CreateRecord(1) rec.StringData(0) = Session.Property(INSTALLDIR) LogInfo = Session.Message(H0400, rec) End function I also tried your suggestion to remove @Id from FileSearch but still doesn't works. FileSearch Name=APP.exe / Thanks Jeff --- On Thu, 10/9/09, Sebastian Brand (Instyler Software) wix+us...@instyler.com wrote: From: Sebastian Brand (Instyler Software) wix+us...@instyler.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: 'General discussion for Windows Installer XML toolset.' wix-users@lists.sourceforge.net Received: Thursday, 10 September, 2009, 6:33 PM Hello, Are you sure the INSTALLDIR property is set already when the FileSearch begins? Also try removing the @Id from the FileSearch, I remember there was an issue with that when trying to get sub-directories. Best regards, Sebastian Brand Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: puyo puy [mailto:puyo...@yahoo.com] Sent: Thursday, September 10, 2009 10:31 To: wix users Subject: [WiX-users] Wix 3.0 FileSearch Hi there, I'm trying to create msi installer using wix and this installer will search for old application for current install location. When the old application found, a custom action will execute the old application. I used the following script to search for the old application. Property Id=EXE_EXISTS DirectorySearch Id=CheckInstallDir Path=[INSTALLDIR] Depth=0 FileSearch Id=CheckExeFile Name=APP.exe / /DirectorySearch /Property When the old application found, custom action CA_RunEXE will execute. InstallExecuteSequence Custom Action=CA_RunEXE After=InstallInitializeEXE_EXISTS/Custom /InstallExecuteSequence But according to the msi log, action CA_RunEXE never execute because condition is false even the old application exist. From the log file I see INSTALLDIR already set and pointed to correct location(C:\Program Files\Company\Product\). If I replace DirectorySearch Id=CheckInstallDir Path=[INSTALLDIR] Depth=0 to DirectorySearch Id=CheckInstallDir Path=C:\Program Files\Company\Product\ Depth=0 , the action CA_RunEXE executed as expected. I cannot hardcode the Path as user may install in different locations. Can anyone of you can see what's wrong in my script? Thanks in advance Jeff __ Get more done like never before with Yahoo!7 Mail. Learn more:
Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value
No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Blair, Can we attribute this to a bug in WiX 3.0 then? If I need to write a work around, does WiX provide any parsing capabilities, or should I look at using VBScript or similar to get this working? Dominique. -Original Message- From: Blair [mailto:os...@live.com] Sent: 14 September 2009 17:34 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value In my tests using a simple installation package, it would appear that the conditional comparison routines for strings stop looking through the string at the first NUL character. Since REG_MULTI_SZ strings start with a NUL, then terminate each value with an additional NUL (remember that the conditional is evaluated AFTER the string is parsed replacing all [whatever] property references) means that the conditional syntax can't see any values after the first [~] value (which would include all values retrieved using RegistrySearch involving REG_MULTI_SZ strings. You can check for presence of the property, however. (If the property were truly empty, it would be removed). To see what I am talking about, compare these three lines from my log: AppSearch: Property: MYMULTIVALUE, Signature: MyMultiValue MSI (c) (38:98) [09:26:38:902]: PROPERTY CHANGE: Adding MYMULTIVALUE property. Its value is ''. Property(C): MYMULTIVALUE = [~]SysClass.Dll,StorageCoInstaller[~]WmiProp.dll,WmiPropCoInstaller[~] Those are the only references to that property in the entire debug verbose log. You would need some custom action to parse or otherwise escape the property values in the property before using the condition syntax to search them. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Monday, September 14, 2009 8:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value OK based on Pally's earlier post, it would seem that SQLSERVERMSSQLSERVER or the property equivalent should work, but neither works for me. Do they work for anyone else? -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 14 September 2009 15:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Nope, Changing it to a Property does not work either. I'm guessing that changing it to a property just makes it the equivalent of writing SQLSERVERMSSQLSERVER Which would be incorrect as well. Is the the correct conditional operator for what I'm trying to achieve? What is the difference between and if any? As I mentioned in my original post, some kind of website or official documentation showing exactly how each operator is used in a conditional situation would be really, really useful at this point. At the moment I feel like I'm walking through the woods, blind folded. Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 14 September 2009 14:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Have you tried using a Property with its value set to MSSQLSERVER as I first assumed you were doing? Even something as simple as Property Id=MSSQLSERVER Value=MSSQLSERVER / added to your first code fragment might cause this to work. Essentially your code is doing exactly what you're trying to achieve from how I understand it but a quirk of Windows Installer could be fooling both of us and the above might be the solution.
[WiX-users] Faulting application setup.exe
hi All, i've a sample installer which will be called by my setup.exe, while launching setup.exe after welcome dialog suddenly installation was failing, even logs doesn't giving any errors, so went to the event viewer and i found one error. the error is like this: Faulting application setup.exe, version 12.1.1.75, faulting module unknown, version 0.0.0.0, hang address 0x0001. can anybody help me in this issue? i don't have any clue why this issue is coming. Thanks, bsr -- 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] replacing DialogRef with Dialog is not working
I'd try changing Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=UserRegistrationDlg Order=2LicenseAccepted = 1/Publish To 'Order=1' as from looking at the WiX v3.0 sources, WiXUI_Mondo.wxs has the following: Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=SetupTypeDlg Order=2LicenseAccepted = 1/Publish So it they could be conflicting. Your code looks absolutely fine, other than this nothing jumps out as a possible cause here. If this fixes your issue could you e-mail Gábor DEÁK JAHN (mailto:d...@tramontana.co.hu?subject=wixtutorial) to let him know so he can update the tutorial? Good luck it's good to see people using resources like the tutorial. Keep it up, it doesn't take much to get into WiX but it's very powerful once you know how to use it =) 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: DerekLiang [mailto:derek.liang...@gmail.com] Sent: 14 September 2009 19:18 To: wix-users@lists.sourceforge.net Subject: [WiX-users] replacing DialogRef with Dialog is not working Hi all, I am wondering how to insert a custom dialog into a built-in dialog set in a SINGLE file. Here is what I do. Please let me know what do I do wrong. 1. download the sample zip files, compile, and test successfully. http://www.tramontana.co.hu/wix/download.php?file=samples/samplewixuiadddlg.ziptype=application/zip 2. replaced the DialogRef Id=UserRegistrationDlg / in File SampleWixUIAddDlg.wxs with the content between the UI and /UI tags in UserRegistrationDlg.wxs as the following. 3. compilation is success. However when I try to install the MSI, the UserRegistrationDlg is a not appearing. Is this supposed to work, or there is something else I need to do. Thanks in advance! dl ---content of SampleWixUIAddDlg.wxs ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Name=Foobar 1.0 Id=DF713893-D1DA-4D9D-B58C-1BE2D615E3E9 UpgradeCode=DBE560F6-1832-4F36-9EE0-9F8A31DF9077 Language=1033 Codepage=1252 Version=1.0.0 Manufacturer=Acme Ltd. Package Id=* Keywords=Installer Description=Acme's Foobar 1.0 Installer Comments=Foobar is a registered trademark of Acme Ltd. Manufacturer=Acme Ltd. InstallerVersion=100 Languages=1033 Compressed=yes SummaryCodepage=1252 / Media Id=1 Cabinet=Sample.cab EmbedCab=yes DiskPrompt=CD-ROM #1 / Property Id=DiskPrompt Value=Acme's Foobar 1.0 Installation [1] / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=Acme Name=Acme Directory Id=INSTALLDIR Name=Foobar 1.0 Component Id=MainExecutable Guid=69A40E29-6F4E-4E45-BA28-E839329C7F00 File Id=FoobarEXE Name=FoobarAppl10.exe DiskId=1 Source=FoobarAppl10.exe KeyPath=yes Shortcut Id=startmenuFoobar10 Directory=ProgramMenuDir Name=Foobar 1.0 WorkingDirectory=INSTALLDIR Icon=Foobar10.exe IconIndex=0 Advertise=yes / Shortcut Id=desktopFoobar10 Directory=DesktopFolder Name=Foobar 1.0 WorkingDirectory=INSTALLDIR Icon=Foobar10.exe IconIndex=0 Advertise=yes / /File /Component Component Id=HelperLibrary Guid=73099C09-DAFF-4A5C-8EDE-A35593418FAA File Id=HelperDLL Name=Helper.dll DiskId=1 Source=Helper.dll KeyPath=yes / /Component Component Id=Manual Guid=43BCCCEA-2D92-4308-AB60-061FFCAEE6EA File Id=Manual Name=Manual.pdf DiskId=1 Source=Manual.pdf KeyPath=yes Shortcut Id=startmenuManual Directory=ProgramMenuDir Name=Instruction Manual Advertise=yes / /File /Component /Directory /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=Foobar 1.0 Component Id=ProgramMenuDir Guid=1E5FF05A-8F12-431E-B180-0FDA9E648D3C RemoveFolder Id=ProgramMenuDir On=uninstall / RegistryValue Root=HKCU Key=Software\[Manufacturer]\[ProductName] Type=string Value= KeyPath=yes / /Component /Directory /Directory Directory Id=DesktopFolder Name=Desktop / /Directory Feature Id=Complete Title=Foobar 1.0 Description=The complete package. Display=expand Level=1
Re: [WiX-users] Faulting application setup.exe
Looks like a problem with your bootstrapper. Try running it in a debug session. It shouldn't be affecting your installer though. Once msiexec has been called to run your MSI your bootstrapper *should* have nothing more to do with the whole process. 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: BSR PHANI [mailto:bsrphani...@gmail.com] Sent: 15 September 2009 10:35 To: wix-users-requ...@lists.sourceforge.net; wix-users@lists.sourceforge.net Subject: [WiX-users] Faulting application setup.exe hi All, i've a sample installer which will be called by my setup.exe, while launching setup.exe after welcome dialog suddenly installation was failing, even logs doesn't giving any errors, so went to the event viewer and i found one error. the error is like this: Faulting application setup.exe, version 12.1.1.75, faulting module unknown, version 0.0.0.0, hang address 0x0001. can anybody help me in this issue? i don't have any clue why this issue is coming. Thanks, bsr -- 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] Regarding .Net 3.5 SP1
Hi, Thanks for your reply, but i have to merge that bootstrapper with my installer written by WIX. Please let me know, any thing wich will help me! Thanks S.Muthuramakrishnan. - Original Message - From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Monday, September 14, 2009 3:48 PM Subject: Re: [WiX-users] Regarding .Net 3.5 SP1 http://www.codeplex.com/dotnetinstaller/ 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: Muthuramakrishnan [mailto:s...@srasys.co.in] Sent: 14 September 2009 05:40 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Regarding .Net 3.5 SP1 Hi All, I need the BootStrapper for .net 3.5 SP1. Any Ideas... Thanks S.Muthuramakrishnan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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] Preparing to install...
Bob, Sorry to trouble you. Our tests show different behaviours of this dialog when installing from local disk or CD room. Our installer of single MSI file is about 400MB. When installing from CD on a low spec machine, this Preparing to install dialog box is displayed immediately, then OS hangs while reading MSI file . After 3 minutes, the first MSI dialog is displayed. When installing the same MSI file from local disk, the hour glass lasts about 3 minutes, then Preparing to install dialog box is displayed, and the first MSI dialog is displayed immediately after. Do you know why we have Preparing to install dialog box is displayed at different time? Thanks, Shibo -- View this message in context: http://n2.nabble.com/Preparing-to-install-tp693380p3648840.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] Conditional installed based on REG_MULTI_SZ value
I'm using v4.5.6001.22159 if that is any help to anyone. Is putting my CustomAction before LaunchConditions the best place to run my vbs, or would there be another more appropriate place? Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 15 September 2009 10:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Blair, Can we attribute this to a bug in WiX 3.0 then? If I need to write a work around, does WiX provide any parsing capabilities, or should I look at using VBScript or similar to get this working? Dominique. -Original Message- From: Blair [mailto:os...@live.com] Sent: 14 September 2009 17:34 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value In my tests using a simple installation package, it would appear that the conditional comparison routines for strings stop looking through the string at the first NUL character. Since REG_MULTI_SZ strings start with a NUL, then terminate each value with an additional NUL (remember that the conditional is evaluated AFTER the string is parsed replacing all [whatever] property references) means that the conditional syntax can't see any values after the first [~] value (which would include all values retrieved using RegistrySearch involving REG_MULTI_SZ strings. You can check for presence of the property, however. (If the property were truly empty, it would be removed). To see what I am talking about, compare these three lines from my log: AppSearch: Property: MYMULTIVALUE, Signature: MyMultiValue MSI (c) (38:98) [09:26:38:902]: PROPERTY CHANGE: Adding MYMULTIVALUE property. Its value is ''. Property(C): MYMULTIVALUE = [~]SysClass.Dll,StorageCoInstaller[~]WmiProp.dll,WmiPropCoInstaller[~] Those are the only references to that property in the entire debug verbose log. You would need some custom action to parse or otherwise escape the property values in the property before using the condition syntax to search them. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Monday, September 14, 2009 8:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value OK based on Pally's earlier post, it would seem that SQLSERVERMSSQLSERVER or the property equivalent should work, but neither works for me. Do they work for anyone else? -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 14 September 2009 15:54 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Nope, Changing it to a Property does not work either. I'm guessing that changing it to a property just makes it the equivalent of writing SQLSERVERMSSQLSERVER Which would be incorrect as well. Is the the correct conditional operator for what I'm trying to achieve? What is the difference between and if any? As I mentioned in my original post, some kind of website or official documentation showing exactly how each operator is used in a conditional situation would be really, really useful at this point. At the moment I feel like I'm walking through the woods, blind folded. Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 14 September 2009 14:47 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on
[WiX-users] Component installed even if not part of selected feature
Hi, I have something like Component Id=C1 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app1Sc Name=app sc Icon=... IconIndex=.../ Shortcut Id=app1ScRmt Name=appSc Remote Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C2 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app2Sc Name=app sc Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C3 Guid=... DiskId=1 File.../File /Component Feature Id=Full Level=1 ComponentRef Id=C2/ ComponentRef Id=C3/ /Feature Feature Id=Partial Level=1/ ComponentRef Id=C1/ /Feature I select Full feature for installation; I know it's correct because C3 component files are installed. But I also get the shortcuts from C1 component created which looks like the C1 is installed as well (basically C1 and C2 differs only by a shortcut as above, the files are exactly the same) even if not part of Full install. I saw someone already had a similar problem but can't seem to find an answer for my problem in the answers he got (I don't plan using conditions) http://sourceforge.net/mailarchive/forum.php?thread_name=45f1db380908240448n2c4a5594y3a5e9ee8437ee399%40mail.gmail.comforum_name=wix-users Did anyone had a similar problem? Thanks -- 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] Component installed even if not part of selected feature
Give both app.exe unique File Id's I suspect the shortcuts won't appear. 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: fiordean dacian [mailto:dfiord...@yahoo.com] Sent: 15 September 2009 15:35 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Component installed even if not part of selected feature Hi, I have something like Component Id=C1 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app1Sc Name=app sc Icon=... IconIndex=.../ Shortcut Id=app1ScRmt Name=appSc Remote Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C2 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app2Sc Name=app sc Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C3 Guid=... DiskId=1 File.../File /Component Feature Id=Full Level=1 ComponentRef Id=C2/ ComponentRef Id=C3/ /Feature Feature Id=Partial Level=1/ ComponentRef Id=C1/ /Feature I select Full feature for installation; I know it's correct because C3 component files are installed. But I also get the shortcuts from C1 component created which looks like the C1 is installed as well (basically C1 and C2 differs only by a shortcut as above, the files are exactly the same) even if not part of Full install. I saw someone already had a similar problem but can't seem to find an answer for my problem in the answers he got (I don't plan using conditions) http://sourceforge.net/mailarchive/forum.php?thread_name=45f1db380908240448n2c4a5594y3a5e9ee8437ee399%40mail.gmail.comforum_name=wix-users Did anyone had a similar problem? Thanks -- 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] Conditional installed based on REG_MULTI_SZ value
In that case are you bootstrapping the Windows Installer 4.5 redistributable before your installer runs so all your users/customers will be able to successfully install your product or are you also testing it on 3.1 4.0 to make sure they don't have problems? According to the docs (http://wix.sourceforge.net/manual-wix3/read_a_registry_entry.htm) before LaunchConditions should be fine but I would double check a verbose log just to make sure your RegistrySearch is populating the SQLSERVER Property before your CustomAction attempts to parse it. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 14:53 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value I'm using v4.5.6001.22159 if that is any help to anyone. Is putting my CustomAction before LaunchConditions the best place to run my vbs, or would there be another more appropriate place? Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 15 September 2009 10:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Blair, Can we attribute this to a bug in WiX 3.0 then? If I need to write a work around, does WiX provide any parsing capabilities, or should I look at using VBScript or similar to get this working? Dominique. -Original Message- From: Blair [mailto:os...@live.com] Sent: 14 September 2009 17:34 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value In my tests using a simple installation package, it would appear that the conditional comparison routines for strings stop looking through the string at the first NUL character. Since REG_MULTI_SZ strings start with a NUL, then terminate each value with an additional NUL (remember that the conditional is evaluated AFTER the string is parsed replacing all [whatever] property references) means that the conditional syntax can't see any values after the first [~] value (which would include all values retrieved using RegistrySearch involving REG_MULTI_SZ strings. You can check for presence of the property, however. (If the property were truly empty, it would be removed). To see what I am talking about, compare these three lines from my log: AppSearch: Property: MYMULTIVALUE, Signature: MyMultiValue MSI (c) (38:98) [09:26:38:902]: PROPERTY CHANGE: Adding MYMULTIVALUE property. Its value is ''. Property(C): MYMULTIVALUE = [~]SysClass.Dll,StorageCoInstaller[~]WmiProp.dll,WmiPropCoInstaller[~] Those are the only references to that property in the entire debug verbose log. You would need some custom action to parse or otherwise escape the property values in the property before using the condition syntax to search them. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Monday, September 14, 2009 8:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value OK based on Pally's earlier post, it would seem that SQLSERVERMSSQLSERVER or the
Re: [WiX-users] Regarding .Net 3.5 SP1
http://www.wixwiki.com/index.php?title=Deploying_Additional_Components might be helpful. -Original Message- From: Muthuramakrishnan [mailto:s...@srasys.co.in] Sent: Tuesday, September 15, 2009 5:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Regarding .Net 3.5 SP1 Hi, Thanks for your reply, but i have to merge that bootstrapper with my installer written by WIX. Please let me know, any thing wich will help me! Thanks S.Muthuramakrishnan. - Original Message - From: Pally Sandher pally.sand...@iesve.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Monday, September 14, 2009 3:48 PM Subject: Re: [WiX-users] Regarding .Net 3.5 SP1 http://www.codeplex.com/dotnetinstaller/ 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: Muthuramakrishnan [mailto:s...@srasys.co.in] Sent: 14 September 2009 05:40 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Regarding .Net 3.5 SP1 Hi All, I need the BootStrapper for .net 3.5 SP1. Any Ideas... Thanks S.Muthuramakrishnan -- Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day trial. Simplify your report design, integration and deployment - and focus on what you do best, core application coding. Discover what's new with Crystal Reports now. http://p.sf.net/sfu/bobj-july ___ 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] Component installed even if not part of selected feature
Hi thanks Pally I confirm the C1 and C2 file IDs are all different (I missed that in my example for C2) --- On Tue, 9/15/09, Pally Sandher pally.sand...@iesve.com wrote: From: Pally Sandher pally.sand...@iesve.com Subject: Re: [WiX-users] Component installed even if not part of selected feature To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Date: Tuesday, September 15, 2009, 5:58 PM Give both app.exe unique File Id's I suspect the shortcuts won't appear. 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: fiordean dacian [mailto:dfiord...@yahoo.com] Sent: 15 September 2009 15:35 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Component installed even if not part of selected feature Hi, I have something like Component Id=C1 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app1Sc Name=app sc Icon=... IconIndex=.../ Shortcut Id=app1ScRmt Name=appSc Remote Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C2 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app2Sc Name=app sc Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C3 Guid=... DiskId=1 File.../File /Component Feature Id=Full Level=1 ComponentRef Id=C2/ ComponentRef Id=C3/ /Feature Feature Id=Partial Level=1/ ComponentRef Id=C1/ /Feature I select Full feature for installation; I know it's correct because C3 component files are installed. But I also get the shortcuts from C1 component created which looks like the C1 is installed as well (basically C1 and C2 differs only by a shortcut as above, the files are exactly the same) even if not part of Full install. I saw someone already had a similar problem but can't seem to find an answer for my problem in the answers he got (I don't plan using conditions) http://sourceforge.net/mailarchive/forum.php?thread_name=45f1db380908240448n2c4a5594y3a5e9ee8437ee399%40mail.gmail.comforum_name=wix-users Did anyone had a similar problem? Thanks -- 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 -- 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 -- 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] Conditional installed based on REG_MULTI_SZ value
Make sure it is before LaunchConditions and after AppSearch (you can move either one of those if needed) For example: InstallExecuteSequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallExecuteSequence InstallUISequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallUISequence The usual caveat about VBS (or any other) script CA goes here: they are unreliable (there are anti-virus systems that prevent the script from running and, esp. on Vista, incorrect installations/repairs cause Windows Installer to reject the scripting engine runtime). For reliability, a C/C++ CA statically linked to its runtime is considered best practice. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Tuesday, September 15, 2009 6:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value I'm using v4.5.6001.22159 if that is any help to anyone. Is putting my CustomAction before LaunchConditions the best place to run my vbs, or would there be another more appropriate place? Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 15 September 2009 10:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Blair, Can we attribute this to a bug in WiX 3.0 then? If I need to write a work around, does WiX provide any parsing capabilities, or should I look at using VBScript or similar to get this working? Dominique. -Original Message- From: Blair [mailto:os...@live.com] Sent: 14 September 2009 17:34 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value In my tests using a simple installation package, it would appear that the conditional comparison routines for strings stop looking through the string at the first NUL character. Since REG_MULTI_SZ strings start with a NUL, then terminate each value with an additional NUL (remember that the conditional is evaluated AFTER the string is parsed replacing all [whatever] property references) means that the conditional syntax can't see any values after the first [~] value (which would include all values retrieved using RegistrySearch involving REG_MULTI_SZ strings. You can check for presence of the property, however. (If the property were truly empty, it would be removed). To see what I am talking about, compare these three lines from my log: AppSearch: Property: MYMULTIVALUE, Signature: MyMultiValue MSI (c) (38:98) [09:26:38:902]: PROPERTY CHANGE: Adding MYMULTIVALUE property. Its value is ''. Property(C): MYMULTIVALUE = [~]SysClass.Dll,StorageCoInstaller[~]WmiProp.dll,WmiPropCoInstaller[~] Those are the only references to that property in the entire debug verbose log. You would need some custom action to parse or otherwise escape the property values in the property before using the condition syntax to search them. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Monday, September 14, 2009 8:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value OK based on Pally's earlier post, it would seem that SQLSERVERMSSQLSERVER or the property equivalent should work, but neither works for me. Do they work for anyone else? -Original Message- From:
Re: [WiX-users] Wix 3.0 FileSearch
You will need to calculate/retrieve INSTALLDIR via a custom action you run before AppSearch, or use some directory other than INSTALLDIR for our EXE_EXISTS property. Since you only run that EXE when it was previously present, is that EXE placed there using a previous installer package? Could you use a ComponentSearch to locate the directory (or even the EXE itself)? -Original Message- From: puyo puy [mailto:puyo...@yahoo.com] Sent: Tuesday, September 15, 2009 12:06 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 3.0 FileSearch Hi Blair, Thank you for your help. I checked the log file. AppSearch(property EXE_EXISTS) was set before INSTALLDIR but CA_RunEXE was called after INSTALLDIR set. Execute Sequences: 1. AppSearch property EXE_EXISTS assigned 2. Property INSTALLDIR assigned 2. CA_RunEXE custom action evaluated but not called becase the codition failed. Custom Action=CA_RunEXE After=InstallInitializeEXE_EXISTS/Custom If I execute msiexec with INSTALLDIR parameter e.g.: msiexec /i test.msi /l*vx test.log installdir=C:\Program Files\Company\Product\ my custom action call sucessfully. Can anyone know how to fix this problem? Thanks Jeff --- On Mon, 14/9/09, Blair os...@live.com wrote: From: Blair os...@live.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: 'General discussion for Windows Installer XML toolset.' wix-users@lists.sourceforge.net Received: Monday, 14 September, 2009, 9:17 PM INSTALLDIR may be set before your CA_RunEXE custom action runs (it will be set by the time the standard action CostFinalize runs if it wasn't set explicitly before, because CostFinalize populates all the properties identified in the Directory table) but it may not be set when the standard AppSearch runs, and that was the question Sebastian asked. Can you confirm that INSTALLDIR is set before the AppSearch action runs? Please search a debug verbose log for INSTALLDIR to see when it is first set, and if that is before AppSearch or after. -Original Message- From: puyo puy [mailto:puyo...@yahoo.com] Sent: Monday, September 14, 2009 1:11 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix 3.0 FileSearch Hi, Can someone from WIX confirm that is a bug or I did something wrong. Thanks Jeff --- On Fri, 11/9/09, puyo puy puyo...@yahoo.com wrote: From: puyo puy puyo...@yahoo.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Received: Friday, 11 September, 2009, 9:29 AM Hi Sebastian Thank you for your quick reply. Yes, I'm sure that INSTALLDIR was set before called. I added extract custom action before execute CA_RunEXE to display the property INSTALLDIR to the log file and I can see the value is correct. I copy that value and replaced Path=[INSTALLDIR] to Path=C:\Program Files\Company\Product\ and it works. Function LogMsg Dim rec Set rec = Session.Installer.CreateRecord(1) rec.StringData(0) = Session.Property(INSTALLDIR) LogInfo = Session.Message(H0400, rec) End function I also tried your suggestion to remove @Id from FileSearch but still doesn't works. FileSearch Name=APP.exe / Thanks Jeff --- On Thu, 10/9/09, Sebastian Brand (Instyler Software) wix+us...@instyler.com wrote: From: Sebastian Brand (Instyler Software) wix+us...@instyler.com Subject: Re: [WiX-users] Wix 3.0 FileSearch To: 'General discussion for Windows Installer XML toolset.' wix-users@lists.sourceforge.net Received: Thursday, 10 September, 2009, 6:33 PM Hello, Are you sure the INSTALLDIR property is set already when the FileSearch begins? Also try removing the @Id from the FileSearch, I remember there was an issue with that when trying to get sub-directories. Best regards, Sebastian Brand Instyler Setup - Creating WiX-based MSI installations, elegantly. http://www.instyler.com -Original Message- From: puyo puy [mailto:puyo...@yahoo.com] Sent: Thursday, September 10, 2009 10:31 To: wix users Subject: [WiX-users] Wix 3.0 FileSearch Hi there, I'm trying to create msi installer using wix and this installer will search for old application for current install location. When the old application found, a custom action will execute the old application. I used the following script to search for the old application. Property Id=EXE_EXISTS DirectorySearch Id=CheckInstallDir Path=[INSTALLDIR] Depth=0 FileSearch Id=CheckExeFile Name=APP.exe / /DirectorySearch /Property When the old application found, custom action CA_RunEXE will execute. InstallExecuteSequence Custom Action=CA_RunEXE After=InstallInitializeEXE_EXISTS/Custom /InstallExecuteSequence But according to the msi log, action CA_RunEXE never execute because condition is false even the old application exist. From the log file I see INSTALLDIR
Re: [WiX-users] Component installed even if not part of selected feature
First thing I see is a component rule violation: C1 and C2 have the same keypath (assuming both components are in the same directory). File F1 should be installed by one and only one component (same with every other resource). You will need to fix that somehow, since violations of the component rules, by definition, lead to unexpected and sometimes unexplainable behaviors. -Original Message- From: fiordean dacian [mailto:dfiord...@yahoo.com] Sent: Tuesday, September 15, 2009 7:35 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Component installed even if not part of selected feature Hi, I have something like Component Id=C1 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app1Sc Name=app sc Icon=... IconIndex=.../ Shortcut Id=app1ScRmt Name=appSc Remote Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C2 Guid=... DiskId=1 File Id=F1 Name=app.exe Source=c:\app.exe Shortcut Id=app2Sc Name=app sc Icon=... IconIndex=.../ /File File.../File Registry.../Registry /Component Component Id=C3 Guid=... DiskId=1 File.../File /Component Feature Id=Full Level=1 ComponentRef Id=C2/ ComponentRef Id=C3/ /Feature Feature Id=Partial Level=1/ ComponentRef Id=C1/ /Feature I select Full feature for installation; I know it's correct because C3 component files are installed. But I also get the shortcuts from C1 component created which looks like the C1 is installed as well (basically C1 and C2 differs only by a shortcut as above, the files are exactly the same) even if not part of Full install. I saw someone already had a similar problem but can't seem to find an answer for my problem in the answers he got (I don't plan using conditions) http://sourceforge.net/mailarchive/forum.php?thread_name=45f1db380908240448n 2c4a5594y3a5e9ee8437ee399%40mail.gmail.comforum_name=wix-users Did anyone had a similar problem? Thanks -- 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] Conditional installed based on REG_MULTI_SZ value
I find it weird that the WI would reject VBS but accept a C/C++ dll? There is nothing stopping someone from writing dodgy code in C/C++ and shipping it with an installer. Just because it is compiled it's safer? Out software should be installed by Administrators, so I'm hoping they will allow our VBS scripts, as I don't fancy writing any C/C++ code. If it was C# or Delphi I wouldn't mind. -Original Message- From: Blair [mailto:os...@live.com] Sent: 15 September 2009 16:44 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Make sure it is before LaunchConditions and after AppSearch (you can move either one of those if needed) For example: InstallExecuteSequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallExecuteSequence InstallUISequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallUISequence The usual caveat about VBS (or any other) script CA goes here: they are unreliable (there are anti-virus systems that prevent the script from running and, esp. on Vista, incorrect installations/repairs cause Windows Installer to reject the scripting engine runtime). For reliability, a C/C++ CA statically linked to its runtime is considered best practice. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Tuesday, September 15, 2009 6:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value I'm using v4.5.6001.22159 if that is any help to anyone. Is putting my CustomAction before LaunchConditions the best place to run my vbs, or would there be another more appropriate place? Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 15 September 2009 10:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Blair, Can we attribute this to a bug in WiX 3.0 then? If I need to write a work around, does WiX provide any parsing capabilities, or should I look at using VBScript or similar to get this working? Dominique. -Original Message- From: Blair [mailto:os...@live.com] Sent: 14 September 2009 17:34 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value In my tests using a simple installation package, it would appear that the conditional comparison routines for strings stop looking through the string at the first NUL character. Since REG_MULTI_SZ strings start with a NUL, then terminate each value with an additional NUL (remember that the conditional is evaluated AFTER the string is parsed replacing all [whatever] property references) means that the conditional syntax can't see any values after the first [~] value (which would include all values retrieved using RegistrySearch involving REG_MULTI_SZ strings. You can check for presence of the property, however. (If the property were truly empty, it would be removed). To see what I am talking about, compare these three lines from my log: AppSearch: Property: MYMULTIVALUE, Signature: MyMultiValue MSI (c) (38:98) [09:26:38:902]: PROPERTY CHANGE: Adding MYMULTIVALUE property. Its value is ''. Property(C): MYMULTIVALUE = [~]SysClass.Dll,StorageCoInstaller[~]WmiProp.dll,WmiPropCoInstaller[~] Those are the only references to that property in the entire debug verbose log.
[WiX-users] (no subject)
From time to time I am getting the following dialog during install that never disappears and prevents installation from continuing: Please wait while installer finishes determining your disk space requirements. Return If I cancel the install and then restart it again most likely it will work. What may be going on? Alex -- 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] replacing DialogRef with Dialog is not working
By changing it to 'Order=3' seems to be working. Thanks for the hint. dl Pally Sandher wrote: I'd try changing Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=UserRegistrationDlg Order=2LicenseAccepted = 1/Publish To 'Order=1' as from looking at the WiX v3.0 sources, WiXUI_Mondo.wxs has the following: Publish Dialog=LicenseAgreementDlg Control=Next Event=NewDialog Value=SetupTypeDlg Order=2LicenseAccepted = 1/Publish So it they could be conflicting. Your code looks absolutely fine, other than this nothing jumps out as a possible cause here. If this fixes your issue could you e-mail Gábor DEÁK JAHN (mailto:d...@tramontana.co.hu?subject=wixtutorial) to let him know so he can update the tutorial? Good luck it's good to see people using resources like the tutorial. Keep it up, it doesn't take much to get into WiX but it's very powerful once you know how to use it =) 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: DerekLiang [mailto:derek.liang...@gmail.com] Sent: 14 September 2009 19:18 To: wix-users@lists.sourceforge.net Subject: [WiX-users] replacing DialogRef with Dialog is not working Hi all, I am wondering how to insert a custom dialog into a built-in dialog set in a SINGLE file. Here is what I do. Please let me know what do I do wrong. 1. download the sample zip files, compile, and test successfully. http://www.tramontana.co.hu/wix/download.php?file=samples/samplewixuiadddlg.ziptype=application/zip 2. replaced the DialogRef Id=UserRegistrationDlg / in File SampleWixUIAddDlg.wxs with the content between the UI and /UI tags in UserRegistrationDlg.wxs as the following. 3. compilation is success. However when I try to install the MSI, the UserRegistrationDlg is a not appearing. Is this supposed to work, or there is something else I need to do. Thanks in advance! dl ---content of SampleWixUIAddDlg.wxs ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Name=Foobar 1.0 Id=DF713893-D1DA-4D9D-B58C-1BE2D615E3E9 UpgradeCode=DBE560F6-1832-4F36-9EE0-9F8A31DF9077 Language=1033 Codepage=1252 Version=1.0.0 Manufacturer=Acme Ltd. Package Id=* Keywords=Installer Description=Acme's Foobar 1.0 Installer Comments=Foobar is a registered trademark of Acme Ltd. Manufacturer=Acme Ltd. InstallerVersion=100 Languages=1033 Compressed=yes SummaryCodepage=1252 / Media Id=1 Cabinet=Sample.cab EmbedCab=yes DiskPrompt=CD-ROM #1 / Property Id=DiskPrompt Value=Acme's Foobar 1.0 Installation [1] / Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Name=PFiles Directory Id=Acme Name=Acme Directory Id=INSTALLDIR Name=Foobar 1.0 Component Id=MainExecutable Guid=69A40E29-6F4E-4E45-BA28-E839329C7F00 File Id=FoobarEXE Name=FoobarAppl10.exe DiskId=1 Source=FoobarAppl10.exe KeyPath=yes Shortcut Id=startmenuFoobar10 Directory=ProgramMenuDir Name=Foobar 1.0 WorkingDirectory=INSTALLDIR Icon=Foobar10.exe IconIndex=0 Advertise=yes / Shortcut Id=desktopFoobar10 Directory=DesktopFolder Name=Foobar 1.0 WorkingDirectory=INSTALLDIR Icon=Foobar10.exe IconIndex=0 Advertise=yes / /File /Component Component Id=HelperLibrary Guid=73099C09-DAFF-4A5C-8EDE-A35593418FAA File Id=HelperDLL Name=Helper.dll DiskId=1 Source=Helper.dll KeyPath=yes / /Component Component Id=Manual Guid=43BCCCEA-2D92-4308-AB60-061FFCAEE6EA File Id=Manual Name=Manual.pdf DiskId=1 Source=Manual.pdf KeyPath=yes Shortcut Id=startmenuManual Directory=ProgramMenuDir Name=Instruction Manual Advertise=yes / /File /Component /Directory /Directory /Directory Directory Id=ProgramMenuFolder Name=Programs Directory Id=ProgramMenuDir Name=Foobar 1.0 Component Id=ProgramMenuDir Guid=1E5FF05A-8F12-431E-B180-0FDA9E648D3C RemoveFolder Id=ProgramMenuDir On=uninstall / RegistryValue Root=HKCU Key=Software\[Manufacturer]\[ProductName] Type=string Value= KeyPath=yes / /Component /Directory
Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value
I've not come across the Vista scripting issue that Blair mentioned, but AV programs are always looking for scripts that might be dangerous. In some cases I believe they even intercept calls to the scripting engines. This is typically the reason so many setups ask you to disable AV programs before doing an install. Another common issue I see is that writing VBScript seems to turn off any programming skills the writer may have had. Almost every VBScript I've seen is guilty of abusing On Error Resume Next, of not using explicit declarations, and generally just plowing through without error handling. In addition, it's not the same as Windows Script Host, and that also seems to lead to some confusion. There's no native support for calling C# Dlls from Windows Installer. Various solutions exist, but they all have the characteristic that something has to crank up and host some version of the .NET Framework before it can run your code. Anything that goes wrong in there will require some understanding of that framework hosting mechanism. Calling a Win32 C++ Dll custom action with a fixed signature from some other Win32 code is trivial, and the call from MSI into your function about as simple as a function call can get, and errors are usually obvious. Phil Wilson -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Tuesday, September 15, 2009 9:07 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value I find it weird that the WI would reject VBS but accept a C/C++ dll? There is nothing stopping someone from writing dodgy code in C/C++ and shipping it with an installer. Just because it is compiled it's safer? Out software should be installed by Administrators, so I'm hoping they will allow our VBS scripts, as I don't fancy writing any C/C++ code. If it was C# or Delphi I wouldn't mind. -Original Message- From: Blair [mailto:os...@live.com] Sent: 15 September 2009 16:44 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Make sure it is before LaunchConditions and after AppSearch (you can move either one of those if needed) For example: InstallExecuteSequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallExecuteSequence InstallUISequence AppSearch Before=ParseSqlServerForMSSQL/ Custom Action=ParseSqlServerForMSSQL Before=LaunchConditions/ /InstallUISequence The usual caveat about VBS (or any other) script CA goes here: they are unreliable (there are anti-virus systems that prevent the script from running and, esp. on Vista, incorrect installations/repairs cause Windows Installer to reject the scripting engine runtime). For reliability, a C/C++ CA statically linked to its runtime is considered best practice. -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: Tuesday, September 15, 2009 6:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value I'm using v4.5.6001.22159 if that is any help to anyone. Is putting my CustomAction before LaunchConditions the best place to run my vbs, or would there be another more appropriate place? Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 15 September 2009 10:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value No but you could attribute it to a bug in whichever version of Windows Installer you're using to test the MSI (v3.1 or v4.0 whether you're on XP/2k3 or Vista/2k8 respectively I'm guessing). People on this list really need to learn the difference between WiX Windows Installer. They are *not* the same thing should never be used interchangeably as if far too often the case. You'll have to write your own Custom Action to parse the registry value before you compare it as far as I know. Would be nice if there was some sort of Standard Custom Action in WiX for manipulating regex but then there's already plenty of features which existed in WiX v2.0 which we have to live without in WiX v3.0 so I wouldn't hold my breath. 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: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 15 September 2009 09:42 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on
[WiX-users] launching page localization
On Tue, 15 Sep 2009 19:59:35 +, Lian Jiang wrote: Lian, You probably mean the very first small message about the installation launching. This is displayed by the Windows Installer, not your installer. So, no matter how fully you have localized yours, this message will display in the actual Windows system language your installer is running on. Bye, Gábor --- DEÁK JAHN, Gábor -- Budapest, Hungary E-mail: d...@tramontana.co.hu -- 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] launching page localization
Hi, I localized all strings used in my installer UI. The installer is a MUI based msi which means the same MSI can work on different locale machines and shows the strings in the corresponding locale. All dialogs works fine except that the launching page (the verify first dialog showing something like installation starts ...) shows strings incorrectly. For example, I saw it shows other language when running on an en-us machine and it shows English when running on other locales machine. The launching page shown in en-us locale machine is attached. Thanks for any clue. Thanks Lian -- 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
