[WiX-users] MSI returns 1606 Could not access location
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 _ Boo! Scare away worms, viruses and so much more! Try Windows Live OneCare! http://onecare.live.com/standard/en-us/purchase/trial.aspx?s_cid=wl_hotmailnews - 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] adding mimemap to Webvirtualdir
Hi all, I want to know how the iis:mimemap tag works, it seems to need an id but do not know how to add an MIME element although in the helpfile is written that it schould be child of Wix tag. Second thing is that I want to add a wildcard mime (after I know how to add a MIME to a webvirtualdir) like „*,C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll,0,All or is it better to call a vbscript instead? Thanks Peter - 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] Maintenance modes (Might be related to old UAC Prompt Required thread, April 2007)
It gets even stranger. For some reason, it does uninstall properly when I start the msi from an admin command prompt like this: msiexec /i setup.msi /l*vx admin.log but if I start it from a non admin account like this: msiexec /i setuprip.msi /l*vx nonadmin.log it leaves behind the items an admin can't remove. I also notice in the logs, I have these lines in the admin.log file: MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property. Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'. Action ended 10:47:56: InstallValidate. Return value 1. The non admin log is missing the modify of the remove property. I'm using an install sequence based on the wix UI specified like this: Property Id=WixUI_Mode Value=InstallDir / I also notice that in the admin log I have this: MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. while in the non-admin it says: * MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant ** MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. So it looks like it won't do it because it hasn't elevated, which makes sense, because it's a per machine install. So, it's looking like it's not really a WiX problem, but more of an MSI problem. Any ideas? Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 6:47 AM Subject: Re: [WiX-users] Maintenance modes From: Richard [EMAIL PROTECTED] Sent: Monday, October 29, 2007 9:40 PM Subject: Re: [WiX-users] Maintenance modes In article [EMAIL PROTECTED], Anthony Wieser [EMAIL PROTECTED] writes: For some reason my msi file is bringing up the maintenance mode when I double click it. This means its already installed. 1. How do I make sure that only remove is supported. I've already set the property ARPNOMODIFY like this: Property Id=ARPNOMODIFY Value=1 / but I've done it in a UI block. Is that wrong? Put it inside the Product tag. Turns out I got this from the WixUI_InstallDir.wxs file I based it on. The property seems to be in the right place when I look at the file in Orcas. Secondly, if this is expected behavior, any ideas why when I click the remove button, everything in my install disappears, except for the entries under add remove programs? It sounds like you've corrupted Add/Remove Programs somehow. You can use the msizap utility to make A/RP forget about your product, but use this only as a last resort. I don't think that's what's going on, because I can still remove the program from ARP afterwards, even though most of the install is gone. Trawling through the UI sources, I found this in VerifyReadDlg.wxs: Control Id=Remove Type=PushButton X=236 Y=243 Width=56 Height=17 Hidden=yes Text=!(loc.VerifyReadyDlgRemove) Condition Action=showWixUI_InstallMode = Remove/Condition Publish Event=Remove Value=All![CDATA[OutOfDiskSpace 1]]/Publish [snip...] /Control However, the msi documentation says the argument for remove is: A string that is either the name of the feature or ALL. Does it matter that the case is wrong? It could be a problem, but its hard to say without debugging it myself in
[WiX-users] Install a Font
Hi I need my installer to install the font Wingdings3 on install Any ideas? Thanks -- View this message in context: http://www.nabble.com/Install-a-Font-tf4717844.html#a13486672 Sent from the wix-users mailing list archive at Nabble.com. - 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] WiX Localization - One Installer to support multiple Languages
The recommended way to do this is to create language transforms and then call the msi from a setup.exe bootstrapper which will pass the correct transform name along as a command line parameter. You'd have to add a dialog in the bootstrapper to choose the language or include the logic to determine the language of the OS. There is no supported way to do this without a bootstrapper (or forcing the user to include the transform name on the command line). This link describes an undocumented ability of windows installer that might work for you: http://www.installsite.org/pages/en/msi/articles/embeddedlang/index.htm Dana On 10/30/07, Sankaranarayanan [EMAIL PROTECTED] wrote: Hi, Currently I am creating Localized WiX installers based on the steps mentioned @ http://www.tramontana.co.hu/wix/lesson2.php#2.4 (WixUI Customization and Localization Combined). Using those steps - I am able to create one installer for specific language. Is there a way to link the wixobj files with different localized language files in the same installer. I would like to have only one installer and its UI should be displayed based on the Language of the Users Operating System. If the Operating System language isn't one of the defeault supported language of the MSI - it should fall back to en-US. Can all supported languages WixUI_XX-XX.wxl file be integrated into the same installer. Thanks, Sankaranarayanan MG ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - 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
Re: [WiX-users] Checkbox does not recognize when it is checked
No it isn't. It will work if I put the box in the UI during the setup and have it checked. If it is placed in the uninstall sequence however it will not acknowledge the box is checked. Bob Arnson-6 wrote: xyavier wrote: boB, It does however bring up my UI when someone clicks the change button in the ARP. My plan was to remove the Remove button so the user would be forced to use my UI which gives them the option to either remove or repair. So, under this situation is there any way to allow them to check the box at the time of removal. Sure. Is it not working? -- sig://boB http://joyofsetup.com/ - 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 -- View this message in context: http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13488280 Sent from the wix-users mailing list archive at Nabble.com. - 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] disabling the features aapeared in the selection tree based on their installation condition.
hi in my product the installation takes place in many modes. there z a set of features in this product. each mode support some mandatory features and some optional fearture. there are some feartures which are not supported in some mode decided by their installation condition. i used absent=disallow to specify mandatory and optional feature. now i want to disable the showing of fetures in selection tree used in custom setup if this feature is not supported in tis particular mode(i.e its installation condition is false). can u suggest me the way to do this. thanx -- View this message in context: http://www.nabble.com/disabling-the-features-aapeared-in-the-selection-tree-based-on-their-installation-condition.-tf4718617.html#a13489176 Sent from the wix-users mailing list archive at Nabble.com. - 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] Maintenance modes SOLVED!
It turns out, the problem was because I was installing a component based on the existence of a file on the end users computer, like this. Property Id=DEPFOUND DirectorySearch Id=deppath Path=[SystemFolder] FileSearch Id=depfile Name=depfile.dll / /DirectorySearch /Property and then later Feature Id=SetDEP Title=Enable DEP Level=0 ComponentRef Id=DepComponent/ Condition Level=1DEPFOUND/Condition /Feature Unfortunately, not marking the property secure caused the behavior shown in my previous messages. Thanks to Bob, for this http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/ which led me in the right direction. I had been using a similar idiom for desktop shortcuts on a tick box, but they didn't seem to need secure. Perhaps it's because they defaulted to on instead of off. Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 11:19 AM Subject: Re: [WiX-users] Maintenance modes (Might be related to old UACPrompt Required thread, April 2007) It gets even stranger. For some reason, it does uninstall properly when I start the msi from an admin command prompt like this: msiexec /i setup.msi /l*vx admin.log but if I start it from a non admin account like this: msiexec /i setuprip.msi /l*vx nonadmin.log it leaves behind the items an admin can't remove. I also notice in the logs, I have these lines in the admin.log file: MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property. Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'. Action ended 10:47:56: InstallValidate. Return value 1. The non admin log is missing the modify of the remove property. I'm using an install sequence based on the wix UI specified like this: Property Id=WixUI_Mode Value=InstallDir / I also notice that in the admin log I have this: MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. while in the non-admin it says: * MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant ** MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. So it looks like it won't do it because it hasn't elevated, which makes sense, because it's a per machine install. So, it's looking like it's not really a WiX problem, but more of an MSI problem. Any ideas? Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 6:47 AM Subject: Re: [WiX-users] Maintenance modes From: Richard [EMAIL PROTECTED] Sent: Monday, October 29, 2007 9:40 PM Subject: Re: [WiX-users] Maintenance modes In article [EMAIL PROTECTED], Anthony Wieser [EMAIL PROTECTED] writes: For some reason my msi file is bringing up the maintenance mode when I double click it. This means its already installed. 1. How do I make sure that only remove is supported. I've already set the property ARPNOMODIFY like this: Property Id=ARPNOMODIFY Value=1 / but I've done it in a UI block. Is that wrong? Put it inside the Product tag. Turns out I got this from the WixUI_InstallDir.wxs file I based it
Re: [WiX-users] Maintenance modes SOLVED!
Would adding 'Or Installed' to the condition work as well? Wouldn't it then remove the file if it's there, and leave it if it isn't? Kelly Anthony Wieser [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 08:00 AM To wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Maintenance modes SOLVED! It turns out, the problem was because I was installing a component based on the existence of a file on the end users computer, like this. Property Id=DEPFOUND DirectorySearch Id=deppath Path=[SystemFolder] FileSearch Id=depfile Name=depfile.dll / /DirectorySearch /Property and then later Feature Id=SetDEP Title=Enable DEP Level=0 ComponentRef Id=DepComponent/ Condition Level=1DEPFOUND/Condition /Feature Unfortunately, not marking the property secure caused the behavior shown in my previous messages. Thanks to Bob, for this http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/ which led me in the right direction. I had been using a similar idiom for desktop shortcuts on a tick box, but they didn't seem to need secure. Perhaps it's because they defaulted to on instead of off. Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 11:19 AM Subject: Re: [WiX-users] Maintenance modes (Might be related to old UACPrompt Required thread, April 2007) It gets even stranger. For some reason, it does uninstall properly when I start the msi from an admin command prompt like this: msiexec /i setup.msi /l*vx admin.log but if I start it from a non admin account like this: msiexec /i setuprip.msi /l*vx nonadmin.log it leaves behind the items an admin can't remove. I also notice in the logs, I have these lines in the admin.log file: MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property. Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'. Action ended 10:47:56: InstallValidate. Return value 1. The non admin log is missing the modify of the remove property. I'm using an install sequence based on the wix UI specified like this: Property Id=WixUI_Mode Value=InstallDir / I also notice that in the admin log I have this: MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. while in the non-admin it says: * MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant ** MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. So it looks like it won't do it because it hasn't elevated, which makes sense, because it's a per machine install. So, it's looking like it's not really a WiX problem, but more of an MSI problem. Any ideas? Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 6:47 AM Subject: Re: [WiX-users] Maintenance modes From: Richard [EMAIL PROTECTED] Sent: Monday, October 29, 2007 9:40 PM Subject: Re: [WiX-users] Maintenance modes In article [EMAIL PROTECTED], Anthony Wieser [EMAIL PROTECTED] writes: For some reason my msi file is bringing up the maintenance mode when I double click it. This
[WiX-users] XmlConfig wix version 2.0.5325.0
If I add the XmlConfig in my wxs my 2 customactions no longer work because the customaction.Installstate can not be found. When I remove the XmlConfig element everything is fine. I need to delete and otherwise manipulate the web config and XmlFile is not enough. Here is the element: XmlConfig Id=someid File=[thewebdir]Web.config Action=delete Sequence=1 VerifyPath=//configuration/myconfiguration Name=myconfiguration ElementPath=//configuration/ Any one? -- View this message in context: http://www.nabble.com/XmlConfig-wix-version-2.0.5325.0-tf4719153.html#a13490732 Sent from the wix-users mailing list archive at Nabble.com. - 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] Maintenance modes SOLVED!
It's not my file. I'm modifying a registry entry based on whether I find a file in the system folder. Anthony Wieser Wieser Software Ltd - Original Message - From: Kelly Leahy To: Anthony Wieser Cc: wix-users@lists.sourceforge.net ; [EMAIL PROTECTED] Sent: Tuesday, October 30, 2007 3:18 PM Subject: Re: [WiX-users] Maintenance modes SOLVED! Would adding 'Or Installed' to the condition work as well? Wouldn't it then remove the file if it's there, and leave it if it isn't? Kelly Anthony Wieser [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 08:00 AM To wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Maintenance modes SOLVED! It turns out, the problem was because I was installing a component based on the existence of a file on the end users computer, like this. Property Id=DEPFOUND DirectorySearch Id=deppath Path=[SystemFolder] FileSearch Id=depfile Name=depfile.dll / /DirectorySearch /Property and then later Feature Id=SetDEP Title=Enable DEP Level=0 ComponentRef Id=DepComponent/ Condition Level=1DEPFOUND/Condition /Feature Unfortunately, not marking the property secure caused the behavior shown in my previous messages. Thanks to Bob, for this http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/ which led me in the right direction. I had been using a similar idiom for desktop shortcuts on a tick box, but they didn't seem to need secure. Perhaps it's because they defaulted to on instead of off. Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 11:19 AM Subject: Re: [WiX-users] Maintenance modes (Might be related to old UACPrompt Required thread, April 2007) It gets even stranger. For some reason, it does uninstall properly when I start the msi from an admin command prompt like this: msiexec /i setup.msi /l*vx admin.log but if I start it from a non admin account like this: msiexec /i setuprip.msi /l*vx nonadmin.log it leaves behind the items an admin can't remove. I also notice in the logs, I have these lines in the admin.log file: MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property. Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'. Action ended 10:47:56: InstallValidate. Return value 1. The non admin log is missing the modify of the remove property. I'm using an install sequence based on the wix UI specified like this: Property Id=WixUI_Mode Value=InstallDir / I also notice that in the admin log I have this: MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. while in the non-admin it says: * MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant ** MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. So it looks like it won't do it because it hasn't elevated, which makes sense, because it's a per
Re: [WiX-users] Install a Font
Craig0ss wrote: I need my installer to install the font Wingdings3 on install Check with its developer to see if they provide a redist: http://www.ascendercorp.com/msfonts/wingdings3.html. -- sig://boB http://joyofsetup.com/ - 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] disabling the features aapeared in the selection tree based on their installation condition.
shambhu kumar wrote: now i want to disable the showing of fetures in selection tree used in custom setup if this feature is not supported in tis particular mode(i.e its installation condition is false). The selection tree control doesn't support that -- features can only be hidden, not disabled, in the control. -- sig://boB http://joyofsetup.com/ - 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] Checkbox does not recognize when it is checked
xyavier wrote: No it isn't. It will work if I put the box in the UI during the setup and have it checked. If it is placed in the uninstall sequence however it will not acknowledge the box is checked. How are you using the check box value? -- sig://boB http://joyofsetup.com/ - 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] Maintenance modes SOLVED!
I just meant that the component wouldn't be excluded on maintenance if you had 'or Installed' regardless of the value of DEPFOUND, but perhaps it wouldn't work. Kelly Anthony Wieser [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 08:41 AM To wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Maintenance modes SOLVED! It's not my file. I'm modifying a registry entry based on whether I find a file in the system folder. Anthony Wieser Wieser Software Ltd - Original Message - From: Kelly Leahy To: Anthony Wieser Cc: wix-users@lists.sourceforge.net ; [EMAIL PROTECTED] Sent: Tuesday, October 30, 2007 3:18 PM Subject: Re: [WiX-users] Maintenance modes SOLVED! Would adding 'Or Installed' to the condition work as well? Wouldn't it then remove the file if it's there, and leave it if it isn't? Kelly Anthony Wieser [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 08:00 AM To wix-users@lists.sourceforge.net cc Subject Re: [WiX-users] Maintenance modes SOLVED! It turns out, the problem was because I was installing a component based on the existence of a file on the end users computer, like this. Property Id=DEPFOUND DirectorySearch Id=deppath Path=[SystemFolder] FileSearch Id=depfile Name=depfile.dll / /DirectorySearch /Property and then later Feature Id=SetDEP Title=Enable DEP Level=0 ComponentRef Id=DepComponent/ Condition Level=1DEPFOUND/Condition /Feature Unfortunately, not marking the property secure caused the behavior shown in my previous messages. Thanks to Bob, for this http://www.joyofsetup.com/2007/05/30/feature-conditions-and-ui/ which led me in the right direction. I had been using a similar idiom for desktop shortcuts on a tick box, but they didn't seem to need secure. Perhaps it's because they defaulted to on instead of off. Anthony Wieser Wieser Software Ltd - Original Message - From: Anthony Wieser [EMAIL PROTECTED] To: wix-users@lists.sourceforge.net Sent: Tuesday, October 30, 2007 11:19 AM Subject: Re: [WiX-users] Maintenance modes (Might be related to old UACPrompt Required thread, April 2007) It gets even stranger. For some reason, it does uninstall properly when I start the msi from an admin command prompt like this: msiexec /i setup.msi /l*vx admin.log but if I start it from a non admin account like this: msiexec /i setuprip.msi /l*vx nonadmin.log it leaves behind the items an admin can't remove. I also notice in the logs, I have these lines in the admin.log file: MSI (s) (10:1C) [10:47:56:521]: PROPERTY CHANGE: Modifying CostingComplete property. Its current value is '0'. Its new value: '1'. MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: BindImage MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: ProgId MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: PublishComponent MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: SelfReg MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Extension MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Font MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2205 2: 3: Class MSI (s) (10:1C) [10:47:56:521]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: Note: 1: 2727 2: MSI (s) (10:1C) [10:47:56:536]: PROPERTY CHANGE: Modifying REMOVE property. Its current value is 'DesktopShortcut,ProductFeature'. Its new value: 'ALL'. Action ended 10:47:56: InstallValidate. Return value 1. The non admin log is missing the modify of the remove property. I'm using an install sequence based on the wix UI specified like this: Property Id=WixUI_Mode Value=InstallDir / I also notice that in the admin log I have this: MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting AdminUser property to 1 because this is the client or the user has already permitted elevation MSI (c) (64:0C) [10:47:51:357]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (c) (64:0C) [10:47:51:357]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. while in the non-admin it says: * MSI (s) (10:3C) [10:33:37:592]: MSI_LUA: Credential prompt is not required at this point, product is managed and deployment compliant ** MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting AdminUser property to 1 because the product is already installed managed and per-machine MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding AdminUser property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: MSI_LUA: Setting MsiRunningElevated property to 1 because the install is already running elevated. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding MsiRunningElevated property. Its value is '1'. MSI (s) (10:3C) [10:33:37:654]: PROPERTY CHANGE: Adding Privileged property. Its value is '1'. So it looks like it won't do
Re: [WiX-users] MMC Snapin
Hi. Thanks for the reply. But isn't it true that the DLL itself should be registered, since the .MSC acts as a configuration/shortcut to the actual snap-in, which resides in a DLL. I deployed the MSC, but I am just getting Snap-in failed to initialize and Snap-in creation failed messages when I run it. Anyway, I tried to register the DLL manually with RegAsm mySnapIn.dll /codebase, but I am getting an Action canceled page in the area where snap-in should be displayed. Any comments are appreciated. -Original Message- From: Chad Petersen [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 9:36 To: Levon Levonian; Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MMC Snapin We use an MMC snap-in in one of our applications. I may be simplifying this too much, but entry point to a Snap-In is the .MSC file. We deposit the .MSC in the Deploy directory of choice and create a shortcut to the .MSC. Component Id=DeployMSCComp Guid=1ED23462-B5B7-42af-B86A-BF4CB1E86BB6 File Id=DeployMSC Name=INTERL~1.MSC LongName=Interlinq E3 Deployment Manager.msc src=.\Data\Interlinq E3 Deployment Manager 2.6.msc Vital=yes KeyPath=yes DiskId=1 Shortcut Id=DeployMSCShortCut Directory=MENUINTERLINQ Name=E3Depl~2 LongName=Interlinq E3 Deployment Manager Icon=DEPLOYICON IconIndex=0 Show=normal WorkingDirectory=DEPLOYDIR / /File /Component The rest of the supporting DLLs and scripts, etc. that are needed by the Snap-In also go in the same folder and a registry key association is made to the resource dll that references the MSC file. File Id=E3DeployManagerResources_Dll Name=E3R~1.dll LongName=E3DeployManagerResource.dll src=.\Data\E3DeployManagerResource.dll Vital=yes DiskId=1/ Registry Id=DeployLocationKey Root=HKCU Key=Software\HarlandFS\E3Deploy Name=MSC Value=[#DeployMSC] Type=string/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levon Levonian Sent: Friday, October 26, 2007 4:31 PM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MMC Snapin OK, I got the extension name, but: None of the WiX v3 packages contains WixMMCExtension, I only found it in v2, but v3 does not load v2 extensions (Error The extension 'C:\Program Files\Windows Installer XML v3\bin\WixMMCExtension.dll' could not be loaded.candle.exe) Anybody has a working example for Snap-in deployment? Thanks! -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, October 25, 2007 19:57 To: Levon Levonian Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MMC Snapin There is an extension in WiX v3 that handles much of the authoring work for you. Levon Levonian wrote: Hi All, Is there a (easy) way to deploy an MMC Snap-in? ** READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be corrupted, incomplete, misdirected or may incorrectly identify the sender. Therefore, nothing in this message or attachments may be considered legally binding. THIS MESSAGE IS ONLY INTENDED FOR THE USE OF THE INDIVIDUAL OR ENTITY TO WHICH IT IS ADDRESSED AND MAY BE PRIVILEGED. If you are not the intended recipient or their authorized agent, you may not forward or copy this information and must delete or destroy all copies of this message and attachments received. If you have received this communication in error, please notify Matrikon Inc. by telephone at (780) 448-1010. ** - 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] Checkbox does not recognize when it is checked
In article [EMAIL PROTECTED], xyavier [EMAIL PROTECTED] writes: No it isn't. It will work if I put the box in the UI during the setup and have it checked. If it is placed in the uninstall sequence however it will not acknowledge the box is checked. OK, you know there's no such thing as the uninstall sequence, right? There's a UI sequence that is used when a full UI is shown and there's an execute sequence that is always used. Changes to properties are not stored in the MSI during installation; you have to persist properties elsewhere if you want them to remember the changed value set during installation at the time of uninstallation. A common way to do this is to persist properties into the registry and use AppSearch to get them back out of the registry and into a property. CheckBoxes toggle a property's value between empty and the value listed in the CheckBox table. Are you trying to set your property to something *other* than what's in the CheckBox table? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Managed Custom Action using InstallUtilLib.dll
In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Checkbox does not recognize when it is checked
This is how it is set up -- Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400' Height='18' Property='DELALL' CheckBoxValue=1 TextCheck the box to Delete extensibility.dll/Text /Control Control Id='RemoveNow' Type='PushButton' X='276' Y='210' Width='90' Height='18' Default='yes' Text![CDATA[{\Tahoma10}Remove Now]]/Text /Control --- Component Id='MyComponent' Guid='BLah BLah BLah-123456789012' Condition DELALL = 1 /Condition RemoveFile Id='LogFile' On='uninstall' Name='*.*' / RemoveFolder Id='TheDir' On='uninstall'/ /Component - Mark xyavier wrote: No it isn't. It will work if I put the box in the UI during the setup and have it checked. If it is placed in the uninstall sequence however it will not acknowledge the box is checked. Bob Arnson-6 wrote: xyavier wrote: boB, It does however bring up my UI when someone clicks the change button in the ARP. My plan was to remove the Remove button so the user would be forced to use my UI which gives them the option to either remove or repair. So, under this situation is there any way to allow them to check the box at the time of removal. Sure. Is it not working? -- sig://boB http://joyofsetup.com/ - 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 -- View this message in context: http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13491613 Sent from the wix-users mailing list archive at Nabble.com. - 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] Checkbox does not recognize when it is checked
This is how it is set up -- Control Id='All_Files' Type='CheckBox' X='10' Y='30' Width='400' Height='18' Property='DELALL' CheckBoxValue=1 TextCheck the box to Delete extensibility.dll/Text /Control Control Id='RemoveNow' Type='PushButton' X='276' Y='210' Width='90' Height='18' Default='yes' Text![CDATA[{\Tahoma10}Remove Now]]/Text /Control --- Component Id='MyComponent' Guid='BLah BLah BLah-123456789012' Condition DELALL = 1 /Condition RemoveFile Id='LogFile' On='uninstall' Name='*.*' / RemoveFolder Id='TheDir' On='uninstall'/ /Component - Mark Bob Arnson-6 wrote: xyavier wrote: No it isn't. It will work if I put the box in the UI during the setup and have it checked. If it is placed in the uninstall sequence however it will not acknowledge the box is checked. How are you using the check box value? -- sig://boB http://joyofsetup.com/ - 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 -- View this message in context: http://www.nabble.com/Checkbox-does-not-recognize-when-it-is-checked-tf4683976.html#a13492385 Sent from the wix-users mailing list archive at Nabble.com. - 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] Managed Custom Action using InstallUtilLib.dll
I use custom action for the following operations 1) Read XML Config file and set installer properties 2) Install Device Drivers 3) Loading MOF 4) Setting Windows Service privileges 5) Installing .NET Perf Counters. etc... WiX doesn't support these actions by default. Please let know if you have any approach for the following issue : I am using Managed Custom Action as details in http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx This approach works like a charm but I didn't quite like the idea of packaging InstallUtilLib.dll file in MSI. Is there a way to use the InstallUtilLib.dll present in the client machine instead of packing it in MSI Binary table as follows Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /. (I have a Lauch Condition to check for .NET Framework presence in the client machine). Thanks, Sankaranarayanan MG - Original Message From: Richard [EMAIL PROTECTED] To: WiX Users wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Sent: Tuesday, 30 October, 2007 10:03:10 AM Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - 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] Help with Major Upgrade
I am packaging an MSI that I would like to have perform a Major Upgrade when deployed on a machine with an older version of said package already installed. My setup: * Product Id is set to ---- * Upgrade Code is set to some GUID which does not change * The Upgrade clause is set to Upgrade Id=some GUID UpgradeVersion Minimum=$(var.VERSION) OnlyDetect=yes Property=NEWERVERSIONDETECTED / UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes Maximum=$(var.VERSION) IncludeMaximum=no Property=OLDERVERSIONBEINGUPGRADED / /Upgrade Where var.VERSION is our major.minor.micro.build version number. * InstallExecuteSequence contains the following entries: RemoveExistingProducts After=InstallFinalize/ * The package launches an application upon installation. Scenarios: * Install version 1 of package, Install version 2 of package. Version 2 install notices that version 1 is running and asks for it to be shut down. User complies and the install completes normally. Version 2 is the only package that appears in Add/Remove Programs. * Install version 1 of package, Install version 2 of package. When asked to shut down running copy of version 1, User hits the Exit button. Install informs user that their system was not modified and exits. Both versions now appear in Add/Remove Programs. When the application is next launched it is version 2. In the second scenario the install of Version 2 should roll back and exit as the UI implies. What do I need to do for this to happen? Failing that how can I prevent scenario 2? - 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] Sharing a folder with group permissions
I am trying to share a directory to a group of users rather than a particular user, i.e. the Administrators group on the local machine ([ComputerName]\Administrators). However, the Permission element within a FileShare must point to a User. From the Tramontana tutorial, you can set the User's Name property = Everyone and it'll share the folder under the Everyone group, but I can't get it to share under any other group (I get a error saying user not found): Component Id=SharedComponent ... FileShare Id=SharedFileShare Name=MyFolder Description=MyFolder Permission User=sharedusers GenericAll=yes / /FileShare User Id=sharedusers CreateUser=yes Name=Administrators Domain=[ComputerName] FailIfExists=no GroupRef Id=AdminGroup / /User /Component ... Group Id=AdminGroup Name=Administrators Domain=[ComputerName] / Any help would be appreciated, thanks. -- View this message in context: http://www.nabble.com/Sharing-a-folder-with-group-permissions-tf4719928.html#a13493201 Sent from the wix-users mailing list archive at Nabble.com. - 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] Wix v3 certificate installation bug?
It appears that the Wix Certificate file-based installation and the Overwrite option are currently incompatible. If a Certificate element is configured with Request=no and Overwrite=yes and CertificatePath=PathToCertificateFile, installation will fail. The error logged is Invalid Certificate.Attributes Is this intentional and simply undocumented that the Overwrite and file-based options are incompatible, or is this a bug? Thanks, John Hancock - 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] Help with Major Upgrade
The problem is the sequencing. By the time InstallFinalize has happened, the install is already committed, so you can't roll back the install of version 2, at least if I'm understanding it correctly. You probably want your RemoveExistingProducts to be somewhere earlier in the sequence, so that it can cause a rollback of version 2's install if version 1's uninstall fails. There are problems with all placements of this action, however, so you should decide what is the worst of your evils. If you have Phil Wilson's book, it describes the pros and cons of the different placements of RemoveExistingProducts. I don't have it here at work with me - it's sitting on my desk at home - otherwise I'd look it up and recommend alternatives for you. Kelly Ted Berg [EMAIL PROTECTED] Sent by: [EMAIL PROTECTED] 10/30/2007 11:50 AM To wix-users@lists.sourceforge.net cc Subject [WiX-users] Help with Major Upgrade I am packaging an MSI that I would like to have perform a Major Upgrade when deployed on a machine with an older version of said package already installed. My setup: * Product Id is set to ---- * Upgrade Code is set to some GUID which does not change * The Upgrade clause is set to Upgrade Id=some GUID UpgradeVersion Minimum=$(var.VERSION) OnlyDetect=yes Property=NEWERVERSIONDETECTED / UpgradeVersion Minimum=1.0.0.0 IncludeMinimum=yes Maximum=$(var.VERSION) IncludeMaximum=no Property=OLDERVERSIONBEINGUPGRADED / /Upgrade Where var.VERSION is our major.minor.micro.build version number. * InstallExecuteSequence contains the following entries: RemoveExistingProducts After=InstallFinalize/ * The package launches an application upon installation. Scenarios: * Install version 1 of package, Install version 2 of package. Version 2 install notices that version 1 is running and asks for it to be shut down. User complies and the install completes normally. Version 2 is the only package that appears in Add/Remove Programs. * Install version 1 of package, Install version 2 of package. When asked to shut down running copy of version 1, User hits the Exit button. Install informs user that their system was not modified and exits. Both versions now appear in Add/Remove Programs. When the application is next launched it is version 2. In the second scenario the install of Version 2 should roll back and exit as the UI implies. What do I need to do for this to happen? Failing that how can I prevent scenario 2? - 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] start and stop services
I have used the ServiceControl element as below: ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both' Stop='uninstall'/ I have logged on as Administrator and XYZ AdminConsole is running. Now if I run my MSI package, it is failing and showing: Service 'XYZ AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have sufficient preveledges to start system services. Do you have any idea about? Thanks! Richard-45 wrote: In article [EMAIL PROTECTED], shapla [EMAIL PROTECTED] writes: 1. Restart this service after installing my MSI 2. My MSI will remove some files during uninstall and I want to: 2.1 Stop this service before removing the files and 2.2 Start it again after removing the files. How can I do this? Please let me know if you have any idea. Look at the ServiceControl element. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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 -- View this message in context: http://www.nabble.com/start-and-stop-services-tf4715721.html#a13494802 Sent from the wix-users mailing list archive at Nabble.com. - 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] WiX 3.0 post 3304 working for anyone?
Whenever I run a tool in version 3307, 3328 or 3419 builds obtained from wix.sourceforge.net/releases, I get a System.IO.FileLoadException (0x80131040) saying that the wix assembly could not be loaded. Turning on the binding logging gives this information: === Pre-bind state information === LOG: User = ***removed*** LOG: DisplayName = wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad (Fully-specified) LOG: Appbase = file:///C:/Tools/wix3-binaries3328/ LOG: Initial PrivatePath = NULL Calling assembly : candle, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad. === LOG: This bind starts in default load context. LOG: Using application configuration file: C:\Tools\wix3-binaries3328\candle.exe.Config LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\config\machine.config. LOG: Post-policy reference: wix, Version=3.0.3328.0, Culture=neutral, PublicKeyToken=ce35f76fcda82bad LOG: Attempting download of new URL file:///C:/Tools/wix3-binaries3328/wix.DLL. WRN: Comparing the assembly name resulted in the mismatch: PUBLIC KEY TOKEN ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated. This suggests that the public key token of wix.dll isn't what candle.exe is asking for. Loading the files into Reflector (www.aisto.com/roeder/dotnet) shows that wix.dll has a public key token of 9f4be179981a58d1. Is this working for anyone else? I can't imagine how it could be, but before I put a bug in the tracker I wanted to be sure. -- Mike Dimmick - 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] MMC Snapin
I thought I'd sent a message on this one but must have deleted a draft. There are two sorts of MMC snap-in: MMC 3.0 only: .NET 2.0 classes which inherit Microsoft.ManagementConsole.SnapIn All versions: COM objects which implement IComponent and IcomponentData (not to be confused, in .NET, with System.ComponentModel.IComponent). The former sort can be registered with registry keys under HKLM\Software\Microsoft\MMC\SnapIns. The documentation tells you to use a .NET Installer class but that's a bad plan - managed custom actions are officially not supported (I wish the Framework team would just mark the damned thing Deprecated and work out a way to achieve their install tasks WITHOUT doing something unsupported by Windows Installer). WixMMCExtension in v2 handles only MMC 3.0 .NET snap-ins. It is a pure extension in that it only generates Registry rows, rather than requiring any custom actions. It could be ported to WiX v3 fairly easily, I think. The latter sort are simply COM objects and should be registered in the same way as any other .NET objects registered for COM interop, if you have written it using .NET. Heat is able to handle this (if you're running as an administrator, anyway - if not, it just generates the File element in 3.0.3304.0). However Heat will only generate the COM registration - it won't generate the snap-in registration. You'll need to add your own Registry elements to do this. The registry entries you need to create can be found at http://msdn2.microsoft.com/en-us/library/aa815156.aspx. Adding the snap-in to a console (.msc) file is then straightforwardly done through the MMC user interface. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levon Levonian Sent: 30 October 2007 16:15 To: Chad Petersen; Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MMC Snapin Hi. Thanks for the reply. But isn't it true that the DLL itself should be registered, since the .MSC acts as a configuration/shortcut to the actual snap-in, which resides in a DLL. I deployed the MSC, but I am just getting Snap-in failed to initialize and Snap-in creation failed messages when I run it. Anyway, I tried to register the DLL manually with RegAsm mySnapIn.dll /codebase, but I am getting an Action canceled page in the area where snap-in should be displayed. Any comments are appreciated. -Original Message- From: Chad Petersen [mailto:[EMAIL PROTECTED] Sent: Monday, October 29, 2007 9:36 To: Levon Levonian; Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: RE: [WiX-users] MMC Snapin We use an MMC snap-in in one of our applications. I may be simplifying this too much, but entry point to a Snap-In is the .MSC file. We deposit the .MSC in the Deploy directory of choice and create a shortcut to the .MSC. Component Id=DeployMSCComp Guid=1ED23462-B5B7-42af-B86A-BF4CB1E86BB6 File Id=DeployMSC Name=INTERL~1.MSC LongName=Interlinq E3 Deployment Manager.msc src=.\Data\Interlinq E3 Deployment Manager 2.6.msc Vital=yes KeyPath=yes DiskId=1 Shortcut Id=DeployMSCShortCut Directory=MENUINTERLINQ Name=E3Depl~2 LongName=Interlinq E3 Deployment Manager Icon=DEPLOYICON IconIndex=0 Show=normal WorkingDirectory=DEPLOYDIR / /File /Component The rest of the supporting DLLs and scripts, etc. that are needed by the Snap-In also go in the same folder and a registry key association is made to the resource dll that references the MSC file. File Id=E3DeployManagerResources_Dll Name=E3R~1.dll LongName=E3DeployManagerResource.dll src=.\Data\E3DeployManagerResource.dll Vital=yes DiskId=1/ Registry Id=DeployLocationKey Root=HKCU Key=Software\HarlandFS\E3Deploy Name=MSC Value=[#DeployMSC] Type=string/ -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Levon Levonian Sent: Friday, October 26, 2007 4:31 PM To: Rob Mensching Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MMC Snapin OK, I got the extension name, but: None of the WiX v3 packages contains WixMMCExtension, I only found it in v2, but v3 does not load v2 extensions (Error The extension 'C:\Program Files\Windows Installer XML v3\bin\WixMMCExtension.dll' could not be loaded.candle.exe) Anybody has a working example for Snap-in deployment? Thanks! -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Thursday, October 25, 2007 19:57 To: Levon Levonian Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] MMC Snapin There is an extension in WiX v3 that handles much of the authoring work for you. Levon Levonian wrote: Hi All, Is there a (easy) way to deploy an MMC Snap-in? ** READER BEWARE: Unencrypted, unsigned Internet e-mail is inherently insecure. Internet messages may be
Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll
Managed custom actions are officially unsupported by Windows Installer because of the way that the CLR 'taints' the process it loads into. You cannot reliably ensure that the correct CLR version is loaded at the correct time. See Rob's blog post http://robmensching.com/blog/archive/2007/04/19/Managed-Code-CustomActions-n o-support-on-the-way-and-heres.aspx. Yes, it's seriously annoying that the .NET Framework and Visual Studio guide you in the direction of a bad design. The whole Installer hierarchy (and especially ServiceInstaller which duplicates Windows Installer functionality) should be marked Deprecated in my view. What can you do? Unfortunately, the most reliable form of custom actions are native C/C++ DLLs. However, if you can write device drivers I would have thought you could write custom action DLLs. WiX does have support for .NET performance counters in v3 using the PerformanceCategory and PerformanceCounter elements in the Util schema. This is certainly present in build 3304. For v2 you will have to write an appropriate .h and .ini file and use the PerfCounter element. You can use the code for the ParsePerformanceCategoryElement method in v3 - which basically generates the .h and .ini files and dumps them into a custom table - as a template. See src\ext\UtilExtension\UtilCompiler.cs in the source distribution. .NET Framework doesn't provide a way to do this (well, it does, but only if you're prepared to use reflection to invoke it because the members are private). Wix's support currently won't work on NT 4.0 because the APIs LoadPerfCounterTextStrings and UnLoadPerCounterTextStrings are used, not the lodctr.exe program. The APIs were added in Windows 2000. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sankaranarayanan Sent: 30 October 2007 18:36 To: Richard; WiX Users Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll I use custom action for the following operations 1) Read XML Config file and set installer properties 2) Install Device Drivers 3) Loading MOF 4) Setting Windows Service privileges 5) Installing .NET Perf Counters. etc... WiX doesn't support these actions by default. Please let know if you have any approach for the following issue : I am using Managed Custom Action as details in http://blogs.msdn.com/josealmeida/archive/2004/11/08/253831.aspx This approach works like a charm but I didn't quite like the idea of packaging InstallUtilLib.dll file in MSI. Is there a way to use the InstallUtilLib.dll present in the client machine instead of packing it in MSI Binary table as follows Binary Id=InstallUtil src=$(var.FrameworkPath)\InstallUtilLib.dll /. (I have a Lauch Condition to check for .NET Framework presence in the client machine). Thanks, Sankaranarayanan MG - Original Message From: Richard [EMAIL PROTECTED] To: WiX Users wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Sent: Tuesday, 30 October, 2007 10:03:10 AM Subject: Re: [WiX-users] Managed Custom Action using InstallUtilLib.dll In article [EMAIL PROTECTED], Sankaranarayanan [EMAIL PROTECTED] writes: I am using Managed Custom Action [...] What is your custom action doing? The MSDN documentation leads people to believe that they need managed custom actions for all sorts of things that the standard actions and tables already cover. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ ___ Want ideas for reducing your carbon footprint? Visit Yahoo! For Good http://uk.promotions.yahoo.com/forgood/environment.html - 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
Re: [WiX-users] Help with Major Upgrade
In article [EMAIL PROTECTED], Kelly Leahy [EMAIL PROTECTED] writes: The problem is the sequencing. By the time InstallFinalize has happened, the install is already committed, so you can't roll back the install of version 2, at least if I'm understanding it correctly. You probably want your RemoveExistingProducts to be somewhere earlier in the sequence, so that it can cause a rollback of version 2's install if version 1's uninstall fails. I always recommend putting RemoveExistingProducts right after InstallInitialize. This wraps the entire upgrade in a transaction. If the transaction fails, then the new version is removed and the old version is restored. This requires that you author appropriate rollback support in your custom actions, but you should be doing that anyway. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] start and stop services
In article [EMAIL PROTECTED], shapla [EMAIL PROTECTED] writes: I have used the ServiceControl element as below: ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both' Stop='uninstall'/ But didn't you say you wanted to *restart* the service? The calls for a stop and a start. I have logged on as Administrator and XYZ AdminConsole is running. Now if I run my MSI package, it is failing and showing: Service 'XYZ AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have sufficient preveledges to start system services. Do you have any idea about? Windows Installer is essentially just doing a net stop svc to stop a service and a net start svc to start a service. It uses a default timeout of 30 seconds, IIRC. You can adjust the timeout if a service is particularly slow to start. Basically, Windows Installer is just doing what you asked of it here; it doesn't know why a service didn't start. You'll have to look more into the service itself to identify why it didn't start. The Verify that... message is just a catch all warning for the common problem of not having sufficient privileges to control the service. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Install a Font
See http://www.microsoft.com/typography/fonts/font.aspx?FID=39FNAME=Wingdings%2 03FVER=1.55 for a list of Microsoft products that this font ships with. If you can rely on one of these being installed, you won't need to ship it yourself. This table doesn't appear to have been updated for the 2007 products (Windows Vista, Office 2007). If installing your own font, you simply set the FontTitle attribute of the File element that carries the font file. See Font Table in the SDK for more information (http://msdn2.microsoft.com/en-us/library/aa368606.aspx). The normal rules apply - if there is a known component GUID for this file, you should use that (typically with a merge module or the third party's own installer), if not, I would set SharedDllRefCount to ensure that it's not removed prematurely. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Bob Arnson Sent: 30 October 2007 16:19 To: Craig0ss Cc: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Install a Font Craig0ss wrote: I need my installer to install the font Wingdings3 on install Check with its developer to see if they provide a redist: http://www.ascendercorp.com/msfonts/wingdings3.html. -- sig://boB http://joyofsetup.com/ - 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
Re: [WiX-users] Checkbox does not recognize when it is checked
In article [EMAIL PROTECTED], xyavier [EMAIL PROTECTED] writes: This is how it is set up Well, I think you're going to have to dig into log files and your MSI with Orca instead of just relying upon inspection of WiX fragments to debug this problem. Have you tried that? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] adding mimemap to Webvirtualdir
iis:MimeMap is only for setting the MIME type for a given file extension. This governs what IIS will send in the Content-Type header for static web content. It sounds like you need to add an ISAPI filter and as far as I can see, you need to do this with a WebApplicationExtension element. I'm no expert on website configuration, though. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: 30 October 2007 10:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] adding mimemap to Webvirtualdir Hi all, I want to know how the iis:mimemap tag works, it seems to need an id but do not know how to add an MIME element although in the helpfile is written that it schould be child of Wix tag. Second thing is that I want to add a wildcard mime (after I know how to add a MIME to a webvirtualdir) like *,C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\aspnet_isapi.dll,0,All or is it better to call a vbscript instead? Thanks Peter - 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] WiX Localization - One Installer to support multipleLanguages
A given package can only be localized into one language. One approach that you can take to save space is to ship the package in one language with a number of transforms (.mst) which, when applied, translate the package into other languages. Microsoft have used this approach before and it's the recommended one in the SDK. See Localizing a Windows Installer Package at http://msdn2.microsoft.com/en-us/library/aa369769.aspx. -- Mike Dimmick -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Sankaranarayanan Sent: 30 October 2007 06:16 To: wix-users@lists.sourceforge.net Cc: [EMAIL PROTECTED] Subject: [WiX-users] WiX Localization - One Installer to support multipleLanguages Hi, Currently I am creating Localized WiX installers based on the steps mentioned @ http://www.tramontana.co.hu/wix/lesson2.php#2.4 (WixUI Customization and Localization Combined). Using those steps - I am able to create one installer for specific language. Is there a way to link the wixobj files with different localized language files in the same installer. I would like to have only one installer and its UI should be displayed based on the Language of the Users Operating System. If the Operating System language isn't one of the defeault supported language of the MSI - it should fall back to en-US. Can all supported languages WixUI_XX-XX.wxl file be integrated into the same installer. Thanks, Sankaranarayanan MG ___ Yahoo! Answers - Got a question? Someone out there knows the answer. Try it now. http://uk.answers.yahoo.com/ - 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
Re: [WiX-users] WiX Localization - One Installer to support multipleLanguages
In article [EMAIL PROTECTED], Mike Dimmick [EMAIL PROTECTED] writes: [...] Microsoft have used this approach before and it's the recommended one in the SDK. See Localizing a Windows Installer Package at http://msdn2.microsoft.com/en-us/library/aa369769.aspx. This thread had me looking at localization support in Windows Installer again and I can't find on this page where it talks about transforms or recommends using a bootstrapper with transforms as the way to localize a package. I know InstallSUCK does it this way, but I thought that Windows Installer allowed you to embed multiple language transforms into the package and apply one based on the system language? Someone (you, perhaps?) referenced an InstallSite article that described this process but noted that it was unsupported. This seems the reverse of what I remember reading in the SDK documentation, but I'm getting old now :-). -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Custom actions launched from .MSM files
The INSTALLDIR property will be modularized by WiX when building the MSM, so when the final package is executed, [INSTALLDIR] will not evaluate to the place you thought it would. If it's a file you're installing, using [#fileid] is a better option than forming the path yourself. See the documentation for the Formatted data type (at http://msdn2.microsoft.com/en-us/library/aa368609.aspx). Generally you should keep all your components in a merge module in a hierarchy under TARGETDIR. When the merge occurs, this is rewritten to be the Directory the Merge element appears under. Finally, if both producer (MSM) and consumer (MSI) are WiX projects you may find Fragments easier to handle. WiX is like C++ in that it has a compiler (candle) and a linker (light). Candle checks syntax and flattens your XML into tables (the output is still XML but in a flattened form), light links up the rows from multiple inputs into complete tables and resolves references from one fragment to another. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elena Diaconu Sent: 29 October 2007 22:17 To: 'Mike Dimmick'; wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Custom actions launched from .MSM files Hi Mike, Thank you for the answer; but I think the property is in the same file; this is the XML sequence which works fine in the .MSI: CustomAction Id=CAPCInstall.Command Property=QtExecCmdLine Value=quot;[INSTALLDIR]AppSecInc.Performance.CAInstaller.exequot;/ CustomAction Id=CAPCInstall BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check / Binary Id=wixca SourceFile=$(var.WIX_DIR)\wixca.dll / CustomAction Id=CAPCUnInstall.Command Property=QtExecCmdLine Value=quot;[INSTALLDIR]AppSecInc.Performance.CAInstaller.exequot; 1/ CustomAction Id=CAPCUnInstall BinaryKey=wixca DllEntry=CAQuietExec Execute=immediate Return=check/ InstallExecuteSequence Custom Action=CAPCInstall.Command After=RegisterProduct/Custom Custom Action=CAPCInstall After=CAPCInstall.Command/Custom Custom Action=CAPCUnInstall.Command Before=RegisterProductInstalled/Custom Custom Action=CAPCUnInstall After=CAPCUnInstall.CommandInstalled/Custom /InstallExecuteSequence Do you think I forgot to add something, or is there anything to do with [INSTALLDIR], and how the WIX replaces the [INSTALLDIR] string? I also hardcoded the EXE path in the .MSM file (in Value) and I am getting the same error. My WIX version is 3.0. Thank you, Elena _ From: Mike Dimmick [mailto:[EMAIL PROTECTED] Sent: 2007-Oct-29 Mon 5:57 PM To: 'Elena Diaconu'; wix-users@lists.sourceforge.net Subject: RE: [WiX-users] Custom actions launched from .MSM files Deferred custom actions get their instructions on what to do from a property named the same as the custom action itself, which in the CA code itself is the CustomActionData property. When you include something in a module, by default its identifier is modularized, that is, a GUID is added after the identifier you specify. This is to prevent name clashes between different modules and between a module and the installer. I'm guessing that the custom action itself is being modularized - you can see this below - but the property isn't, or the property is in a different module to the CA. -- Mike Dimmick _ From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Elena Diaconu Sent: 29 October 2007 16:05 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Custom actions launched from .MSM files Dear WIX users, I have a problem when I am trying to launch an executable through a Custom Action from an .MSM file: the WIX installation fails. When the executable is launched from an .MSI file everything works fine. So is launching executables through Custom Actions from .MSM files supposed to work or not? Below it is the errors log sequence: MSI (s) (1C:58) [18:03:58:968]: Doing action: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731 Action 18:03:58: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731. Action start 18:03:58: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731. MSI (s) (1C:A0) [18:03:58:984]: Invoking remote custom action. DLL: C:\WINDOWS\Installer\MSIADF.tmp, Entrypoint: CAQuietExec CAQuietExec: Error 0x80070057: failed to get command line data CAQuietExec: Error 0x80070057: failed to get Command Line Action ended 18:03:59: QtExec.412198FF_0AE9_4CB8_889D_53756DDAC731. Return value 3. Action ended 18:03:59: INSTALL. Return value 3. Thank you, I appreciate your answer(s), Elena Elena Diaconu Sr. Software Engineer, Application Security Inc. appsecinc.com http://www.appsecinc.com/ - This SF.net email is sponsored by: Splunk Inc. Still grepping through log files to find problems? Stop. Now Search log events and configuration
Re: [WiX-users] start and stop services
I have tried like below just to stop a service: ServiceControl Id='PMService' Name='XYZ AdminConsole' Stop='install' Wait='yes'/ Installation goes on without any error, but the service is not stopped. I can stop the same service from command prompt(net stop XYZ AdminConsole) Any idea? Thanks! Richard-45 wrote: In article [EMAIL PROTECTED], shapla [EMAIL PROTECTED] writes: I have used the ServiceControl element as below: ServiceControl Id='ADService' Name='XYZ AdminConsole' Start='both' Stop='uninstall'/ But didn't you say you wanted to *restart* the service? The calls for a stop and a start. I have logged on as Administrator and XYZ AdminConsole is running. Now if I run my MSI package, it is failing and showing: Service 'XYZ AdminConsole'(XYZ AdminConsole) failed to start. Verify that you have sufficient preveledges to start system services. Do you have any idea about? Windows Installer is essentially just doing a net stop svc to stop a service and a net start svc to start a service. It uses a default timeout of 30 seconds, IIRC. You can adjust the timeout if a service is particularly slow to start. Basically, Windows Installer is just doing what you asked of it here; it doesn't know why a service didn't start. You'll have to look more into the service itself to identify why it didn't start. The Verify that... message is just a catch all warning for the common problem of not having sufficient privileges to control the service. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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 -- View this message in context: http://www.nabble.com/start-and-stop-services-tf4715721.html#a13501470 Sent from the wix-users mailing list archive at Nabble.com. - 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] start and stop services
In article [EMAIL PROTECTED], shapla [EMAIL PROTECTED] writes: Any idea? What does the log say? -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Managed Custom Action using InstallUtilLib.dll
In article [EMAIL PROTECTED], Aris Green [EMAIL PROTECTED] writes: I have been using managec C++ CA's coded in Visual Studio 2003 for installs. IMO, you might as well just use native C++ at that point. Well, you get the picture. One wrinkle, the VC 2005 requires linking to the C++ CRT as a DLL when using .NET. You have to use a manifest when linking to the CRT, so if the same exact version that you built against in your CA is not on the target machine, BAM!. You still tattoo your process using this technique, though. -- The Direct3D Graphics Pipeline -- DirectX 9 draft available for download http://www.xmission.com/~legalize/book/download/index.html Legalize Adulthood! http://blogs.xmission.com/legalize/ - 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] Wix v3 certificate installation bug?
[dropping wix-devs] John Hancock (HSG) wrote: It appears that the Wix Certificate file-based installation and the Overwrite option are currently incompatible. If a Certificate element is configured with Request=no and Overwrite=yes and CertificatePath=PathToCertificateFile, installation will fail. The error logged is Invalid Certificate.Attributes Is this intentional and simply undocumented that the Overwrite and file-based options are incompatible, or is this a bug? There's a bug there, but also a missing implementation: Overwrite currently does nothing. (Its only mention is commented out in scacert.cpp.) -- sig://boB http://joyofsetup.com/ - 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] Managed Custom Action using InstallUtilLib.dll
I have been using managec C++ CA's coded in Visual Studio 2003 for installs. You create a .NET dll and use unmanaged exports .e.g __declspec(dllexport) int __stdcall MyCustomAction(MSIHANDLE hInstall); All your logic is in the installation package and you don't have to leave a carcass behind with the installed product as you do when using installutil. Well, you get the picture. One wrinkle, the VC 2005 requires linking to the C++ CRT as a DLL when using .NET. You have to use a manifest when linking to the CRT, so if the same exact version that you built against in your CA is not on the target machine, BAM!. You might try writing the CA code in VB .NET, or C#, decompile to IL, augment your class with a static method using an unmanaged export in pure IL, and recompile. I have played around with this a bit in .NET 1.1. Since I am upgrading an installed product for 1.1 to 2.0, I am seriously going to consider this as the C++ CRT DLL with its manifests is one strapping headache, or I might just try to do everything in native code. One thing you can do, which I've done before, is to create a native DLL that embeds the managed assembly as a resource. Extract the assembly, host the CLR in native code, and run your CA. - 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] Checkbox does not recognize when it is checked
xyavier wrote: Component Id='MyComponent' Guid='BLah BLah BLah-123456789012' Condition DELALL = 1 /Condition RemoveFile Id='LogFile' On='uninstall' Name='*.*' / RemoveFolder Id='TheDir' On='uninstall'/ /Component That's not going to work the way you want. RemoveFile and RemoveFolder work on uninstall when the component itself is being uninstalled. That means it has to be installed in the first place, which it won't be, because you have a condition on it that won't be true during install. The easiest way to get what you want is probably via a custom action that adds temporary rows to the RemoveFile table. I blogged about that kind of CA a few months ago: http://www.joyofsetup.com/2007/07/01/semi-custom-actions/. -- sig://boB http://joyofsetup.com/ - 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] What is WixV3 Toolset Output MSI Version?
Hey WiX Folks, If I am not wrong, WIXv3 Toolset produces Windows Install v3.1 MSI. I also remember some blogs where WIX Team have met with MSI Team to do the enhancements to WIX Toolset to use new features of MSI 4.0. Can you answer the following? 1)WIXv3 Current Build produces MSI v3.1. Does WIXv3 in future produce MSI v4.0? OR WIXv4 produces MSI v4.0? 2)When will WIXv3 development completes? When is it going to release candidate phase only very few fixes are taken? Thanks, Laxmi - 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] What is WixV3 Toolset Output MSI Version?
Laxmi Narsimha Rao Oruganti (SQL CE) wrote: If I am not wrong, WIXv3 Toolset produces Windows Install v3.1 MSI. I also remember some blogs where WIX Team have met with MSI Team to do the enhancements to WIX Toolset to use new features of MSI 4.0. Can you answer the following? 1)WIXv3 Current Build produces MSI v3.1. Does WIXv3 in future produce MSI v4.0? OR WIXv4 produces MSI v4.0? WiX lets you target whatever version of MSI you're interested in, down to MSI 1.0. See Package/@InstallerVersion. 2)When will WIXv3 development completes? When is it going to release candidate phase only very few fixes are taken? It will likely reach that stage sometime in 2008. There are no more breaking changes planned, but they are possible. -- sig://boB http://joyofsetup.com/ - 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] WiX 3.0 post 3304 working for anyone?
Mike Dimmick wrote: Whenever I run a tool in version 3307, 3328 or 3419 builds obtained from wix.sourceforge.net/releases, I get a System.IO.FileLoadException (0x80131040) saying that the wix assembly could not be loaded. It's a known issue and the WiX buildmeisters are working on the fix (which is needed after we moved the WiX build to a new machine). But feel free to file a bug -- I don't see one at first glance and everyone loves to close bugs...g -- sig://boB http://joyofsetup.com/ - 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