Re: [WiX-users] Crystal Reports modules not registering files
Hello again. I had the opportunity to test this on a virtual machine, and including the SelfRegModules action solved the problem. Now it seems that everything is being registered. About the 2008 runtime msi. It doesn't work for me because we're using the activex viewer from crystal XI and its not present in this version. Maybe we should upgrade to Crystal 12 to take advantage of the new runtime msi, but for now I think I have to stick with these merge modules. Thanks again for your help Richard. Pedro Ferreira On 11/1/07, Pedro Ferreira [EMAIL PROTECTED] wrote: Hello Richard, thank you for your help. I will try to include the SelfRegModules action and test it on a virtual machine, and see if that solves the problem. Do you know where can I get the Crystal Reports runtime MSI packages? We are using version XI, and in the crystal page, I can only find MSIs for version 2008. Do you know if newer versions include support for previous versions? I know this is not wix related, but I can't seem to find this information on Crystal site, so any help on this would be highly appreciated. Best regards, Pedro Ferreira On 11/1/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: Pedro, My first recommendation would be to use a bootstrapper and the Crystal reports runtime MSI file instead of the merge modules. The merge modules are IMHO almost useless, not to mention the fact that if you use WiX 3 you'll have to turn off verification because the CR merge modules have so many things that cause ICE warnings. If that is not an option for you, the most likely reason for the problem is that you don't have all the necessary actions in your InstallExecuteSequence. Specifically, at least according to comments in some code I used before switching away from the merge modules, you will need to include the SelfRegModules and SelfUnregModules actions. Good luck! Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Ferreira Sent: Wednesday, October 31, 2007 8:21 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] Crystal Reports modules not registering files Hi, I'm fairly new to wix, and I'm trying to deploy the Crystal Reports runtime with my application. I'm inserting the crystal modules as shown here: http://pastebin.com/f286f6c04 The problem is that although the Crystal Reports files are copied to the right directories in the target machine, some or most files are not registered. Tried to create a setup project using Visual Studio 2005, and added the modules to the project, and there, everything works fine, with all files being registered. So I think the problem is with my wix source files. Could someone please give me some tips? I'm getting lost here. Thanks, Pedro Ferreira - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing
[WiX-users] Nigel Rochford is out of the office.
I will be out of the office starting 02/11/2007 and will not return until 06/11/2007. I will respond to your message when I return - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] The whole update maze in MSI
Folks, I'm trying to do this: * Install MyApp v1.0 into a custom directory (e.g. X:\wacky\weirdo\MyApp) * Later, install an update (to v1.01 or v1.1) that picks up where my v1.0 is installed and goes to the same directory by default I figured since not a whole lot has changed between 1.0 and 1.1, I'd use the same ProductID and do a minor update - trouble is, I can't seem to get this to work so that I can just double-click on the Myapp_v1.1.msi and have it run, uninstall the previous v1.0 version, and install itself into that custom directory the user had picked. So I chose to use a Major update, since in that case, I can get it to work as expected (just double-click the MSI and off you go), but in that case, I can't seem to save the installation directory for v1.0 long enough so that v1.1 will pick up on it. v1.0 gets uninstalled okay, but the MSI insists on putting v1.1 into the default directory (c:\program files\[manufacturer]\MyApp11 or whatever it is). So how do I * either make MINOR updates WORK automagically without a plethora of commandline switches - just double-click on the v1.1 MSI and off you go and MyApp is updated * get the MAJOR update to work so that when installing v1.1, I can somehow find the installation directory for v1.0 before it gets uninstalled, and use it as the default for my update-install for v1.1 I've read and re-read and re-re-read the MSI docs and all the web site and tutorial and books I can get on MSI and its update magic - I don't get it. Can one of you help? Have you done this, and how? Cheers ! Marc - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Font definition and WXL
I actually rewrote the code for the last test. If you look at the original example the names match. However, after trying a few more things, it looks like the FaceName attribute takes the localized string just fine. It's the Size and Bold attributes that are not preprocessing the localized string. Look at the original errors below. Paul From: Eric Baudouin Sent: Thursday, November 01, 2007 5:20 PM To: Kelly Leahy Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Font definition and WXL Not a bad suggestion:) Paul would you mind to have a look at this, in case the linker is case sensitive. Thank you. E. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:59 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Ok... It also appears that your error message says 'Facename' (lowercase 'N'), but your declaration shows an uppercase. Not sure if it matters, just thought I'd mention it since I noticed it. Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:44 PM To Kelly Leahy [EMAIL PROTECTED] cc [EMAIL PROTECTED] [EMAIL PROTECTED], Paul Houldridge [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject Re: [WiX-users] Font definition and WXL Here is the answer from Paul, so it look like syntaxically speaking we were doing the right thing. So I think we need to focus more on the methodology. Thank you anyway for your reply. No luck. Using the ! instead of the $ is right. $ is deprecated. .\SetupUI.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. warnings in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. .\SetupUI.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. errors in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' Stop. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:31 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)? Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:17 PM To wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Paul Houldridge [EMAIL PROTECTED] Subject [WiX-users] Font definition and WXL Hello, We have moved our resource to a wxl file to facilitate the localization of our component. In the localization world it is a good practice to make sure that the font size and the font facename can be localized. I was hoping that I could move the font style attribute in the WXL as well so that the localization team could change it accordingly, since the font size and the font facename are different for the Japanese, or any far-east languages. Unfortunately as you can see down below replacing the font attribute with the WXL loc ID causes the compiler to break, because the preprocessor might run some validation because linked the loc data in the code. Would you have a different approach we could use so that at least we have a work-around. Thank you very much. E. wixloc:String Id=BannerTextStyle_FaceNameMS Sans Serif/wixloc:String wixloc:String Id=BannerTextStyle_Size12/wixloc:String wixloc:String Id=BannerTextStyle_Boldyes/wixloc:String Then within my UI tag I have: TextStyle Id=BannerTextStyle FaceName=!(loc.BannerTextStyle_FaceName) Size=!(loc.BannerTextStyle_Size) Red=0 Green=0 Blue=0 Bold=!(loc.BannerTextStyle_Bold)/ The error I get indicates that the !(loc.name) syntax does not work within the attributes for TextStyle. The loc variables are not getting processed into the defined values. This is the error I get: errors in directory c:\harmonica\sql\sync\src\setup\core c:\harmonica\sql\sync\src\setup\core\setupui.wix(26) : error CNDL0008 : The TextStyle/@Size attribute's value,
Re: [WiX-users] Font definition and WXL
Actually, paul, I suspect that Facename isn't working either, you just don't get an XSD validation error because there's no rules for the format of the face name. I bet if you hardcoded the size and bold attributes and compiled your MSI you'd have the !(...) stuff in your facename in the output MSI. You just wouldn't get a validation error, because there's no way for MSI to know that the facename you supplied isn't a valid font name -- after all, who wouldn't want to call their font !(loc.BannerTextStyle_Facename)? wink/ Paul Houldridge [EMAIL PROTECTED] 11/02/2007 08:17 AM To Eric Baudouin [EMAIL PROTECTED], Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net, [EMAIL PROTECTED] [EMAIL PROTECTED] Subject RE: [WiX-users] Font definition and WXL I actually rewrote the code for the last test. If you look at the original example the names match. However, after trying a few more things, it looks like the FaceName attribute takes the localized string just fine. It’s the Size and Bold attributes that are not preprocessing the localized string. Look at the original errors below. Paul From: Eric Baudouin Sent: Thursday, November 01, 2007 5:20 PM To: Kelly Leahy Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Font definition and WXL Not a bad suggestionJ Paul would you mind to have a look at this, in case the linker is case sensitive. Thank you. E. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:59 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Ok... It also appears that your error message says 'Facename' (lowercase 'N'), but your declaration shows an uppercase. Not sure if it matters, just thought I'd mention it since I noticed it. Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:44 PM To Kelly Leahy [EMAIL PROTECTED] cc [EMAIL PROTECTED] [EMAIL PROTECTED], Paul Houldridge [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject Re: [WiX-users] Font definition and WXL Here is the answer from Paul, so it look like syntaxically speaking we were doing the right thing. So I think we need to focus more on the methodology. Thank you anyway for your reply. No luck. Using the ! instead of the $ is right. $ is deprecated. .\SetupUI.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. warnings in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. .\SetupUI.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. errors in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' Stop. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:31 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)? Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:17 PM To wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Paul Houldridge [EMAIL PROTECTED] Subject [WiX-users] Font definition and WXL Hello, We have moved our resource to a wxl file to facilitate the localization of our component. In the localization world it is a good practice to make sure that the font size and the font facename can be localized. I was hoping that I could move the font style attribute in the WXL as well so that the localization team could change it accordingly, since the font size and the font facename are different for the Japanese, or any far-east languages. Unfortunately as you can see down below replacing the font attribute with the WXL loc ID causes the compiler to break, because the preprocessor might run some validation because linked the loc data in
Re: [WiX-users] MSI returns 1606 Could not access location
All I'm saying is that if you remove the location that the software is installed to, it is unreasonable to uninstall, repair, reinstall, or perform any other operation since the location the software has been installed to no longer exists. What do you want Windows Installer to do differently? It has no chance to even confirm that the directories were removed since the volume they reside on is no longer accessible. This is expected behavior from WI, and is By Design. Nothing wix can do to change it. Either restore the volume or get MsiZap. From: Davut Karabay [EMAIL PROTECTED] Sent: Friday, November 02, 2007 12:47 AM To: Blair Murri; Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MSI returns 1606 Could not access location Are you saying that TARGETDIR should not be set to \\wmiscratch\scratch\davut\DaRTfile://\\wmiscratch\scratch\davut\DaRT? But that's where software was installed right?. Installer should be setting it internally. My problem is; if the share become unavailable then there seems to be no way out. Can't uninstall or repair, or install on top of existing. From: [EMAIL PROTECTED] To: [EMAIL PROTECTED]; [EMAIL PROTECTED] CC: wix-users@lists.sourceforge.net Date: Thu, 1 Nov 2007 14:50:41 -0700 Subject: RE: [WiX-users] MSI returns 1606 Could not access location MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'. This line seems to me to be the primary reason. TARGETDIR is the location where the software has been installed. It seems to me that it can’t erase it out of the network share if the network share doesn’t exist. The MSDN docs say that KB886549 can also produce 1606 errors (http://support.microsoft.com/kb/886549/en-us). But, instead I think it is something wrong in your directory table and/or passed in command-line values. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut Karabay Sent: Thursday, November 01, 2007 2:28 PM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSI returns 1606 Could not access location Hi Rob - Thank you for your reply. Do you mean I require network share to exist during uninstall (in the WIX code)? Isn't that a requirement by MSI which I don't have control over? Here is the log. I couldn't understand anything useful other than error code. ... Id start 13:48:25: CostFinalize. MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'. MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'. MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'. MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'. MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'. MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2205 2: 3: MsiAssembly MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT `MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, `MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`, `Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND `MsiAssembly`.`Component_` = ? MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'. MSI (c) (4C:38) [13:48:25:825]: PROPERTY CHANGE: Adding enUS property. Its value is '\\wmiscratch\scratch\davut\DaRT\en-us'. MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Patch MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Condition MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding MSDARTShortCuts property. Its value is 'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft Diagnostics and Recovery Toolset\'. MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1314 2: \\wmiscratch\scratch\davut\DaRT MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT. MSI (c) (4C:38) [13:48:31:637]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT. MSI (c) (4C:38) [13:48:31:652]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT. MSI (c) (4C:38) [13:48:32:909]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT. Id ended 13:48:32: CostFinalize. Return value 3.
Re: [WiX-users] The whole update maze in MSI
To get the second option to work, save the installation directory in the registry when you install v1.0. Then when performing a major upgrade, have v1.1 search the registry for the installation directory and use it. -Brian Simoneau From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Scheuner Sent: Friday, November 02, 2007 7:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The whole update maze in MSI Folks, I'm trying to do this: * Install MyApp v1.0 into a custom directory (e.g. X:\wacky\weirdo\MyApp) * Later, install an update (to v1.01 or v1.1) that picks up where my v1.0 is installed and goes to the same directory by default I figured since not a whole lot has changed between 1.0 and 1.1, I'd use the same ProductID and do a minor update - trouble is, I can't seem to get this to work so that I can just double-click on the Myapp_v1.1.msi and have it run, uninstall the previous v1.0 version, and install itself into that custom directory the user had picked. So I chose to use a Major update, since in that case, I can get it to work as expected (just double-click the MSI and off you go), but in that case, I can't seem to save the installation directory for v1.0 long enough so that v1.1 will pick up on it. v1.0 gets uninstalled okay, but the MSI insists on putting v1.1 into the default directory (c:\program files\[manufacturer]\MyApp11 or whatever it is). So how do I * either make MINOR updates WORK automagically without a plethora of commandline switches - just double-click on the v1.1 MSI and off you go and MyApp is updated * get the MAJOR update to work so that when installing v1.1, I can somehow find the installation directory for v1.0 before it gets uninstalled, and use it as the default for my update-install for v1.1 I've read and re-read and re-re-read the MSI docs and all the web site and tutorial and books I can get on MSI and its update magic - I don't get it. Can one of you help? Have you done this, and how? Cheers ! Marc - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] The whole update maze in MSI
Marc, I concur with Brian, but make sure you have your AppSearch sequenced somewhere before your RemoveExistingProducts in this case, or else MSI will remove the existing version before you get a chance to search the registry for the item. BTW, if you have already released 1.0 and you can't add the registry item, another type of AppSearch may work, like a file system search, for instance, or you may need a CA to do this. You could also write a CA (or there may support for this already in MSI's AppSearch) to read from the existing component location of one of your 'always installed' components of your previous MSI. Kelly Brian Simoneau [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/02/2007 06:36 AM To Marc Scheuner [EMAIL PROTECTED], wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] The whole update maze in MSI To get the second option to work, save the installation directory in the registry when you install v1.0. Then when performing a major upgrade, have v1.1 search the registry for the installation directory and use it. -Brian Simoneau From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Marc Scheuner Sent: Friday, November 02, 2007 7:29 AM To: wix-users@lists.sourceforge.net Subject: [WiX-users] The whole update maze in MSI Folks, I'm trying to do this: * Install MyApp v1.0 into a custom directory (e.g. X:\wacky\weirdo\MyApp) * Later, install an update (to v1.01 or v1.1) that picks up where my v1.0 is installed and goes to the same directory by default I figured since not a whole lot has changed between 1.0 and 1.1, I'd use the same ProductID and do a minor update - trouble is, I can't seem to get this to work so that I can just double-click on the Myapp_v1.1.msi and have it run, uninstall the previous v1.0 version, and install itself into that custom directory the user had picked. So I chose to use a Major update, since in that case, I can get it to work as expected (just double-click the MSI and off you go), but in that case, I can't seem to save the installation directory for v1.0 long enough so that v1.1 will pick up on it. v1.0 gets uninstalled okay, but the MSI insists on putting v1.1 into the default directory (c:\program files\[manufacturer]\MyApp11 or whatever it is). So how do I * either make MINOR updates WORK automagically without a plethora of commandline switches - just double-click on the v1.1 MSI and off you go and MyApp is updated * get the MAJOR update to work so that when installing v1.1, I can somehow find the installation directory for v1.0 before it gets uninstalled, and use it as the default for my update-install for v1.1 I've read and re-read and re-re-read the MSI docs and all the web site and tutorial and books I can get on MSI and its update magic - I don't get it. Can one of you help? Have you done this, and how? Cheers ! Marc - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ** This communication is intended solely for the addressee and is confidential. If you are not the intended recipient, any disclosure, copying, distribution or any action taken or omitted to be taken in reliance on it, is prohibited and may be unlawful. Unless indicated to the contrary: it does not constitute professional advice or opinions upon which reliance may be made by the addressee or any other party, and it should be considered to be a work in progress. Unless stated otherwise, this communication does not form a prescribed statement of actuarial opinion under American Academy of Actuaries guidelines. **- This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Font definition and WXL
The issue is that those columns in the TextStyle table are not marked as localizable so the !(loc variable replacement never happens. Please file a sourceforge bug on this. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Kelly Leahy Sent: Friday, November 02, 2007 8:51 AM To: Paul Houldridge Cc: [EMAIL PROTECTED]; Eric Baudouin; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Font definition and WXL Actually, paul, I suspect that Facename isn't working either, you just don't get an XSD validation error because there's no rules for the format of the face name. I bet if you hardcoded the size and bold attributes and compiled your MSI you'd have the !(...) stuff in your facename in the output MSI. You just wouldn't get a validation error, because there's no way for MSI to know that the facename you supplied isn't a valid font name -- after all, who wouldn't want to call their font !(loc.BannerTextStyle_Facename)? wink/ Paul Houldridge [EMAIL PROTECTED] 11/02/2007 08:17 AM To Eric Baudouin [EMAIL PROTECTED], Kelly Leahy [EMAIL PROTECTED] cc wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net, [EMAIL PROTECTED] [EMAIL PROTECTED] Subject RE: [WiX-users] Font definition and WXL I actually rewrote the code for the last test. If you look at the original example the names match. However, after trying a few more things, it looks like the FaceName attribute takes the localized string just fine. It’s the Size and Bold attributes that are not preprocessing the localized string. Look at the original errors below. Paul From: Eric Baudouin Sent: Thursday, November 01, 2007 5:20 PM To: Kelly Leahy Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: RE: [WiX-users] Font definition and WXL Not a bad suggestion☺ Paul would you mind to have a look at this, in case the linker is case sensitive. Thank you. E. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:59 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Ok... It also appears that your error message says 'Facename' (lowercase 'N'), but your declaration shows an uppercase. Not sure if it matters, just thought I'd mention it since I noticed it. Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:44 PM To Kelly Leahy [EMAIL PROTECTED] cc [EMAIL PROTECTED] [EMAIL PROTECTED], Paul Houldridge [EMAIL PROTECTED], wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net Subject Re: [WiX-users] Font definition and WXL Here is the answer from Paul, so it look like syntaxically speaking we were doing the right thing. So I think we need to focus more on the methodology. Thank you anyway for your reply. No luck. Using the ! instead of the $ is right. $ is deprecated. .\SetupUI.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. warnings in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : warning LGHT1073 : The localization variable $(loc.BannerTextStyle_Facename) uses a deprecated prefix '$'. Please use the '!' prefix instead. Since the prefix '$' is also used by the preprocessor, it has been deprecated to avoid namespace collisions. .\SetupUI.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. errors in directory c:\drs_sync_1\sql\sync\src\setup\core c:\drs_sync_1\sql\sync\src\setup\core\setupui.wix(26) : error LGHT0102 : The localization variable !(loc.BannerTextStyle_Facename) is unknown. Please ensure the variable is defined. NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' NMAKE : fatal error U1077: 'C:\DRS_SYNC_1\Tools\wix3\light.exe' : return code '0x66' Stop. From: Kelly Leahy [mailto:[EMAIL PROTECTED] Sent: Thursday, November 01, 2007 4:31 PM To: Eric Baudouin Cc: Paul Houldridge; wix-users@lists.sourceforge.net; [EMAIL PROTECTED] Subject: Re: [WiX-users] Font definition and WXL Don't you want $(loc.BannerTextStyle_Size) not !(loc.BannerTextStyle_Size)? Kelly Eric Baudouin [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 11/01/2007 04:17 PM To wix-users@lists.sourceforge.net wix-users@lists.sourceforge.net cc Paul Houldridge [EMAIL PROTECTED] Subject [WiX-users] Font definition and WXL Hello, We have moved our resource to a wxl file to facilitate the localization of our component. In the localization world it is a good practice to make sure that the font size and the font facename can be localized. I was hoping that I could move the font style attribute in the
[WiX-users] iis:WebServiceExtension. What am I doing wrong?
Hey Guys,
As part of our install my installer needs to enable ASP.Net 2.0 Web Service
Extentions in IIS 6.0 and above and windows 2003. I tried using
iis:WebServiceExtension but I am unable to get it to enable the said
extentions..Here are some of my code snippets...
Component Id=ASPNetWebServiceExtention
Guid={3D36B9A2-4E11-4554-A962-1AAD041892E3}
iis:WebServiceExtension Id=WebServiceExtension_ASP.NET_2.0
File=[ASPNETISAPIDLL] Allow=yes Description=ASP.NET v2.0.50727
UIDeletable=no /
/Component
...
...
...
Property Id=ASPNETISAPIDLL
DirectorySearch Id=ASPNETISAPIDLLSearch
Path=[WindowsFolder]Microsoft.NET\Framework Depth=2
FileSearch Id=ASPNETISAPIDLLFile Name=aspnet_isapi.dll
MinVersion=2.0 MaxVersion=3.0 /
/DirectorySearch
/Property
...
...
...
Feature Id=ASPNetExt Level=1 Title=ASP.Net 2.0 Web Service Extensions
Registration
ComponentRef Id=ASPNetWebServiceExtention /
Condition Level=0(VersionNT=500)/Condition
/Feature
What am I doing wrong?
--
. Abdullah Ahmed
. [EMAIL PROTECTED]
-
This SF.net email is sponsored by: Splunk Inc.
Still grepping through log files to find problems? Stop.
Now Search log events and configuration files using AJAX and a browser.
Download your FREE copy of Splunk now http://get.splunk.com/___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] MSI returns 1606 Could not access location
Thank you for the clarification! From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL PROTECTED]: Fri, 2 Nov 2007 07:26:39 -0700Subject: RE: [WiX-users] MSI returns 1606 Could not access location All I'm saying is that if you remove the location that the software is installed to, it is unreasonable to uninstall, repair, reinstall, or perform any other operation since the location the software has been installed to no longer exists. What do you want Windows Installer to do differently? It has no chance to even confirm that the directories were removed since the volume they reside on is no longer accessible. This is expected behavior from WI, and is By Design. Nothing wix can do to change it. Either restore the volume or get MsiZap. From: Davut Karabay [EMAIL PROTECTED]: Friday, November 02, 2007 12:47 AMTo: Blair Murri; Rob MenschingCc: [EMAIL PROTECTED]: RE: [WiX-users] MSI returns 1606 Could not access location Are you saying that TARGETDIR should not be set to \\wmiscratch\scratch\davut\DaRT? But that's where software was installed right?. Installer should be setting it internally. My problem is; if the share become unavailable then there seems to be no way out. Can't uninstall or repair, or install on top of existing. From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL PROTECTED]: Thu, 1 Nov 2007 14:50:41 -0700Subject: RE: [WiX-users] MSI returns 1606 Could not access location MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'. This line seems to me to be the primary reason. TARGETDIR is the location where the software has been installed. It seems to me that it can’t erase it out of the network share if the network share doesn’t exist. The MSDN docs say that KB886549 can also produce 1606 errors (http://support.microsoft.com/kb/886549/en-us). But, instead I think it is something wrong in your directory table and/or passed in command-line values. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut KarabaySent: Thursday, November 01, 2007 2:28 PMTo: Rob MenschingCc: [EMAIL PROTECTED]: Re: [WiX-users] MSI returns 1606 Could not access location Hi Rob - Thank you for your reply. Do you mean I require network share to exist during uninstall (in the WIX code)? Isn't that a requirement by MSI which I don't have control over? Here is the log. I couldn't understand anything useful other than error code. ...Id start 13:48:25: CostFinalize.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2205 2: 3: MsiAssembly MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT `MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, `MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`, `Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND `MsiAssembly`.`Component_` = ? MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'.MSI (c) (4C:38) [13:48:25:825]: PROPERTY CHANGE: Adding enUS property. Its value is '\\wmiscratch\scratch\davut\DaRT\en-us'.MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Patch MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Condition MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding MSDARTShortCuts property. Its value is 'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft Diagnostics and Recovery Toolset\'.MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1314 2: \\wmiscratch\scratch\davut\DaRT MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:637]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:652]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:32:909]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location
[WiX-users] deferred CAQuietExec
In WiX 3.0, how do I pass the command line and timeout (QtExecCmdLine and QtExecTimeout respectively) properties to the CAQuietExec custom action when I need it to Execute=deferred? When I attempt this, CAQuietExec complains that it can't get the properties. Regards, Adam - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Crystal Reports modules not registering files
Pedro, I'm not sure where (or if) there is a runtime MSI for the original XI release. There is for XI R2 (typically in C:\Program Files\Business Objects\Crystal Reports 11.5\Samples\en\CR .NET\.NET 2 Runtime Setup\CrystalReports11_5_NET_2005.msi for the .NET 2.0 version. There may be something in a similar location for the original XI release) My experience has been that new versions generally support older report files. They also add bulk to the report runtime footprint. :-( Since CR 2008 is so new, I personally am not planning on migrating to it at this time - it's just too close to release time to get an acceptable quantity of testing performed. Hope this helps, Regards, Richard -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Pedro Ferreira Sent: Thursday, November 01, 2007 3:38 PM To: Foster, Richard - PAL Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Crystal Reports modules not registering files Hello Richard, thank you for your help. I will try to include the SelfRegModules action and test it on a virtual machine, and see if that solves the problem. Do you know where can I get the Crystal Reports runtime MSI packages? We are using version XI, and in the crystal page, I can only find MSIs for version 2008. Do you know if newer versions include support for previous versions? I know this is not wix related, but I can't seem to find this information on Crystal site, so any help on this would be highly appreciated. Best regards, Pedro Ferreira * C O N F I D E N T I A L I T Y N O T I C E * --- The content of this e-mail is intended solely for the use of the individual or entity to whom it is addressed. If you have received this communication in error, be aware that forwarding it, copying it, or in any way disclosing its content to any other person, is strictly prohibited. Quixote Traffic Corporation is neither liable for the contents, nor for the proper, complete and timely transmission of (the information contained in) this communication. If you have received this communication in error, please notify the author by replying to this e-mail immediately and delete the material from any computer. - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Installing the same as admin and user
Hi,
I get an error message and my guess is that it is because I do what is
said in the subject: Installing the same as admin and user.
My installer is installed centrally by our administrators and users do
not have write access to it. Now some users need to have the
installation on their own home drive because they need to recompile
from sources.
When I log the run of the installer I get something ending with:
MSI (c) (F4:C4) [12:00:04:368]: Product {27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}
is admin assigned: LocalSystem owns the publish key.
MSI (c) (F4:C4) [12:00:04:368]: Product {27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}
is managed.
MSI (c) (F4:C4) [12:00:04:368]: Running product
'{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}' with elevated privileges: Product is
assigned.
MSI (c) (F4:C4) [12:00:04:368]: Adding new sources is not allowed.
This installation is forbidden by system policy. Contact your system
administrator.
Is that because it has already been installed on the c-drive? Or what
could be the reason? Can I solve it?
tia,
Brian
Complete log below:
=== Verbose logging started: 01-11-2007 12:00:04 Build type: SHIP UNICODE
3.01.4000.4039 Calling process: C:\WINDOWS\system32\msiexec.exe ===
MSI (c) (F4:C4) [12:00:04:318]: Resetting cached policy values
MSI (c) (F4:C4) [12:00:04:318]: Machine policy value 'Debug' is 0
MSI (c) (F4:C4) [12:00:04:318]: *** RunEngine:
*** Product: dna.msi
*** Action:
*** CommandLine: **
MSI (c) (F4:C4) [12:00:04:318]: Machine policy value 'DisableUserInstalls' is 0
MSI (c) (F4:C4) [12:00:04:348]: SOFTWARE RESTRICTION POLICY: Verifying package
-- 'C:\DOCUME~1\v2671\Desktop\dna.msi' against software restriction policy
MSI (c) (F4:C4) [12:00:04:348]: Note: 1: 2262 2: .DigitalSignature 3:
-2147287038
MSI (c) (F4:C4) [12:00:04:348]: SOFTWARE RESTRICTION POLICY:
C:\DOCUME~1\v2671\Desktop\dna.msi is not digitally signed
MSI (c) (F4:C4) [12:00:04:348]: SOFTWARE RESTRICTION POLICY:
C:\DOCUME~1\v2671\Desktop\dna.msi is permitted to run at the 'unrestricted'
authorization level.
MSI (c) (F4:C4) [12:00:04:348]: Cloaking enabled.
MSI (c) (F4:C4) [12:00:04:348]: Attempting to enable all disabled priveleges
before calling Install on Server
MSI (c) (F4:C4) [12:00:04:358]: End dialog not enabled
MSI (c) (F4:C4) [12:00:04:358]: Original package ==
C:\DOCUME~1\v2671\Desktop\dna.msi
MSI (c) (F4:C4) [12:00:04:358]: Package we're running from ==
C:\DOCUME~1\v2671\LOCALS~1\Temp\4dee9be7.msi
MSI (c) (F4:C4) [12:00:04:358]: APPCOMPAT: looking for appcompat database entry
with ProductCode '{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}'.
MSI (c) (F4:C4) [12:00:04:358]: APPCOMPAT: no matching ProductCode found in
database.
MSI (c) (F4:C4) [12:00:04:358]: MSCOREE not loaded loading copy from system32
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'DisablePatch' is 0
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'AllowLockdownPatch' is 0
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'DisableMsi' is 0
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'AlwaysInstallElevated' is
1
MSI (c) (F4:C4) [12:00:04:358]: User policy value 'AlwaysInstallElevated' is 0
MSI (c) (F4:C4) [12:00:04:358]: Product {27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}
is admin assigned: LocalSystem owns the publish key.
MSI (c) (F4:C4) [12:00:04:358]: Product {27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}
is managed.
MSI (c) (F4:C4) [12:00:04:358]: Running product
'{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}' with elevated privileges: Product is
assigned.
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'DisableLUAPatching' is 0
MSI (c) (F4:C4) [12:00:04:358]: Machine policy value 'DisableFlyWeightPatching'
is 0
MSI (c) (F4:C4) [12:00:04:368]: APPCOMPAT: looking for appcompat database entry
with ProductCode '{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}'.
MSI (c) (F4:C4) [12:00:04:368]: APPCOMPAT: no matching ProductCode found in
database.
MSI (c) (F4:C4) [12:00:04:368]: Transforms are not secure.
MSI (c) (F4:C4) [12:00:04:368]: Command Line:
CURRENTDIRECTORY=C:\DOCUME~1\v2671\Desktop CLIENTUILEVEL=0 CLIENTPROCESSID=1780
MSI (c) (F4:C4) [12:00:04:368]: PROPERTY CHANGE: Adding PackageCode property.
Its value is '{C98853B4-A97D-47F8-8C86-37A5849788B0}'.
MSI (c) (F4:C4) [12:00:04:368]: Product Code passed to Engine.Initialize:
''
MSI (c) (F4:C4) [12:00:04:368]: Product Code from property table before
transforms: '{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}'
MSI (c) (F4:C4) [12:00:04:368]: Product Code from property table after
transforms: '{27249B57-8B5C-D44F-4FB1-DD0F93DD5A7B}'
MSI (c) (F4:C4) [12:00:04:368]: Product not registered: beginning first-time
install
MSI (c) (F4:C4) [12:00:04:368]: PROPERTY CHANGE: Adding ProductState property.
Its value is '1'.
MSI (c) (F4:C4) [12:00:04:368]: Entering
CMsiConfigurationManager::SetLastUsedSource.
MSI (c) (F4:C4) [12:00:04:368]: Specifed source is not already in a list.
MSI (c) (F4:C4)
Re: [WiX-users] MSI returns 1606 Could not access location
Are you saying that TARGETDIR should not be set to \\wmiscratch\scratch\davut\DaRT? But that's where software was installed right?. Installer should be setting it internally. My problem is; if the share become unavailable then there seems to be no way out. Can't uninstall or repair, or install on top of existing. From: [EMAIL PROTECTED]: [EMAIL PROTECTED]; [EMAIL PROTECTED]: [EMAIL PROTECTED]: Thu, 1 Nov 2007 14:50:41 -0700Subject: RE: [WiX-users] MSI returns 1606 Could not access location MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'. This line seems to me to be the primary reason. TARGETDIR is the location where the software has been installed. It seems to me that it can’t erase it out of the network share if the network share doesn’t exist. The MSDN docs say that KB886549 can also produce 1606 errors (http://support.microsoft.com/kb/886549/en-us). But, instead I think it is something wrong in your directory table and/or passed in command-line values. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Davut KarabaySent: Thursday, November 01, 2007 2:28 PMTo: Rob MenschingCc: [EMAIL PROTECTED]: Re: [WiX-users] MSI returns 1606 Could not access location Hi Rob - Thank you for your reply. Do you mean I require network share to exist during uninstall (in the WIX code)? Isn't that a requirement by MSI which I don't have control over? Here is the log. I couldn't understand anything useful other than error code. ...Id start 13:48:25: CostFinalize.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfDiskSpace property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding OutOfNoRbDiskSpace property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceAvailable property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRequired property. Its value is '0'.MSI (c) (4C:38) [13:48:25:747]: PROPERTY CHANGE: Adding PrimaryVolumeSpaceRemaining property. Its value is '0'.MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2205 2: 3: MsiAssembly MSI (c) (4C:38) [13:48:25:762]: Note: 1: 2228 2: 3: MsiAssembly 4: SELECT `MsiAssembly`.`Attributes`, `MsiAssembly`.`File_Application`, `MsiAssembly`.`File_Manifest`, `Component`.`KeyPath` FROM `MsiAssembly`, `Component` WHERE `MsiAssembly`.`Component_` = `Component`.`Component` AND `MsiAssembly`.`Component_` = ? MSI (c) (4C:38) [13:48:25:762]: PROPERTY CHANGE: Modifying TARGETDIR property. Its current value is 'C:\Program Files\Microsoft Diagnostics and Recovery Toolset'. Its new value: '\\wmiscratch\scratch\davut\DaRT'.MSI (c) (4C:38) [13:48:25:825]: PROPERTY CHANGE: Adding enUS property. Its value is '\\wmiscratch\scratch\davut\DaRT\en-us'.MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Patch MSI (c) (4C:38) [13:48:25:840]: Note: 1: 2205 2: 3: Condition MSI (c) (4C:38) [13:48:25:840]: PROPERTY CHANGE: Adding MSDARTShortCuts property. Its value is 'C:\Users\Davut\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Microsoft Diagnostics and Recovery Toolset\'.MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1314 2: \\wmiscratch\scratch\davut\DaRT MSI (c) (4C:38) [13:48:25:903]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:637]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:31:652]: Note: 1: 1606 2: \\wmiscratch\scratch\davut\DaRT Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.MSI (c) (4C:38) [13:48:32:909]: Product: Microsoft Diagnostics and Recovery Toolset 6.0 -- Error 1606. Could not access network location \\wmiscratch\scratch\davut\DaRT.Id ended 13:48:32: CostFinalize. Return value 3Thanks,Davut Date: Wed, 31 Oct 2007 11:35:43 -0700 From: [EMAIL PROTECTED] To: [EMAIL PROTECTED] CC: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MSI returns 1606 Could not access location This happens if your MSI requires the original source media for some reason during uninstall. Usually, it's some coding error that causes this problem. Look in the verbose log file and see what is causing the source prompt. Davut Karabay wrote: Hi, I run my insaller (e.g. msiexec /i XYZ.msi). Select a network path to install (e.g. \\somecomputer\someshare\installdir). Product is installed with success. Now delete the network path. Run the installer again. It returns 1606 saying that could not access the network location. Installer is stuck. Can't uninstall or repair. Is this by design? Can I handle it differently? Thanks, Davut
Re: [WiX-users] x64 and ProgramFilesFolder vs. ProgramFiles64Folder
On Oct 24, 2007 7:59 AM, Bob Arnson [EMAIL PROTECTED] wrote: Geoff Finger wrote: Instead what I found was a post claiming I don't think you want to reference ProgramFiles64Folder either. Use ProgramFilesFolder and Windows Installer will put things in the correct directory based upon the Component's Win64 setting. That's not how it works. A 64-bit package can write to both folders (as appropriate given the bitness of its components) but it's not automatic so you need both directory hierarchies. How do you avoid getting the error LGHT0109 : Duplicate symbol 'Directory:INSTALLDIR' found. errors in that case? I can change INSTALLDIR to INSTALLDIR2 or something similar, but then the file structure in Program Files (x86) won't match that in Program Files if the user changes the install directory, right? Do I need to make some kind of custom action to copy the value of INSTALLDIR to INSTALLDIR2 after the directory selection page? Thanks! (And sorry about the slow response, I got sidetracked onto another project for awhile.) - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] XmlFile From Property
I was looking at using the XmlFile custom action. I wanted to store the values in the Property table; and issue various installs with setting customized (by me) using Orca. However, it appears as if you have to hard code the value attribute of the xml tag; and that it therefore cannot reference the properties table. Is this in fact true, or is there a way for me to do what I suggest? Let me know, James Beverly, MA - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Wix3 - No Type=Edit control in UI to edit input?
Sorry if I'm missing something, but I'm trying to use a dialog control of Type=Edit that worked fine in V2 but crashes the msi in V3 with an error of 2885. I'm not readily finding and mention of what the values can be here, besides Text/Combox/but what about PathEdit, Edit? I'm sure I'm missing something? BTW I've noticed that I cannot copy any text in any dialog to the clipboard - which would be handy for people who need to make note of valuable info e.g. URL, help contact info, etc. Many thanks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix3 - No Type=Edit control in UI to edit input?
Sorry never mind I have this working. On Fri, 2 Nov 2007 20:36:34 -0800, Serge Gart wrote Sorry if I'm missing something, but I'm trying to use a dialog control of Type=Edit that worked fine in V2 but crashes the msi in V3 with an error of 2885. I'm not readily finding and mention of what the values can be here, besides Text/Combox/but what about PathEdit, Edit? I'm sure I'm missing something? BTW I've noticed that I cannot copy any text in any dialog to the clipboard - which would be handy for people who need to make note of valuable info e.g. URL, help contact info, etc. Many thanks - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Launching Default Browser
Hi I want to launch the default browser after my installation is finished. I tried this Property Id=BROWSER RegistrySearch Id='DefaultBrowser' Type='raw' Root='HKCR' Key='http\shell\open\command' / /Property CustomAction Id='LaunchBrowser' Property='BROWSER' ExeCommand='www.something.com' Return='asyncNoWait' / InstallExecuteSequence ... Custom Action='LaunchBrowser' After='InstallFinalize'NOT Installed/Custom /InstallExecuteSequence But this is not working ,. I see no browser being launched Thanks and Regards Srinivas T - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Launching Default Browser
Well FYI I am using WIX 2 From: Srinivas Tirupati Sent: Saturday, November 03, 2007 11:36 AM To: wix-users@lists.sourceforge.net Subject: Launching Default Browser Hi I want to launch the default browser after my installation is finished. I tried this Property Id=BROWSER RegistrySearch Id='DefaultBrowser' Type='raw' Root='HKCR' Key='http\shell\open\command' / /Property CustomAction Id='LaunchBrowser' Property='BROWSER' ExeCommand='www.something.com' Return='asyncNoWait' / InstallExecuteSequence ... Custom Action='LaunchBrowser' After='InstallFinalize'NOT Installed/Custom /InstallExecuteSequence But this is not working ,. I see no browser being launched Thanks and Regards Srinivas T - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration files using AJAX and a browser. Download your FREE copy of Splunk now http://get.splunk.com/___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
