Re: [WiX-users] optionally removing AppData folders created by application, during uninstall
Unfortunately, I think you will have to resort to a Custom Action to get the behavior you want. However, rather than delete files, just add temporary records to RemoveFie table for the appropriate Component to do the removal when you want it done. Using temporary records lets the windows installer handle the execution and rollback for you. Far less code. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Thursday, June 26, 2008 21:11 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] optionally removing AppData folders created by application, during uninstall
I've got most of this custom action already written, but I do the delete directly as I never managed to figure out linking into the RemoveFile table. Not that I put that much effort in, I was pretty wiped out after having to figure a load of C++. Do you have an example of this Rob? If so, I'll update my CA and release the source. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 27 June 2008 07:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders created by application, during uninstall Unfortunately, I think you will have to resort to a Custom Action to get the behavior you want. However, rather than delete files, just add temporary records to RemoveFie table for the appropriate Component to do the removal when you want it done. Using temporary records lets the windows installer handle the execution and rollback for you. Far less code. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Thursday, June 26, 2008 21:11 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users No virus
Re: [WiX-users] Dialog: Set a Property conditionally
Hello, I have a radiobuttongroup (see below) and I would like to set the Property INSTALLTYPE=0 when the RadioButtonGroup is disabled (Condition: NOT (DEVICETYPE = 0 OR DEVICETYPE = 7)). How can I do this? Thank's for the help! Chris Control Id=radioButtonGroupBox1 Type=RadioButtonGroup Height=71 Width=132 X=125 Y=147 Property=INSTALLTYPE RadioButtonGroup Property=INSTALLTYPE RadioButton X=2 Y=2 Height=18 Width=78 Text=new installation Value=0/ RadioButton X=2 Y=18 Height=18 Width=120 Text=restore archive settings Value=1/ RadioButton X=2 Y=34 Height=18 Width=140 Text=update from previous version Value=2/ RadioButton X=2 Y=50 Height=18 Width=120 Text=restore with dump Value=3/ /RadioButtonGroup Condition Action=disable![CDATA[NOT (DEVICETYPE = 0 OR DEVICETYPE = 7)]]/Condition Condition Action=enable![CDATA[(DEVICETYPE = 0 OR DEVICETYPE = 7)]]/Condition /Control - Use the same conditions in a SetProperty element. - Could you send the correct XML to it? I don't know how to do this. Thank you, Chris - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Induce Sleep in the MSI script
I think you'd have to write a custom action. As custom actions go, this would be a very simple one. I tried putting in a custom action that used the cmd.exe sleep command to fix a problem with a service that needed to restart only to discover that not all my deployment targets had the sleep command! I later was able to abandon the sleep as we fixed the fact the service needed to be restarted. I meant a C++ custom action that called the Win32 function Sleep(). That would be very simple - no C runtime library dependencies, no need to worry about rollback, etc. Regards, John - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Realizing a property during a major upgrade
Thanks for the reply, considering we already shipped 1.0.0 I guess we'll look for a workaround... Alex G. On 6/25/08 6:24 PM, Blair Murri [EMAIL PROTECTED] wrote: Properties (including public) are NOT passed to nested installations (including RemoveExistingProducts). Your 1.0.0 installer needs to use the UPGRADINGPRODUCTCODE Property instead of your IS_MAJOR_UPGRADE property for your scenario. See http://msdn.microsoft.com/library/aa372380.aspx for more details on this property. From: [EMAIL PROTECTED] [EMAIL PROTECTED] On Behalf Of Alex Goryuk [EMAIL PROTECTED] Sent: Tuesday, June 24, 2008 10:57 AM To: discussion for Windows Installer XML toolset. Subject: [WiX-users] Realizing a property during a major upgrade Hi, Is it possible to pass PUBLIC properties to products (.MSI) being removed during RemoveExistingProducts (during major upgrade)? My installer 1.0.0 * installs the 1.0.0 product * launches a custom action based on a property IS_MAJOR_UPGRADE My installer 2.0.0 * removes a previous product (1.0.0) - but doesn¹t realize the property IS_MAJOR_UPGRADE * installs the new product, but during ³RemoveExistingProducts² the IS_MAJOR_UPGRADE is not being realized by the v1.0.0 MSI, thus my custom action is not being executed. To prove this I launched the 1.0.0 installer with IS_MAJOR_UPGRADE as a parameter and the custom action executed correctly. So far I¹ve tried: 1) Set a custom action after LaunchConditions that sets IS_MAJOR_UPGRADE=true 2) Pass IS_MAJOR_PROPERTY to installer 2.0.0 hoping that it¹d be realized during the ³RemoveExistingProducts² that removed 1.0.0 3) Setting the UpgradeVersion element¹s property to ³IS_MAJOR_UPGRADE² * in this case IS_MAJOR_PROPERTY is a ³SecureCustomProperty² 4) Set the public property in the Property table. Thanks, Alex G. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to create a shrtcut to a file already present on the disk ?
Hi everyone. I'm starting to use WiX, because we're changing our deployment solution to a MSI-based one. So, I'm starting to recreate our previouses packages. The first i tryed to make has to deploy files (exe) and to create shortcuts on file that are already somewhere on network shares, in AllUsers\Desktop\MyFolder. Here is my wxs file : ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=c77148d4-0e53-4f49-a282-6a743ed4a6dc Name= TestDossierTravail Language=1036 Version=1.0.0.0 Manufacturer=Urssaf de Lyon UpgradeCode=7802d12b-1431-4121-a658-7ce26a9b0f75 Package InstallerVersion=300 Compressed=yes / Media Id=1 Cabinet=TestDossierTravail.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=TravailFolder Name=. Component Id=componentGlobalShortcuts Guid= A9856B1C-D2FD-47c6-9334-2393FB19BDDF Shortcut Id=Myshortcut Name=Shortcut WorkingDirectory= ProgramPath Target=[ProgramPath] Directory =TravailFolder/ File Id=RelanceImpressions Source= \\server\share\folder\anotherexe.exe / /Component /Directory /Directory Property Id=ProgramPath Value=X:\Folder\Prog / Property Id=TravailFolder Value=C:\Documents and settings\All Users\Bureau\Travail\ / Feature Id=featureBasicInscall Title=Basique Level=1 ComponentRef Id=componentGlobalShortcuts / /Feature /Product /Wix When I install this, the file anotherexe.exe is copied into the C:\Documents and settings\All Users\Bureau\Travail\ folder (what is OK). But my shortcut is created into C:\Documents and settings\username\Bureau\Travail\ and not in the All Users\Bureau folder ! I don't understand why, so if anyone has an answer, it would be welcomed ! Thanks for your help Thomas (PS: Sorry for my english, I'm French ;) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] pyro-gen'd MSP brings up MaintenanceDlg
Greetings. I hate to barge in and immediately begin asking questions, but there's been something eluding me that I don't quite understand. I've created a pair of installers according to the instructions I was able to find in the docs for successfully creating patches using pyro (extrapolating, of course, to my full installer rather than a couple of text files). The problem is that if I try to run the generated msp as suggested: msiexec /p patch/patch.msp Windows Installer simply brings up the maintenance dialog for the currently installed version, instead of patching it. Is there something totally obvious that I'm missing here? I've tried running with REINSTALL and REINSTALLMODE variables declared at the command line, but it seems that doing so overrides AllowRemoval=yes and also throws a UAC prompt in Vista, which I'd rather not do. Both MSIs are signed, as is the MSP. Thanks in advance. Word of warning: I'm not a programmer by trade; I started developing our setup packages in WiX because no one else wanted to do it and I didn't like using InstallShield. -- Ryan J. Markel - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Bug in dark.exe?
I will log it as a bug. Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Thursday, June 26, 2008 3:12 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Bug in dark.exe? Sounds like a bug in there somewhere. Can you log it? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mike Rerick Sent: Wednesday, June 25, 2008 16:15 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Bug in dark.exe? I am de-compiling a MSI generated with InstallShield 11.5. I got an error on table CustomAction. I also found this link to the same problem: http://www.nabble.com/--wix-Bugs-1976057---dark-fails-on-Wise-MSI-due-to-Une xpectedColumnCount-td17552116.html When I look at the InstallShield MSI file with Orca, The CustomAction table looks just fine. I was using Wix 3.0.4214 and got the following error (and no .wxs file was generated): C:\Program Files\WixEdit\wix-3.0.4214.0\dark DB.msi DB.wxs -x db Microsoft (R) Windows Installer Xml Decompiler version 3.0.4214.0 Copyright (C) Microsoft Corporation. All rights reserved. DB.msi C:\Program Files\WixEdit\wix-3.0.4214.0\WixDifxAppExtension.dll : error DARK0143 : A parsed tuple has more fields for table 'CustomAction' than are defined. This is potentially because a standard table is being redefined as a custom table. I then tried with Wix 3.0.4014 and got the following (and a .wxs file was generated): C:\Program Files\WixEdit\wix-3.0.4014.0\dark DB.msi DB.wxs -x db Microsoft (R) Windows Installer Xml Decompiler version 3.0.4014.0 Copyright (C) Microsoft Corporation 2003. All rights reserved. DB.msi dark.exe : warning DARK1065 : The AdvtUISequence table is not supported by the W iX toolset because it has been deprecated by the Windows Installer team. Any in formation in this table will be left out of the decompiled output. DB\DB.msi : warning DARK1060 : The ISSQLConnection table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLDBMetaData table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLConnectionDBServer table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLScriptFile table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLConnectionScript table is being decompiled as a custom table. DB\DB.msi : warning DARK1060 : The ISSQLScriptReplace table is being decompiled as a custom table. DB\DB.msi : warning DARK1062 : The ModuleComponents table can only be represented in WiX for merge modules. Th e information in this table will be left out of the decompiled output. DB.msi : warning DARK1066 : The Patch table is not directly supported by the WiX toolset because it belongs in a patch (msp) file. This table can be indirectly created by making a patch c reation (pcp) file using WiX, then using PatchWiz to create a patch (msp) file. Any information in this table will be left out of the decompiled output. DB\DB.msi : warning DARK1066 : The PatchPackage table is not directly supported by the WiX toolset because it b elongs in a patch (msp) file. This table can be indirectly created by making a patch creation (pcp) file using WiX, then using PatchWiz to create a patch (msp) file. Any information in this table will be left out of the decompiled output. dark.exe : warning DARK1058 : The AdminExecuteSequence table contains an action 'ScheduleReboot' which is not allowed in this table. If this is a standard acti on then it is not valid for this table, if it is a custom action or dialog then this table does not accept actions of that type. This action will be left out o f the decompiled output. dark.exe : warning DARK1058 : The AdvtExecuteSequence table contains an action ' RegisterTypeLibraries' which is not allowed in this table. If this is a standar d action then it is not valid for this table, if it is a custom action or dialog then this table does not accept actions of that type. This action will be left out of the decompiled output. dark.exe : warning DARK1058 : The AdvtExecuteSequence table contains an action ' ScheduleReboot' which is not allowed in this table. If this is a standard actio n then it is not valid for this table, if it is a custom action or dialog then t his table does not accept actions of that type. This action will be left out of the decompiled output. Mike Rerick Sr. Software Engineer - Professional Services blocked::http://www.iwsinc.com/ 9200 S.E. Sunnybrook Blvd., Suite 170 Clackamas, OR 97015 Phone: (503) 353-8068Fax: (503) 353-8065 The information contained in this transmission contains potentially privileged, export controlled and/or confidential information of Imageware Systems, Inc. or its
Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall
This suggestion touches the question I was thinking to ask for a long time: I want to perform file/registry key/etc. copy/removal at various times during install. I would prefer to use standard actions for that to gain automatic rollback. So I have to schedule standard actions to run multiple times and each time work on a different set of items. However, these items (say files if file operation) are all in the same table. I was hoping that the combination of conditions and adding temporary records can help in selecting subsets from a set of items to be acted upon by the currently scheduled standard action. Can we also remove records from the table at runtime? Are there any other recommendations/best practices/ experiences on how to use standard action in a more granular/controlled way? *That* is the best way IMO to minimize uncontrollable effects of custom actions. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 2:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall Unfortunately, I think you will have to resort to a Custom Action to get the behavior you want. However, rather than delete files, just add temporary records to RemoveFie table for the appropriate Component to do the removal when you want it done. Using temporary records lets the windows installer handle the execution and rollback for you. Far less code. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Thursday, June 26, 2008 21:11 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php
[WiX-users] LGHT0217 VSTS
If I run a build through the VS IDE on the build machine, everything works like a champ. When I run the build through Visual Studio Team Suite, Team Build, I get the below errors... I followed the link and information in the URL listed in the error message, everything checks out. [But I'm also not getting the error 2738 that folks are referencing]. Any thoughts on how I can resolve this (aside from disabling validations)? [Incidentally, the domain account used for the build service is part of the administrators group on the build machine. The build machine is Windows 2008 Server, with UAC turned off] Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM07'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM08'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for
Re: [WiX-users] optionally removing AppData folders created by application, during uninstall
1. There is a WcaAddTempRecord(). That will do most of the work. 2. netshortcuts.cpp uses it for CreateFolder, that's pretty similar. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ryan O'Neill Sent: Friday, June 27, 2008 00:39 To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] optionally removing AppData folders created by application, during uninstall I've got most of this custom action already written, but I do the delete directly as I never managed to figure out linking into the RemoveFile table. Not that I put that much effort in, I was pretty wiped out after having to figure a load of C++. Do you have an example of this Rob? If so, I'll update my CA and release the source. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: 27 June 2008 07:41 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders created by application, during uninstall Unfortunately, I think you will have to resort to a Custom Action to get the behavior you want. However, rather than delete files, just add temporary records to RemoveFie table for the appropriate Component to do the removal when you want it done. Using temporary records lets the windows installer handle the execution and rollback for you. Far less code. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Thursday, June 26, 2008 21:11 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up this sort of behaviour? Thank you in advance... Adam Langley Senior Developer Tel: +64 9 486 9010 - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] How to create a shrtcut to a file already present on the disk ?
I encourage you to read through the Directories topic in MSI and take a look at the examples in WiX.chm. Using Properties that way is very non-conventional. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of THOMAS VAILLIER Sent: Friday, June 27, 2008 06:40 To: wix-users Subject: [WiX-users] How to create a shrtcut to a file already present on the disk ? Hi everyone. I'm starting to use WiX, because we're changing our deployment solution to a MSI-based one. So, I'm starting to recreate our previouses packages. The first i tryed to make has to deploy files (exe) and to create shortcuts on file that are already somewhere on network shares, in AllUsers\Desktop\MyFolder. Here is my wxs file : ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Product Id=c77148d4-0e53-4f49-a282-6a743ed4a6dc Name= TestDossierTravail Language=1036 Version=1.0.0.0 Manufacturer=Urssaf de Lyon UpgradeCode=7802d12b-1431-4121-a658-7ce26a9b0f75 Package InstallerVersion=300 Compressed=yes / Media Id=1 Cabinet=TestDossierTravail.cab EmbedCab=yes / Directory Id=TARGETDIR Name=SourceDir Directory Id=TravailFolder Name=. Component Id=componentGlobalShortcuts Guid= A9856B1C-D2FD-47c6-9334-2393FB19BDDF Shortcut Id=Myshortcut Name=Shortcut WorkingDirectory= ProgramPath Target=[ProgramPath] Directory =TravailFolder/ File Id=RelanceImpressions Source= \\server\share\folder\anotherexe.exe / /Component /Directory /Directory Property Id=ProgramPath Value=X:\Folder\Prog / Property Id=TravailFolder Value=C:\Documents and settings\All Users\Bureau\Travail\ / Feature Id=featureBasicInscall Title=Basique Level=1 ComponentRef Id=componentGlobalShortcuts / /Feature /Product /Wix When I install this, the file anotherexe.exe is copied into the C:\Documents and settings\All Users\Bureau\Travail\ folder (what is OK). But my shortcut is created into C:\Documents and settings\username\Bureau\Travail\ and not in the All Users\Bureau folder ! I don't understand why, so if anyone has an answer, it would be welcomed ! Thanks for your help Thomas (PS: Sorry for my english, I'm French ;) - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall
Windows Installer doesn't work that way. It executes all of the rows in a particular table in bulk. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Tony Juricic Sent: Friday, June 27, 2008 08:45 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall This suggestion touches the question I was thinking to ask for a long time: I want to perform file/registry key/etc. copy/removal at various times during install. I would prefer to use standard actions for that to gain automatic rollback. So I have to schedule standard actions to run multiple times and each time work on a different set of items. However, these items (say files if file operation) are all in the same table. I was hoping that the combination of conditions and adding temporary records can help in selecting subsets from a set of items to be acted upon by the currently scheduled standard action. Can we also remove records from the table at runtime? Are there any other recommendations/best practices/ experiences on how to use standard action in a more granular/controlled way? *That* is the best way IMO to minimize uncontrollable effects of custom actions. -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Friday, June 27, 2008 2:41 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] optionally removing AppData folders createdby application, during uninstall Unfortunately, I think you will have to resort to a Custom Action to get the behavior you want. However, rather than delete files, just add temporary records to RemoveFie table for the appropriate Component to do the removal when you want it done. Using temporary records lets the windows installer handle the execution and rollback for you. Far less code. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Adam Langley Sent: Thursday, June 26, 2008 21:11 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] optionally removing AppData folders created by application, during uninstall Hi guys, I have been battling with this problem for a while. I have a .Net application which saves temporary data into AppData\Roaming\Bookmarks. This folder should not HAVE to be installed by the MSI as the app will create it when needed (but I've gotten to the stage of experimentation where it seems to be easier if it is created by the MSI - the installer seems to not want to remove folders it didn't create, no matter what I do). I want this folder (and all its contents) to be removed at uninstall if REMOVEBOOKMARKS=1 (I have created a custom dialog with a checkbox that lets the user selected during uninstall whether or not to delete these temporary files). If REMOVEBOOKMARKS=0, then I don't want to delete the folder (or its contents), allowing any later installations to pick up these files... My WiX looks something like this: Property Id=REMOVEBOOKMARKS Value=0/ Directory Id=AppDataFolder Directory Id=MyApp Name=MyApp Component Id=RemoveAppData Guid=8C857E65-5EA2-4b0e-BCDA-334F030B1E4A ConditionREMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\1 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / RemoveFolder Id=RemoveAppData On=uninstall / RemoveFile Id=RemoveAppDataFiles Name=* On=uninstall/ /Component Directory Id=Bookmarks Name=Bookmarks Component Id=AddAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86456 Permanent=yes ConditionNOT Installed/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey CreateFolder / /Component Component Id=RemoveAppDataBookmarks Guid=3494B400-3193-4226-878C-2A4EB1B86455 ConditionInstalled AND REMOVEBOOKMARKS = 1/Condition RegistryKey Root=HKCU Key=Software\MyApp\Uninstall\3 RegistryValue Value=MyApp Type=string KeyPath=yes / /RegistryKey !--CreateFolder /-- RemoveFolder Id=RemoveAppDataBookmarks On=uninstall/ RemoveFile Id=RemoveAppDataBookmarksFiles Name=* On=uninstall/ /Component /Directory /Directory /Directory The Bookrmarks folder is the one I want to stay behind if REMOVEBOOKMARKS=0. It seems, no matter what I do, I can't get it to work. If I specify Permanent on the AddAppDataBookmarks component, the NOTHING will remove it. If I DONT specify it, then no matter what I put in the component conditions, it will ALWAYS be removed... How do I set up
Re: [WiX-users] LGHT0217 VSTS
Try the following two blog entries: http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga Sent: Friday, June 27, 2008 10:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT0217 VSTS If I run a build through the VS IDE on the build machine, everything works like a champ. When I run the build through Visual Studio Team Suite, Team Build, I get the below errors... I followed the link and information in the URL listed in the error message, everything checks out. [But I'm also not getting the error 2738 that folks are referencing]. Any thoughts on how I can resolve this (aside from disabling validations)? [Incidentally, the domain account used for the build service is part of the administrators group on the build machine. The build machine is Windows 2008 Server, with UAC turned off] Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM07'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was
Re: [WiX-users] LGHT0217 VSTS
Oh, wait, that's the same blog entries referenced by the FAQ item you said you read and followed below :) Never mind me... it's Friday morning. Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Neil Enns Sent: Friday, June 27, 2008 10:17 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT0217 VSTS Try the following two blog entries: http://blogs.msdn.com/heaths/archive/2007/05/31/windows-installer-errors-2738-and-2739-with-script-custom-actions.aspx http://blogs.msdn.com/astebner/archive/2007/06/07/3151752.aspx Neil -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Nannenga Sent: Friday, June 27, 2008 10:12 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] LGHT0217 VSTS If I run a build through the VS IDE on the build machine, everything works like a champ. When I run the build through Visual Studio Team Suite, Team Build, I get the below errors... I followed the link and information in the URL listed in the error message, everything checks out. [But I'm also not getting the error 2738 that folks are referencing]. Any thoughts on how I can resolve this (aside from disabling validations)? [Incidentally, the domain account used for the build service is part of the administrators group on the build machine. The build machine is Windows 2008 Server, with UAC turned off] Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if
Re: [WiX-users] LGHT0217 VSTS
Hey John, Out of curiosity, do you get similar errors on a previous build? I am curious to see if this is native to the new change or this is going to fail in the past as well. Thanks, -- Brian Rogers Intelligence removes complexity. - Me http://www.codeplex.com/wixml/ On Fri, Jun 27, 2008 at 10:12 AM, John Nannenga [EMAIL PROTECTED] wrote: If I run a build through the VS IDE on the build machine, everything works like a champ. When I run the build through Visual Studio Team Suite, Team Build, I get the below errors... I followed the link and information in the URL listed in the error message, everything checks out. [But I'm also not getting the error 2738 that folks are referencing]. Any thoughts on how I can resolve this (aside from disabling validations)? [Incidentally, the domain account used for the build service is part of the administrators group on the build machine. The build machine is Windows 2008 Server, with UAC turned off] Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM06'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM07'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service
Re: [WiX-users] LGHT0217 VSTS
I received the following error reported on build 3.0.4214.0 (I think it is the same issue, except this build of WiX didn't report all the individual ICE action failures) Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4214.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: An unexpected external UI message was received: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance. The command exited with code 217. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Rogers Sent: Friday, June 27, 2008 12:25 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] LGHT0217 VSTS Hey John, Out of curiosity, do you get similar errors on a previous build? I am curious to see if this is native to the new change or this is going to fail in the past as well. Thanks, -- Brian Rogers Intelligence removes complexity. - Me http://www.codeplex.com/wixml/ On Fri, Jun 27, 2008 at 10:12 AM, John Nannenga [EMAIL PROTECTED] wrote: If I run a build through the VS IDE on the build machine, everything works like a champ. When I run the build through Visual Studio Team Suite, Team Build, I get the below errors... I followed the link and information in the URL listed in the error message, everything checks out. [But I'm also not getting the error 2738 that folks are referencing]. Any thoughts on how I can resolve this (aside from disabling validations)? [Incidentally, the domain account used for the build service is part of the administrators group on the build machine. The build machine is Windows 2008 Server, with UAC turned off] Task Light Command: C:\Program Files\Windows Installer XML v3\bin\Light.exe -sw1076 -loc ..\..\..\Strings\Common_ENG.wxl -loc Ddapi.wxl -out C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.msm -pdbout C:\Users\fgoinsbs\AppData\Local\Temp\MBS Install\Dex v11.0\Binaries\Mixed Platforms\Release\Microsoft_Dexterity11_VC80_DDAPI_x64.wixpdb obj\x64\Release\DdapiMergeModule.wixobj Microsoft (R) Windows Installer Xml Linker version 3.0.4227.0 Copyright (C) Microsoft Corporation. All rights reserved. light.exe : error LGHT0217: Error executing ICE action 'ICEM01'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM02'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM03'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM04'. The most common cause of this kind of ICE failure is an incorrectly registered scripting engine. See http://wix.sourceforge.net/faq.html#Error217 for details and how to solve this problem. The following string format was not expected by the external UI message logger: The Windows Installer Service could not be accessed. This can occur if the Windows Installer is not correctly installed. Contact your support personnel for assistance.. light.exe : error LGHT0217: Error executing ICE action 'ICEM05'. The most common cause of this
[WiX-users] Warning CNDL1044 - How to get rid of this?
Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Copying all files in a directory recursively
We should probably add this to the FAQ. Windows Installer doesn't have such functionality and we don't have a standard custom action in WiX to do it. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nilkund Aseef Sent: Friday, June 27, 2008 10:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Copying all files in a directory recursively Hello, I was wondering if there is a way in WIX to copy all files in a directory ( with several subdirectories and files). I tried using copyfile element, but it only seems to copy all the files at the top level. The files under the subdirectories were not copied. This is the syntax I use in my wxs files Property Id=SOURCE$(var.SamplesSourcePath)/Property CopyFile Id=Foo SourceName=* SourceProperty=SOURCE DestinationDirectory=Workflow / RemoveFolder Id=Workflow On=uninstall / I would really appreciate if someone can give me pointers on how this can be achieved. Thanks! Aseef. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Mathur, Uttam (GTS) wrote: Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? In vim: %s/ ShortName='[^']\+'//g - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
No, why would we remove the warning? You're doing a dangerous thing, the compiler is trying to help you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list
[WiX-users] removing registry key entries on uninstall from HKCU for all users
Hey all, I'm trying to remove registry keys from the HKCU root for each user. The application is being installed for all users, however I wanted the registry settings to be independent of each user, which is why I set it in HKCU instead of HKLM. Now I want to remove the keys on uninstall, any ideas on how I would go about doing this? The manual said using KeyPath=yes would set this key for all users (and I was hoping it would remove as well) if HKCU was the root, but candle gives me the error: error CNDL0038 : The Registry/@Name attribute cannot be specified when attribute Action is present with value 'removeKeyOnUninstall'. For the entry: Registry Root=HKCU Key=Software\MyKey Action= createKeyAndRemoveKeyOnUninstall KeyPath=yes / Any Ideas? Thanks! Mike - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Sorry Luke, but I will be using the VIM for first time. So, how to execute this command? Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Bakken Sent: Friday, June 27, 2008 2:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Mathur, Uttam (GTS) wrote: Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? In vim: %s/ ShortName='[^']\+'//g - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Yes. Dark is trying to preserve what is in your MSI as exactly as it can. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 12:30 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Ok, got it. Then why Dark.exe generate this short file name in the project file? If we remove this data in the MSI, will dark.exe not generate it? Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 3:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? No, why would we remove the warning? You're doing a dangerous thing, the compiler is trying to help you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net
Re: [WiX-users] removing registry key entries on uninstall from HKCU for all users
It is not possible to do this 100% on Windows (due to the way that roaming profiles work). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micheal Wu Sent: Friday, June 27, 2008 12:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] removing registry key entries on uninstall from HKCU for all users Hey all, I'm trying to remove registry keys from the HKCU root for each user. The application is being installed for all users, however I wanted the registry settings to be independent of each user, which is why I set it in HKCU instead of HKLM. Now I want to remove the keys on uninstall, any ideas on how I would go about doing this? The manual said using KeyPath=yes would set this key for all users (and I was hoping it would remove as well) if HKCU was the root, but candle gives me the error: error CNDL0038 : The Registry/@Name attribute cannot be specified when attribute Action is present with value 'removeKeyOnUninstall'. For the entry: Registry Root=HKCU Key=Software\MyKey Action= createKeyAndRemoveKeyOnUninstall KeyPath=yes / Any Ideas? Thanks! Mike - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Preprocessor ifdef did odd thing
Attempts to reproduce the problem failed, the problem changed to simply not recompiling the source file in the new project.. I fixed that by specifying different obj dirs for each project. And I say, Wow sourceforge hasn't been updated with a new build for over a year... http://sourceforge.net/project/showfiles.php?group_id=105970package_id=16 I read the News of January 11, 2008... but seriously, if you guys are going to be lazy about updating sourceforge, for over a year, and then you go asking for feedback on all these bug fixes... If you are serious about wanting feedback you should just replace the stale download link for 3.0 (beta) with a link to the weeklies. Scott On Wed, Jun 25, 2008 at 12:05 PM, Rob Mensching [EMAIL PROTECTED] wrote: Wow, 3.0.2925.0 is a year old. There are hundreds of bug fixes and changes since then. Hmm, there have been some fixes to preprocessor recently to correctly handle relative paths when include files included include files and something to fix ?ifdef? (but I think that was a regression). After that, I'm really at a loss... I know that there have been reports of issues in VS2005 but Jason has been fixing a lot of them. He's also not having much luck getting repros of some issues people have reported. Maybe if you can help work out the VS2005 issues in the latest WiX v3 builds then we can track down the preprocessor issue (assuming it still exists) at the same time? Also, for everyone's benefit, this is why I always encourage anyone who is going to adopt the in progress WiX toolset (WiX v3 in this case) to keep up to date (at least monthly). If you get too far behind and hit a bug then you can get trapped in a difficult position. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Wednesday, June 25, 2008 06:21 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Preprocessor ifdef did odd thing I have a product that can be built two ways. I have two WiX installer projects in visual studio, sharing many of the same wxs files. One project defines a variable in the project settings to cause some of the .wxs files to compile differently, like this: ... Component Id=someFiles Guid=8909196A-8C89-497c-A850-868D7648F063 File Id=file1 Source=..\..\SharedFiles\File1.exe KeyPath=yes Name=File1.exe /File ?ifdef IsVersionA ? File Id=File2 Source=..\..\SharedFiles\File2_A.txt Name=File2.txt/ ?else? File Id=File2 Source=..\..\SharedFiles\File2.txt Name=File2.txt/ ?endif? File Id=File3 Source=..\..\SharedFiles\File3.txt Name=File3.txt/ /Component Directory Id=ConfDir Name=conf Component Id=configFiles Guid=936B3B83-AF5D-47ba-9985-3B4D22E6353B ?ifdef IsVersionA ? File Id=ConfigFile Source=..\..\SharedFiles\conf\server-A.conf Name=server.conf/ ?else? File Id=ConfigFile Source=..\..\SharedFiles\conf\server.conf Name=server.conf/ ?endif? File Id=otherConfig Source=..\..\SharedFiles\etc\ Name=server-password.conf/ /Component /Directory ... When my project built with IsVersionA=true defined in the project settings File2.txt in the msi was a copy of File2_A.txt but server.conf was a copy of ..\..\SharedFiles\conf\server.conf NOT the expected ..\..\SharedFiles\conf\server-A.conf When investigating I manually rebuilt only this project from the solution (after shuffling some lines around to make File Id=otherConfig the key file of Component Id=configFiles) both files were correct. Note that there is another project in the solution that shares this same .wxs file and does not define the IsVersionA variable. I thought at the least that if for some reason the .wxs wasn't being recompiled properly between project builds when I built the solution (doing a rebuild) that the results would be consistent within the single .wxs. They clearly were not - QA reported the file inconsistency. I double checked to confirm the problem by using orca to check the file sizes in the .msi. Then I double checked the preprocessor conditions in the .wxs source file. It was somewhat baffeling. I'm using an older build of WiX 3 (3.0.2925.0) because the recent builds don't work well with Visual Studio 2005. Of course we are noticing this now only a day or two away from when we need to release the production build... argh! Can anyone shed some light (hey that's almost a pun) on what might be going on and how I might deal with it in a reliable way. Getting inconsistent output from your build tools isn't a good thing. Thanks, Scott - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users
Re: [WiX-users] removing registry key entries on uninstall from HKCU for all users
You can try using Active setup here which can do this task when user logs into the box. But that will be pain and it's better to leave them there. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 4:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] removing registry key entries on uninstall from HKCU for all users It is not possible to do this 100% on Windows (due to the way that roaming profiles work). -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Micheal Wu Sent: Friday, June 27, 2008 12:24 To: wix-users@lists.sourceforge.net Subject: [WiX-users] removing registry key entries on uninstall from HKCU for all users Hey all, I'm trying to remove registry keys from the HKCU root for each user. The application is being installed for all users, however I wanted the registry settings to be independent of each user, which is why I set it in HKCU instead of HKLM. Now I want to remove the keys on uninstall, any ideas on how I would go about doing this? The manual said using KeyPath=yes would set this key for all users (and I was hoping it would remove as well) if HKCU was the root, but candle gives me the error: error CNDL0038 : The Registry/@Name attribute cannot be specified when attribute Action is present with value 'removeKeyOnUninstall'. For the entry: Registry Root=HKCU Key=Software\MyKey Action= createKeyAndRemoveKeyOnUninstall KeyPath=yes / Any Ideas? Thanks! Mike - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
IMO the danger is being overestimated. Windows isn't that dumb. It doesn't care if all your MSI short names are Something~1 (or any other name for that matter) because it ignores them. It's easy to demonstrate that every time Windows sees a short name that conflicts with one already in the destination directory it will create a new one when the file is added to the directory. A The warning implies that you cannot safely install these MSI file table entries: SOMELO~1.EXE|somelongfile4name.exe SOMELO~1.EXE|somelongfile3name.exe SOMELO~1.EXE|somelongfile2name.exe SOMELO~1.EXE|somelongfile1name.exe SOMELO~1.EXE|somelongfile5name.exe Into a folder which already has Somelongfile6name.exe Somelongfile7name.exe Somelongfile8name.exe Somelongfile9name.exe Somelongfile10name.exe Which all have some unpredictable long names, including SOMELO~1.EXE and SOMELO~2.EXE. In reality the install works fine. Calling the GetShortPath API confirms that none of the short names in the MSI file table are relevant. The only caveat I can think of is the (mythical?) OS that doesn't do long names, and I'm pretty sure there are none of those around any more, so I've never tested this on a SFN-only system. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 12:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? No, why would we remove the warning? You're doing a dangerous thing, the compiler is trying to help you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
I propose that we switch to PowerShell for all automation tips. Unfortunately, I don't have the equivalent PowerShell command handy. It's a shame Jeffrey Snover doesn't lurk here. :D Joel Peterson [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 12:30 PM To: [EMAIL PROTECTED]; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Sorry Luke, but I will be using the VIM for first time. So, how to execute this command? Thanks -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Bakken Sent: Friday, June 27, 2008 2:48 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Mathur, Uttam (GTS) wrote: Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? In vim: %s/ ShortName='[^']\+'//g -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:19 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do by passing it to Candle.exe from command prompt). TIA, Uttam This message w/attachments (message) may be privileged, confidential or proprietary, and if you are not an intended recipient, please notify the sender, do not use or share it and delete it. Unless specifically indicated, this message is not an offer to sell or a solicitation of any investment products or other financial product or service, an official confirmation of any transaction, or an official statement of Merrill Lynch. Subject to applicable law, Merrill Lynch may monitor, review and retain e-communications (EC) traveling through its networks/systems. The laws of the country of each sender/recipient may impact the handling of EC, and EC may be archived, supervised and produced in countries other than the country in which you are located. This message cannot be guaranteed to be secure or error-free. This message is subject to terms available at the following link: http://www.ml.com/e-communications_terms/. By messaging with Merrill Lynch you consent to the foregoing. - Check out the new SourceForge.net Marketplace. It's the best
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Joel Peterson wrote: I propose that we switch to PowerShell for all automation tips. Unfortunately, I don't have the equivalent PowerShell command handy. That sounds like using a hammer for what is just a simple task with regexes and a competent text editor - I suggested vim because I find it to be the most competent :-). The original poster contacted me and I gave him the following instructions for doing the find/replace with regexes in VS 2008. Hopefully someone on the list or searching the archives will find this useful. Open up the WiX file in VS 2008 with all the ShortNames in it. Go to Edit - Find and Replace - Replace in Files Change Look in to Current Document Expand Find Options, check the box next to Use and choose Regular Expressions from the drop down list. In the Find What box, type ShortName=['][^']+['] You want to have a single space character before ShortName because I'm assuming that all of your ShortName attributes have this space before them. That regular expression literally means: Match the string ShortName=, then either a quote or double quote, followed by one or more characters that are NOT (^) a quote or double quote, followed by a quote or double quote. Leave the Replace with box empty. To test the search, click Find Next and you should see your ShortName attributes and their contents become highlighted. If you're satisfied, click Replace All and all of your ShortName attributes will be gone. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
Sure sure, and thanks for the tip. I was joking, though. Sorta. Joel Peterson [EMAIL PROTECTED] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Luke Bakken Sent: Friday, June 27, 2008 2:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Joel Peterson wrote: I propose that we switch to PowerShell for all automation tips. Unfortunately, I don't have the equivalent PowerShell command handy. That sounds like using a hammer for what is just a simple task with regexes and a competent text editor - I suggested vim because I find it to be the most competent :-). The original poster contacted me and I gave him the following instructions for doing the find/replace with regexes in VS 2008. Hopefully someone on the list or searching the archives will find this useful. Open up the WiX file in VS 2008 with all the ShortNames in it. Go to Edit - Find and Replace - Replace in Files Change Look in to Current Document Expand Find Options, check the box next to Use and choose Regular Expressions from the drop down list. In the Find What box, type ShortName=['][^']+['] You want to have a single space character before ShortName because I'm assuming that all of your ShortName attributes have this space before them. That regular expression literally means: Match the string ShortName=, then either a quote or double quote, followed by one or more characters that are NOT (^) a quote or double quote, followed by a quote or double quote. Leave the Replace with box empty. To test the search, click Find Next and you should see your ShortName attributes and their contents become highlighted. If you're satisfied, click Replace All and all of your ShortName attributes will be gone. - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] WIX version 3.0 errors
Hi, I started to use WIX 3.0 and found link errors. Wonder if anybody may help me what I need to do to modify my wxs file to satisfy WIX 3.0 linker. In my wxs file I wrote as this: Directory Id=SUBDIR41 ShortName=subDIR41 Name=vcmake Directory Id=SUBDIR61 ShortName=subDIR61 Name=msrtaudio16bit Component Id=audsln Guid=BD4C63A3-A4E1-4691-BFCE-E97570D94D3F DiskId=1 Win64=$(var.Win64) File Id=ad16sln1 ShortName = adio16b1.sln Name=msrtaudio16bit_2005.sln Source=$(env._LCSROOT)\dev\media\stream\audio\codecs\RTAudio_PK\vcmake\msrtaudio16bit\msrtaudio16bit_2005.sln DiskId='1' / /Component But the link gave me following errors: msrtaudio16b.wxs(64) : error LGHT0204 : ICE38: Component audsln installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. msrtaudio16b.wxs(63) : error LGHT0204 : ICE64: The directory SUBDIR61 is in the user profile but is not listed in the RemoveFile table. Thanks Xiaoqin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
You know, I'd agree with you *except* that the warning was added after Office ran into a bug that took them a long time to track down because the short name in the MSI matched a short name of a file that already existed on the machine. Maybe admin images? I don't remember the specifics but I remember being surprised when it happened (and was happy to have Derek, who was in Office at the time and still quite upset about never getting those lost days back in his life, add the warning). We don't just make this stuff up you know. smile/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Wilson, Phil Sent: Friday, June 27, 2008 14:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? IMO the danger is being overestimated. Windows isn't that dumb. It doesn't care if all your MSI short names are Something~1 (or any other name for that matter) because it ignores them. It's easy to demonstrate that every time Windows sees a short name that conflicts with one already in the destination directory it will create a new one when the file is added to the directory. A The warning implies that you cannot safely install these MSI file table entries: SOMELO~1.EXE|somelongfile4name.exe SOMELO~1.EXE|somelongfile3name.exe SOMELO~1.EXE|somelongfile2name.exe SOMELO~1.EXE|somelongfile1name.exe SOMELO~1.EXE|somelongfile5name.exe Into a folder which already has Somelongfile6name.exe Somelongfile7name.exe Somelongfile8name.exe Somelongfile9name.exe Somelongfile10name.exe Which all have some unpredictable long names, including SOMELO~1.EXE and SOMELO~2.EXE. In reality the install works fine. Calling the GetShortPath API confirms that none of the short names in the MSI file table are relevant. The only caveat I can think of is the (mythical?) OS that doesn't do long names, and I'm pretty sure there are none of those around any more, so I've never tested this on a SFN-only system. Phil Wilson -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 12:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? No, why would we remove the warning? You're doing a dangerous thing, the compiler is trying to help you. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:19 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:11 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? The easiest fix is to remove the ShortName attribute. The WiX toolset will generate a stable identifier that doesn't have the ambiguity problem. PS: Is there some way to improve the error message? It's basically telling you that you need change the short name since it could collide with other files already on the system. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 11:09 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? I am using Wix toolkit 3.0.4220.0. Thanks. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Rob Mensching Sent: Friday, June 27, 2008 2:07 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Warning CNDL1044 - How to get rid of this? What version of the WiX toolset are you using? -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Mathur, Uttam (GTS) Sent: Friday, June 27, 2008 10:47 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Warning CNDL1044 - How to get rid of this? Hello, I am constantly receiving this warning upon building the WIX project file: Warning CNDL1044: The File/@ShortName attribute's value 'PERFOR~1.XML' is an ambiguous short name because it ends with a '~' character followed by a number. Under some circumstances, this name could resolve to more than one file or directory name and lead to unpredictable results (for example 'MICROS~1' may correspond to 'Microsoft Shared' or 'Microsoft Foo' or literally 'Micros~1'). Please can someone suggest, how to get rid of this warning CNDL1044? Fyi, I am compiling from Visual Studio 2008 and I don't know how to suppress this warning (like we can do
Re: [WiX-users] Preprocessor ifdef did odd thing
You know, I was going to do just that (create a link in the Releases to the weekly builds) and then we had a guy say he was interested in doing the release management. Honestly, I hadn't thought of the link in the Releases on the weekly build until someone else suggested it a month or so ago. Anyway, good feedback all the way around. Hopefully there will be a newer build on the Releases page soon and hopefully people will keep updating from the weekly releases often to help us nail down WiX v3. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Friday, June 27, 2008 13:56 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Preprocessor ifdef did odd thing Attempts to reproduce the problem failed, the problem changed to simply not recompiling the source file in the new project.. I fixed that by specifying different obj dirs for each project. And I say, Wow sourceforge hasn't been updated with a new build for over a year... http://sourceforge.net/project/showfiles.php?group_id=105970package_id=16 I read the News of January 11, 2008... but seriously, if you guys are going to be lazy about updating sourceforge, for over a year, and then you go asking for feedback on all these bug fixes... If you are serious about wanting feedback you should just replace the stale download link for 3.0 (beta) with a link to the weeklies. Scott On Wed, Jun 25, 2008 at 12:05 PM, Rob Mensching [EMAIL PROTECTED] wrote: Wow, 3.0.2925.0 is a year old. There are hundreds of bug fixes and changes since then. Hmm, there have been some fixes to preprocessor recently to correctly handle relative paths when include files included include files and something to fix ?ifdef? (but I think that was a regression). After that, I'm really at a loss... I know that there have been reports of issues in VS2005 but Jason has been fixing a lot of them. He's also not having much luck getting repros of some issues people have reported. Maybe if you can help work out the VS2005 issues in the latest WiX v3 builds then we can track down the preprocessor issue (assuming it still exists) at the same time? Also, for everyone's benefit, this is why I always encourage anyone who is going to adopt the in progress WiX toolset (WiX v3 in this case) to keep up to date (at least monthly). If you get too far behind and hit a bug then you can get trapped in a difficult position. -Original Message- From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED] On Behalf Of Scott Palmer Sent: Wednesday, June 25, 2008 06:21 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Preprocessor ifdef did odd thing I have a product that can be built two ways. I have two WiX installer projects in visual studio, sharing many of the same wxs files. One project defines a variable in the project settings to cause some of the .wxs files to compile differently, like this: ... Component Id=someFiles Guid=8909196A-8C89-497c-A850-868D7648F063 File Id=file1 Source=..\..\SharedFiles\File1.exe KeyPath=yes Name=File1.exe /File ?ifdef IsVersionA ? File Id=File2 Source=..\..\SharedFiles\File2_A.txt Name=File2.txt/ ?else? File Id=File2 Source=..\..\SharedFiles\File2.txt Name=File2.txt/ ?endif? File Id=File3 Source=..\..\SharedFiles\File3.txt Name=File3.txt/ /Component Directory Id=ConfDir Name=conf Component Id=configFiles Guid=936B3B83-AF5D-47ba-9985-3B4D22E6353B ?ifdef IsVersionA ? File Id=ConfigFile Source=..\..\SharedFiles\conf\server-A.conf Name=server.conf/ ?else? File Id=ConfigFile Source=..\..\SharedFiles\conf\server.conf Name=server.conf/ ?endif? File Id=otherConfig Source=..\..\SharedFiles\etc\ Name=server-password.conf/ /Component /Directory ... When my project built with IsVersionA=true defined in the project settings File2.txt in the msi was a copy of File2_A.txt but server.conf was a copy of ..\..\SharedFiles\conf\server.conf NOT the expected ..\..\SharedFiles\conf\server-A.conf When investigating I manually rebuilt only this project from the solution (after shuffling some lines around to make File Id=otherConfig the key file of Component Id=configFiles) both files were correct. Note that there is another project in the solution that shares this same .wxs file and does not define the IsVersionA variable. I thought at the least that if for some reason the .wxs wasn't being recompiled properly between project builds when I built the solution (doing a rebuild) that the results would be consistent within the single .wxs. They clearly were not - QA reported the file inconsistency. I double checked to confirm the problem by using orca to check the file sizes in the .msi. Then I double checked the preprocessor conditions in the .wxs source file. It was somewhat baffeling. I'm
Re: [WiX-users] WIX version 3.0 errors
MSI SDK talks about the ICE errors. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Xiaoqin Sun Sent: Friday, June 27, 2008 15:42 To: wix-users@lists.sourceforge.net Subject: [WiX-users] WIX version 3.0 errors Hi, I started to use WIX 3.0 and found link errors. Wonder if anybody may help me what I need to do to modify my wxs file to satisfy WIX 3.0 linker. In my wxs file I wrote as this: Directory Id=SUBDIR41 ShortName=subDIR41 Name=vcmake Directory Id=SUBDIR61 ShortName=subDIR61 Name=msrtaudio16bit Component Id=audsln Guid=BD4C63A3-A4E1-4691-BFCE-E97570D94D3F DiskId=1 Win64=$(var.Win64) File Id=ad16sln1 ShortName = adio16b1.sln Name=msrtaudio16bit_2005.sln Source=$(env._LCSROOT)\dev\media\stream\audio\codecs\RTAudio_PK\vcmake\msrtaudio16bit\msrtaudio16bit_2005.sln DiskId='1' / /Component But the link gave me following errors: msrtaudio16b.wxs(64) : error LGHT0204 : ICE38: Component audsln installs to user profile. It must use a registry key under HKCU as its KeyPath, not a file. msrtaudio16b.wxs(63) : error LGHT0204 : ICE64: The directory SUBDIR61 is in the user profile but is not listed in the RemoveFile table. Thanks Xiaoqin - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Warning CNDL1044 - How to get rid of this?
In VS2008 RegExp Search Replace, use the expression (remove the outer single quotes): ' ShortName\=\.#\ ' and replace that with a single space char... that will strip them all out. Chris On Fri, Jun 27, 2008 at 2:48 PM, Luke Bakken [EMAIL PROTECTED] wrote: Mathur, Uttam (GTS) wrote: Thanks Rob but I have 5000 files (5000 rows in XML file) in my package and I don't think this is the easiest fix. Can we assume this warning will go away in new version of WIX? In vim: %s/ ShortName='[^']\+'//g - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
