[WiX-users] Failed to create web application. (-2147024809)
Hi Team, My MSI creates a virtual directory under a default website and creates a new web application under existing App pool(this case DefaultAppPool). Which is working fine on windows 2003 OS. When I install the same MSI using Microsoft Octopus from Win7 onto windows 2003 server the installer throws below error. [ERROR] ROMDVWEBV01 : Installers\ROMBSCallBack\ROMBSCallBack.msi: Failed to create web application. (-2147024809 /Root/ROMBSCALLBACK ) [ERROR] ROMDVWEBV01 : Installers\ROMBSCallBack\ROMBSCallBack.msi: Error Code 1603: Fatal error during installation. (Exception from HRESULT: 0x80070643) [ERROR] Error occurred. Waiting for all active server executors to finish current task Any help is highly appreciated. Thanks, Sandeep. -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to save project build output in Visual Studio?
We have a WiX project in our VS 2008 solution. I would like to save the project's build output to a file like BuildLog. Any ideas? Regards, Demyn -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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: 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 ** 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] Sen
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
>
> Value="UserRegistrationDlg" Order="2">LicenseAccepted = "1"
>
> To 'Order="1"' as from looking at the WiX v3.0 sources, WiXUI_Mondo.wxs
> has the following:
>
> Value="SetupTypeDlg" Order="2">LicenseAccepted = "1"
>
> 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 **
> 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.zip&type=application/zip
> 2. replaced the in File
> SampleWixUIAddDlg.wxs with the content between the and 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 encoding="utf-8"?> http://schemas.microsoft.com/wix/2006/wi";>
> UpgradeCode="DBE560F6-1832-4F36-9EE0-9F8A31DF9077" Language="1033"
> Codepage="1252" Version="1.0.0" Manufacturer="Acme Ltd.">
> Manufacturer="Acme Ltd." InstallerVersion="100" Languages="1033"
> Compressed="yes" SummaryCodepage="1252" />
> DiskPrompt="CD-ROM #1" />
> />
>
>
>
>
> Guid="69A40E29-6F4E-4E45-BA28-E839329C7F00">
> DiskId="1" Source="FoobarAppl10.exe" KeyPath="yes">
> Directory="ProgramMenuDir" Name="Foobar 1.0" WorkingDirectory="INSTALLDIR"
> Icon="Foobar10.exe" IconIndex="0" Advertise="yes" />
> Directory="DesktopFolder" Name="Foobar 1.0" WorkingDirectory="INSTALLDIR"
> Icon="Foobar10.exe" IconIndex="0" Advertise="yes" />
>
>
> Guid="73099C09-DAFF-4A5C-8EDE-A35593418FAA">
> DiskId="1" Source="Helper.dll" KeyPath="yes" />
>
> Guid="43BCCCEA-2D92-4308-AB60-061FFCAEE6EA">
> Source="Manual.pdf" KeyPath="yes">
> Directory="ProgramMenuDir" Name="Instruction Manual" Advertise="yes" />
>
>
>
>
>
>
>
> Guid="1E5FF05A-8F12-431E-B180-0FDA9E648D3C">
> />
> Key="Software\[Manufacturer]\[ProductName]" Type="string" Value=""
> KeyPath="yes" />
>
>
>
>
>
> ConfigurableDirectory="INSTALLDIR">
>
>
>
>
>
> Description="The instruction manual." Level="1000">
>
>
>
>
>
> Title="[ProductName] [Setup]" NoMinimize="yes">
> Width="100" Height="15" TabSkip="no" Text="&User Name:" />
> Width="220"
> Height="18" Property="USERNAME" Text="{80}" />
> Width="100" Height="15" TabSkip="no" Text="&Organization:" />
> Width="220" Height="18" Property="COMPANYNAME" Text="{80}" />
> Width="50" Height="10" TabSkip="no">
> CD &Key:
>
> Width="250" Height="16" Property="PIDKEY" Text="[PIDTemplate]" />
> Width="56" Height="17" Text="&Back">
> Value="LicenseAgreementDlg">1
>
[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. 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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: 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 ** 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 dis
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 ... ... ... ... ... 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.com&forum_name=wix-users Did anyone had a similar problem? Thanks -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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.
EXE_EXISTS
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 wrote:
From: Blair
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "'General discussion for Windows Installer XML toolset.'"
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 wrote:
From: puyo puy
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "General discussion for Windows Installer XML toolset."
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.
Thanks
Jeff
--- On Thu, 10/9/09, Sebastian Brand (Instyler Software)
wrote:
From: Sebastian Brand (Instyler Software)
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "'General discussion for Windows Installer XML toolset.'"
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.
When the old application found, custom action "CA_RunEXE" will execute.
EXE_EXISTS
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 to ,
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: http://au.overview.mail.yahoo.com/
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: 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 ** 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 SQLSERVER><"MSSQLSERVER" 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 chan
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 wrote: From: Pally Sandher Subject: Re: [WiX-users] Component installed even if not part of selected feature To: "General discussion for Windows Installer XML toolset." 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 ** 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 ... ... ... ... ... 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.com&forum_name=wix-users Did anyone had a similar problem? Thanks -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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" To: "General discussion for Windows Installer XML toolset." 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 ** > 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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 ** 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 ** 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 SQLSERVER><"MSSQLSERVER" or the property equivalent shou
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 ** 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 ... ... ... ... ... 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.com&forum_name=wix-users Did anyone had a similar problem? Thanks -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Component installed even if not part of selected feature
Hi, I have something like ... ... ... ... ... 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.com&forum_name=wix-users Did anyone had a similar problem? Thanks -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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 ** 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 SQLSERVER><"MSSQLSERVER" 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 SQLSERVER><"MSSQLSERVER" 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_MU
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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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" To: "General discussion for Windows Installer XML toolset." 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 ** > 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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 ** 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Come build with us! The BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] replacing DialogRef with Dialog is not working
I'd try changing
LicenseAccepted = "1"
To 'Order="1"' as from looking at the WiX v3.0 sources, WiXUI_Mondo.wxs has the
following:
LicenseAccepted = "1"
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 **
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.zip&type=application/zip
2. replaced the in File
SampleWixUIAddDlg.wxs with the content between the and 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
http://schemas.microsoft.com/wix/2006/wi";>
CD &Key:
1
1
CostingComplete = 1
ProductID
1
Please enter your customer information
{\WixUI_Font_Title}Customer Information
LicenseAccepted =
"1"
1
---end of content of SampleWixUIAddDlg.wxs
Related tutorial can be found at
http://www.tramontana.co.hu/wix/lesson2.php#2.5
--
View this message in context:
http://n2.nabble.com/replacing-DialogRef-with-Dialog-is-not-working-tp3644211p3644211.html
Sent from the wix-users mailing list archive at Nabble.com.
--
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 BlackBerry® Developer Conference in SF, CA
is the only developer event you need to attend this year. Jumpstart your
developing skills, take BlackBerry mobile applications to market and stay
ahead of the curve. Join us from November 9-12, 2009. Register now!
http://p.sf.net/sfu/devconf
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] 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 BlackBerry® Developer Conference in SF, CA is the only developer event you need to attend this year. Jumpstart your developing skills, take BlackBerry mobile applications to market and stay ahead of the curve. Join us from November 9-12, 2009. Register now! http://p.sf.net/sfu/devconf ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] 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 ** 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 SQLSERVER><"MSSQLSERVER" 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 SQLSERVER><"MSSQLSERVER" 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 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. Palbinder Sandher Software Deployment & IT Adm
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 SQLSERVER><"MSSQLSERVER" 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 SQLSERVER><"MSSQLSERVER" 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 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. Palbinder Sandher Software Deployment & IT Administrator T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the ** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Dominique Louis [mailto:dominique.lo...@amxeurope.com] Sent: 14 September 2009 14:23 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value Hi Pally, Thanks for taking the time to answer my query. I should have mentioned that I had already tried putting quotes around MSSQLSERVER, but that does not work either. What I need is some kind of conditional code the does the equivalent of a "Does this SQLSERVER property *contain* MSSQLSERVER" Dominique. -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: 14 September 2009 13:15 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Conditional installed based on REG_MULTI_SZ value That says to throw the condition 'If the Property SQLSERVER does not contain the Property MSSQLSERVER or the product is not already Installed' Try putting quotes around MSSQLSERVER if you want it t
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.
EXE_EXISTS
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 wrote:
From: Blair
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "'General discussion for Windows Installer XML toolset.'"
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 wrote:
From: puyo puy
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "General discussion for Windows Installer XML toolset."
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.
Thanks
Jeff
--- On Thu, 10/9/09, Sebastian Brand (Instyler Software)
wrote:
From: Sebastian Brand (Instyler Software)
Subject: Re: [WiX-users] Wix 3.0 FileSearch
To: "'General discussion for Windows Installer XML toolset.'"
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.
When the old application found, custom action "CA_RunEXE" will execute.
EXE_EXISTS
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 to ,
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: http://au.overview.mail.yahoo.com/
--
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
--
Let Crystal Reports h
