[WiX-users] VS 11 macros
I'm using WiX 3.5 to build installers for VS2005/2008/2010 extensions. I'm working on an extension for VS11 and find that the nice macros for the earlier versions of Visual Studio are not available for VS11 (of course). Does anyone know if macros like VS11_ROOT_FOLDER, etc., will be available in a coming version of the WiX toolset? Soon, maybe? -- Paul -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Adding file association to component generated by heat
hi, I need to associate a file extension to my executable and my directory structure is generated by heat. As heat would overwrite the generated fragment file on each build, is it possible to add the following stuff elsewhere but not the generated fragment file? ProgId Extension Verb Id=open Command=Open TargetFile=targetID Argument='%1' / /Extension /ProgId Thanks -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5
That may be ordinary behaviour you are seeing. There are 2 msiexec processes associated with an installation - the client-side exe and the server-side service process. After the msiexec service has been used for something (installation, repair, etc), it persists for a while (10 minutes maybe ?) in case it is needed again. You can probably put the chainsaw back in the shed :) -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: 03 October 2011 19:24 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5 Is there any list of know issues with Windows Installer 4.5/5.0? Occasionally, I see zombie msiexec.exe processes. This occurs even on a successful installer verbose log. It's not common, and it appears to be random. Killing the msiexec.exe zombies usually works. Rebooting always works. Occurs like maybe once a week. During testing. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech, Inc.) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Sharing file components between directories
Hello, I am wondering about file components and directories. As I understand it, I have to point any component containing a file towards a named directory. But what if I need a file in several directories? Currently I am thinking about making two separate installers with a common wix library containing the files each have in common. But I would rather have a single installer and then handle the separation through features. But how do I handle multiple installationpoints for some files? Thanks, Thomas Due -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Adding file association to component generated by heat
You can either use an xsl transformation on the generated wxs file that would insert your progid (heat even has a switch to run one) or you could put the progid and contents in its own component in a separate file and add that file to the project. The first has the advantage that you have a versioned resource for a keypath which makes it easy to patch. -Original Message- From: Zack Pang [mailto:zyhp...@gmail.com] Sent: 04 October 2011 07:16 To: WiX-users@lists.sourceforge.net Subject: [WiX-users] Adding file association to component generated by heat hi, I need to associate a file extension to my executable and my directory structure is generated by heat. As heat would overwrite the generated fragment file on each build, is it possible to add the following stuff elsewhere but not the generated fragment file? ProgId Extension Verb Id=open Command=Open TargetFile=targetID Argument='%1' / /Extension /ProgId Thanks - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Sharing file components between directories
For each file, you create multiple components but their Component/Source attributes will point at the same file. The file will only be included in the installer's cabinet once. -Original Message- From: Thomas Due [mailto:t...@scanvaegt.dk] Sent: 04 October 2011 09:44 To: wix-users@lists.sourceforge.net Subject: [WiX-users] Sharing file components between directories Hello, I am wondering about file components and directories. As I understand it, I have to point any component containing a file towards a named directory. But what if I need a file in several directories? Currently I am thinking about making two separate installers with a common wix library containing the files each have in common. But I would rather have a single installer and then handle the separation through features. But how do I handle multiple installationpoints for some files? Thanks, Thomas Due - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-ICE48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC E48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
Nope... The actual path is just as vanilla as the example below. Straight 7-bit ascii... Thanks mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 10:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC E48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files.
When calling another process from within a batch file that you want to waiting merely add 'call' in front of it. I do this to utilize multiple batch files with one call. Jon -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, October 03, 2011 6:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. John Have a look at the Start command (help start) which can be used to start and wait in batch files. Michael -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, 4 October 2011 8:47 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. I am working through deploying our software for automated testing and appear to have encountered an issue that I am not quite sure what the best way is to solve. I need to deploy multiple MSI files, my initial thought was that I could do this with a batch file, but apparently, the process of running the MSI starts a new process and the batch file continues, so all of the installers after the first one fails. The order of install doesn't matter in my case. I was using PSExec to start the MSIs remotely (both directly and via a batch file). Anyone have any ideas as far as what the best way to do this would be? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
I was wondering maybe *before* CostFinalize? I'm just grasping around here... -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 10:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC E48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dealing with ICE48 warning
I've just looked back at your original post which is how to avoid ICE48 errors. The ICE48 error is issued because ... ICE48 checks for directories that are hard-coded to local paths in the Property table. (From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29 .aspx) ICE48 is objecting to the use of C:\OurPath\ TARGETDIR is by default set to the root of the drive with the most free space (I think). Some of the other components, probably in the merge modules, might have directory paths rooted under a well known directory property like ProgramFilesFolder which overrides the TARGETDIR, even though they appear underneath TARGETDIR. I'm not entirely sure how to fix it to work exactly how you have it currently but I can give some info that might help. The usual pattern for having a retargetable installation is to set up the default in the directory elements and then make the installation directory a public directory property, in this case, INSTALLDIR. Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CompanyDir Name=IniTech Directory Id=INSTALLDIR Name=Product v1 ..components... Then you can set the value of INSTALLDIR (or whatever you call it) to some other value on the command line or leave it to get the default. Note that the built-in directory property ProgramFilesFolder will override whatever TARGETDIR is set to unless youre performing an admin installation. If INSTALLDIR is defined as an absolute path, that will in turn override [ProgramFilesFolder]\InitTech. You might be able to get this to work with TARGETDIR but since Windows Installer itself will set the value of it, it's easier to define your own property and use that: in this case INSTALLDIR. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I was wondering maybe *before* CostFinalize? I'm just grasping around here... -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 10:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC E48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and
Re: [WiX-users] Dealing with ICE48 warning
Thanks, Peter... I can give it a shot. I was a bit perplexed when I found that the Type 51 approach worked as I expected when it installed remotely through WMI, as opposed to being run locally on the computer. By and large our ops team uses a utility to manage the farm and the installs are run remotely; the difference in behavior just annoyed me. Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a difference whether I use the Type 51 or the type 35 custom actions to set it? And at which phase? I googled around and found a few posts advocating the type 51 approach Before CostFinalize, now some saying type 35 after. I'm wondering if just avoiding the specific case of TARGETDIR would push one way or the other? Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I've just looked back at your original post which is how to avoid ICE48 errors. The ICE48 error is issued because ... ICE48 checks for directories that are hard-coded to local paths in the Property table. (From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29 .aspx) ICE48 is objecting to the use of C:\OurPath\ TARGETDIR is by default set to the root of the drive with the most free space (I think). Some of the other components, probably in the merge modules, might have directory paths rooted under a well known directory property like ProgramFilesFolder which overrides the TARGETDIR, even though they appear underneath TARGETDIR. I'm not entirely sure how to fix it to work exactly how you have it currently but I can give some info that might help. The usual pattern for having a retargetable installation is to set up the default in the directory elements and then make the installation directory a public directory property, in this case, INSTALLDIR. Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CompanyDir Name=IniTech Directory Id=INSTALLDIR Name=Product v1 ..components... Then you can set the value of INSTALLDIR (or whatever you call it) to some other value on the command line or leave it to get the default. Note that the built-in directory property ProgramFilesFolder will override whatever TARGETDIR is set to unless youre performing an admin installation. If INSTALLDIR is defined as an absolute path, that will in turn override [ProgramFilesFolder]\InitTech. You might be able to get this to work with TARGETDIR but since Windows Installer itself will set the value of it, it's easier to define your own property and use that: in this case INSTALLDIR. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I was wondering maybe *before* CostFinalize? I'm just grasping around here... -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 10:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the installer locally. Not sure where the ? is coming from... Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Monday, October 03, 2011 4:48 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dealing with ICE48 warning When you use a type 51 custom action it doesn't call MsiSetTargetPath because you've told it you are setting a property and not a directory. Try using a type 35 custom action (after CostFinalize) by using the Directory attribute instead of Property. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dealing-with-IC E48-warning-tp6841665p6856559.html Sent from the wix-users mailing list archive at Nabble.com. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense.
Re: [WiX-users] Dealing with ICE48 warning
The subtle differences between the two are a bit beyond me since I've never needed to distinguish between them. There's a list of considerations at http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may answer your questions. It's worth trawling through the MSDN. For us, setting the property before CostInitialize has always worked. We use a setproperty action but setdirectory would work and should make slightly more sense. It probably helps matters that we don't use merge modules nor MSI UI so the directories are determined before the MSI even starts up and don't change during installation. There are setproperty and setdirectory elements in wix3.5 to more concisely express these kinds of custom action. The remote/local difference is somewhat strange, I agree, but I'm sure there's a good reason for it. A comparison of verbose logs may give you a clue. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:57 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks, Peter... I can give it a shot. I was a bit perplexed when I found that the Type 51 approach worked as I expected when it installed remotely through WMI, as opposed to being run locally on the computer. By and large our ops team uses a utility to manage the farm and the installs are run remotely; the difference in behavior just annoyed me. Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a difference whether I use the Type 51 or the type 35 custom actions to set it? And at which phase? I googled around and found a few posts advocating the type 51 approach Before CostFinalize, now some saying type 35 after. I'm wondering if just avoiding the specific case of TARGETDIR would push one way or the other? Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I've just looked back at your original post which is how to avoid ICE48 errors. The ICE48 error is issued because ... ICE48 checks for directories that are hard-coded to local paths in the Property table. (From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29 .aspx) ICE48 is objecting to the use of C:\OurPath\ TARGETDIR is by default set to the root of the drive with the most free space (I think). Some of the other components, probably in the merge modules, might have directory paths rooted under a well known directory property like ProgramFilesFolder which overrides the TARGETDIR, even though they appear underneath TARGETDIR. I'm not entirely sure how to fix it to work exactly how you have it currently but I can give some info that might help. The usual pattern for having a retargetable installation is to set up the default in the directory elements and then make the installation directory a public directory property, in this case, INSTALLDIR. Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=CompanyDir Name=IniTech Directory Id=INSTALLDIR Name=Product v1 ..components... Then you can set the value of INSTALLDIR (or whatever you call it) to some other value on the command line or leave it to get the default. Note that the built-in directory property ProgramFilesFolder will override whatever TARGETDIR is set to unless youre performing an admin installation. If INSTALLDIR is defined as an absolute path, that will in turn override [ProgramFilesFolder]\InitTech. You might be able to get this to work with TARGETDIR but since Windows Installer itself will set the value of it, it's easier to define your own property and use that: in this case INSTALLDIR. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:00 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I was wondering maybe *before* CostFinalize? I'm just grasping around here... -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 10:24 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Could it be the file's encoding ? Declared as UTF-8 but written in something else maybe ? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 15:17 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks for the response... I tried replacing my type 51 with CustomAction Id=SetTarget Directory=TARGETDIR Value=C:\OurPath\ / After CostFinalize, but now I get an error The folder path '?' contains an invalid character when I run the
Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files.
VBScript is pretty straightforward. Dim installer = CreateObject(WindowsInstaller.Installer) And then Installer.InstallProduct (path to msi, property list etc) for each one. I suspect PowerShell has similar capabilities. Phil Wilson -Original Message- From: McCain, Jon [mailto:jon.mcc...@inin.com] Sent: Tuesday, October 04, 2011 7:45 AM To: General discussion for Windows Installer XML toolset. Cc: McCain, Jon Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. When calling another process from within a batch file that you want to waiting merely add 'call' in front of it. I do this to utilize multiple batch files with one call. Jon -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, October 03, 2011 6:52 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. John Have a look at the Start command (help start) which can be used to start and wait in batch files. Michael -Original Message- From: John Bergman [mailto:john.berg...@xpedienttechnologies.com] Sent: Tuesday, 4 October 2011 8:47 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Using a batch file (or something else?) do deploy multiple MSI files. I am working through deploying our software for automated testing and appear to have encountered an issue that I am not quite sure what the best way is to solve. I need to deploy multiple MSI files, my initial thought was that I could do this with a batch file, but apparently, the process of running the MSI starts a new process and the batch file continues, so all of the installers after the first one fails. The order of install doesn't matter in my case. I was using PSExec to start the MSIs remotely (both directly and via a batch file). Anyone have any ideas as far as what the best way to do this would be? -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application
Re: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5
During an installation there may be more than those two. New ones may be fired up to host custom actions. I agree, it all sounds normal to me. Phil Wilson -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 1:53 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5 That may be ordinary behaviour you are seeing. There are 2 msiexec processes associated with an installation - the client-side exe and the server-side service process. After the msiexec service has been used for something (installation, repair, etc), it persists for a while (10 minutes maybe ?) in case it is needed again. You can probably put the chainsaw back in the shed :) -Original Message- From: John Cooper [mailto:jocoo...@jackhenry.com] Sent: 03 October 2011 19:24 To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Known Issues why msiexec.exe goes Zombie for MSI 4.5 Is there any list of know issues with Windows Installer 4.5/5.0? Occasionally, I see zombie msiexec.exe processes. This occurs even on a successful installer verbose log. It's not common, and it appears to be random. Killing the msiexec.exe zombies usually works. Rebooting always works. Occurs like maybe once a week. During testing. -- John Merryweather Cooper Jack Henry Associates, Inc. (Premier Tech, Inc.) Build Install Engineer - jXchange Office: 913-341-3434 x791011 jocoo...@jackhenry.commailto:jocoo...@jackhenry.com NOTICE: This electronic mail message and any files transmitted with it are intended exclusively for the individual or entity to which it is addressed. The message, together with any attachment, may contain confidential and/or privileged information. Any unauthorized review, use, printing, saving, copying, disclosure or distribution is strictly prohibited. If you have received this message in error, please immediately advise the sender by reply email and delete all copies. - - All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users SDL PLC confidential, all rights reserved. If you are not the intended recipient of this mail SDL requests and requires that you delete it without acting upon or copying any of its contents, and we further request that you advise us. SDL PLC is a public limited company registered in England and Wales. Registered number: 02675207. Registered address: Globe House, Clivemont Road, Maidenhead, Berkshire SL6 7DY, UK. -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users *** Confidentiality Notice: This e-mail, including any associated or attached files, is intended solely for the individual or entity to which it is addressed. This e-mail is confidential and may well also be legally privileged. If you have received it in error, you are on notice of its status. Please notify the sender immediately by reply e-mail and then delete this message from your system. Please do not copy it or use it for any purposes, or disclose its contents to any other person. This email comes from a division of the Invensys Group, owned by Invensys plc, which is a company registered in England and Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx. You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail recept...@invensys.com. This e-mail and any attachments thereto may be subject to the terms of any agreements between Invensys (and/or its subsidiaries and affiliates) and the recipient (and/or its subsidiaries and affiliates). -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and
[WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Just curious here but why not use the RemoveFile element within the component
that initially installed the file or do you not own this file?
Also, AFAIK If you remove all files in the fashion above that directory will be
removed as well.
Jon W. McCain | Software Engineer - Install
phone fax +1.317.715.8462 | jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 2:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Because most of these are nested in folders created by the application. I
would really like to use the RemoveFolderEX element found in Wix 3.6 but I am
not allowed to use that version yet. I am forced to stay on 3.5
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Tuesday, October 04, 2011 2:03 PM
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Just curious here but why not use the RemoveFile element within the component
that initially installed the file or do you not own this file?
Also, AFAIK If you remove all files in the fashion above that directory will be
removed as well.
Jon W. McCain | Software Engineer - Install
phone fax +1.317.715.8462 | jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 2:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Okay so the folders/files are then classified as customer data which is why
RemoveFile wouldn't work since you don't actually lay those files down. At
least that is how I am reading your response.
If that is the case then you shouldn't need to worry about being a good install
writer and just whack the folder or its subfolders that you don't control with
your install.
Jon W. McCain | Software Engineer - Install
phone fax +1.317.715.8462 | jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 3:06 PM
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Because most of these are nested in folders created by the application. I
would really like to use the RemoveFolderEX element found in Wix 3.6 but I am
not allowed to use that version yet. I am forced to stay on 3.5
-Original Message-
From: McCain, Jon [mailto:jon.mcc...@inin.com]
Sent: Tuesday, October 04, 2011 2:03 PM
To: General discussion for Windows Installer XML toolset.
Cc: McCain, Jon
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Just curious here but why not use the RemoveFile element within the component
that initially installed the file or do you not own this file?
Also, AFAIK If you remove all files in the fashion above that directory will be
removed as well.
Jon W. McCain | Software Engineer - Install phone fax +1.317.715.8462 |
jon.mcc...@inin.com
Interactive Intelligence Inc.
Deliberately Innovative
www.inin.com
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 2:45 PM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security threats,
fraudulent activity and more. Splunk takes this data and makes sense of it.
Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
--
All the data
Re: [WiX-users] Dealing with ICE48 warning
Hi Peter... It was a bit of a nuisance to get a verbose log out of the wmi install, so I've been comparing the logs from the builds using the type 51 and type 35 work-arounds vs the builds just ignoring the error. The differences I see is that TARGETDIR=my custom value in the early phases of all logs, but in the ones with the type 51 and type 35 work-arounds TARGETDIR just doesn't appear to be used in coming up with the final destination for some of the merge modules. Why? I don't know. E.g. Action ended 17:14:01: INSTALL. Return value 1. Property(C): Binaries = C:\OurPath\Binaries\ Property(C): TARGETDIR = C:\OurPath\ Property(C): ASP = C:\OurPath\ASP\ Property(C): Ptt = C:\OurPath\Ptt\ In the log when I just ignore the warning compared to Action ended 15:27:12: INSTALL. Return value 1. Property(S): Binaries = C:\OurPath\Binaries\ Property(S): TARGETDIR = C:\OurPath\ Property(S): ASP = C:\ASP\ Property(S): Ptt = C:\OurPath\Ptt\ In the log when I'm trying one of the other approaches. On your other suggestions, I found a few things: 1) Can't put a type 35 anywhere before after CostFinalize. It throws an error at any stage before. 2) I tried putting my own directory level (e.g. Directory Id=PRODUCTDIR Name=Ice48 Stub.../Directory) just inside of TARGETDIR, but using a type 51 CA Before=CostInitialize still had the same problem of pretty random directory placement. Specifically, it put things in C:\Ice48 Stub\... 3) Same as #2 but going back to type 35 after CostFinalize appeared to do the trick. Things got installed where I expected when running the msi locally. Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 12:10 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning The subtle differences between the two are a bit beyond me since I've never needed to distinguish between them. There's a list of considerations at http://msdn.microsoft.com/en-us/library/aa367852%28v=VS.85%29.aspx which may answer your questions. It's worth trawling through the MSDN. For us, setting the property before CostInitialize has always worked. We use a setproperty action but setdirectory would work and should make slightly more sense. It probably helps matters that we don't use merge modules nor MSI UI so the directories are determined before the MSI even starts up and don't change during installation. There are setproperty and setdirectory elements in wix3.5 to more concisely express these kinds of custom action. The remote/local difference is somewhat strange, I agree, but I'm sure there's a good reason for it. A comparison of verbose logs may give you a clue. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 16:57 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Thanks, Peter... I can give it a shot. I was a bit perplexed when I found that the Type 51 approach worked as I expected when it installed remotely through WMI, as opposed to being run locally on the computer. By and large our ops team uses a utility to manage the farm and the installs are run remotely; the difference in behavior just annoyed me. Just out of curiosity, if I switch to using INSTALLDIR instead, does it make a difference whether I use the Type 51 or the type 35 custom actions to set it? And at which phase? I googled around and found a few posts advocating the type 51 approach Before CostFinalize, now some saying type 35 after. I'm wondering if just avoiding the specific case of TARGETDIR would push one way or the other? Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Tuesday, October 04, 2011 11:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning I've just looked back at your original post which is how to avoid ICE48 errors. The ICE48 error is issued because ... ICE48 checks for directories that are hard-coded to local paths in the Property table. (From http://msdn.microsoft.com/en-us/library/windows/desktop/aa368977%28v=vs.85%29 .aspx) ICE48 is objecting to the use of C:\OurPath\ TARGETDIR is by default set to the root of the drive with the most free space (I think). Some of the other components, probably in the merge modules, might have directory paths rooted under a well known directory property like ProgramFilesFolder which overrides the TARGETDIR, even though they appear underneath TARGETDIR. I'm not entirely sure how to fix it to work exactly how you have it currently but I can give some info that might help. The usual pattern for having a retargetable installation is to set up the default in the directory elements and then make the installation directory a public directory property, in this case, INSTALLDIR. Directory
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Is there anything about that interop that lets you see the equivalent of
MsiViewGetError or MsiGetLastErrorRecord? There's typically more error info
available from those.
Phil Wilson
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 11:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why my
custom action is constantly failing me. The action executes on uninstall and
is to browse the install folder and add files to the RemoveFile table (with a
few additional properties too) in the MSI so that the file is removed during
uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row (Either
in the Property Table or the RemoveFile table) I get the exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no avail.
And there is no way the directory property name could be conflicting as it is
part static with a GUID (stripped of the hyphens) appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows Installer
citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
*** Confidentiality Notice: This e-mail, including any associated or attached
files, is intended solely for the individual or entity to which it is
addressed. This e-mail is confidential and may well also be legally privileged.
If you have received it in error, you are on notice of its status. Please
notify the sender immediately by reply e-mail and then delete this message from
your system. Please do not copy it or use it for any purposes, or disclose its
contents to any other person. This email comes from a division of the Invensys
Group, owned by Invensys plc, which is a company registered in England and
Wales with its registered office at 3rd Floor, 40 Grosvenor Place, London, SW1X
7AW (Registered number 166023). For a list of European legal entities within
the Invensys Group, please go to http://www.invensys.com/en/legal/default.aspx.
You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail
recept...@invensys.com. This e-mail and any attachments thereto may be subject
to the terms of any agreements between Invensys (and/or its subsidiaries and
affiliates) and the recipient (and/or its subsidiaries and affiliates).
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
Sure. In .NET you use try catch blocks rather then checking the exit code
of functions. In DTF, the View class (and others) will raise an
InstallerException which then exposes the GetErrorRecord() method which is
a wrapper for MsiGetLastErrorRecord().
From: Wilson, Phil phil.wil...@invensys.com
Sent: Tuesday, October 04, 2011 5:36 PM
To: General discussion for Windows Installer XML toolset.
wix-users@lists.sourceforge.net
Subject: Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary
Rows.
Is there anything about that interop that lets you see the equivalent of
MsiViewGetError or MsiGetLastErrorRecord? There's typically more error info
available from those.
Phil Wilson
-Original Message-
From: Brian Lemke [mailto:brian.le...@apihealthcare.com]
Sent: Tuesday, October 04, 2011 11:45 AM
To: wix-users@lists.sourceforge.net
Subject: [WiX-users] C# Custom Action Fails when Inserting Temoporary
Rows.
I'm hoping that someone can help me out. I cannot seem to figure out why
my custom action is constantly failing me. The action executes on
uninstall and is to browse the install folder and add files to the
RemoveFile table (with a few additional properties too) in the MSI so that
the file is removed during uninstall. The action is defined as
InstallExecuteSequence
Custom
Action=PurgeFolder
After=InstallInitialize
![CDATA[REMOVE~=ALL AND NOT UPGRADINGPRODUCTCODE]]
/Custom
/InstallExecuteSequence
The action runs as expected as I can get log messages to show up in the log
file. However whenever the action attempts to insert a temporary row
(Either in the Property Table or the RemoveFile table) I get the
exception:
Microsoft.Deployment.WindowsInstaller.InstallerException: Function failed
during execution. Database: Table(s) Update failed.
at Microsoft.Deployment.WindowsInstaller.View.Modify(ViewModifyMode mode,
Record record)
The method for updating the view looks like
Record newRecord = session.Database.CreateRecord(2);
newRecord.SetString(1, directoryProperty);
newRecord.SetString(2, directory.FullName);
session.Log(String.Format(Adding Property {0}, newRecord.ToString()));
propertyView.Modify(ViewModifyMode.InsertTemporary, newRecord);
I have even tried executing a straight insert statement like INSERT INTO
Property ('Property', 'Value') Values (Value1, Value2) TEMPORARY to no
avail. And there is no way the directory property name could be
conflicting as it is part static with a GUID (stripped of the hyphens)
appended to the end of it.
I am almost at my wits end here. I am half a step away from the CA just
blowing away the whole directory but I am trying to be a good Windows
Installer citizen here and use the tools as they are.
--Brian
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
*** Confidentiality Notice: This e-mail, including any associated or
attached files, is intended solely for the individual or entity to which it
is addressed. This e-mail is confidential and may well also be legally
privileged. If you have received it in error, you are on notice of its
status. Please notify the sender immediately by reply e-mail and then
delete this message from your system. Please do not copy it or use it for
any purposes, or disclose its contents to any other person. This email
comes from a division of the Invensys Group, owned by Invensys plc, which
is a company registered in England and Wales with its registered office at
3rd Floor, 40 Grosvenor Place, London, SW1X 7AW (Registered number 166023).
For a list of European legal entities within the Invensys Group, please go
to http://www.invensys.com/en/legal/default.aspx.
You may contact Invensys plc on +44 (0)20 3155 1200 or e-mail
recept...@invensys.com. This e-mail and any attachments thereto may be
subject to the terms of any agreements between Invensys (and/or its
subsidiaries and affiliates) and the recipient (and/or its subsidiaries and
affiliates).
--
All the data continuously generated in your IT infrastructure contains a
definitive record of customers, application performance, security
threats, fraudulent activity and more. Splunk takes this data and makes
sense of it. Business sense. IT sense. Common sense.
http://p.sf.net/sfu/splunk-d2dcopy1
___
WiX-users mailing list
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
On 04-Oct-11 15:29, McCain, Jon wrote: If that is the case then you shouldn't need to worry about being a good install writer and just whack the folder or its subfolders that you don't control with your install. Of course you should. If there's a failure or other rollback, the user's data is gone. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] C# Custom Action Fails when Inserting Temoporary Rows.
On 04-Oct-11 15:06, Brian Lemke wrote: Because most of these are nested in folders created by the application. I would really like to use the RemoveFolderEX element found in Wix 3.6 but I am not allowed to use that version yet. I am forced to stay on 3.5 1. That's a false economy: The time it would take to validate a WiX v3.6 drop is dwarfed by the time to write a custom action, much less a good one. 2. So reuse the WiX v3.6 code, as much as you can. For example, you could use the CA DLL without taking the compiler extension. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] WixUIMondo
On 03-Oct-11 12:43, Brad Lemings wrote: So I located the .wxl sources with the appropriate text strings. I'm assuming I don't need the special markup in comments (e.g. _locIDText, _locComment)? No, they're just comments for the localization team that contributed the strings. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] VS 11 macros
On 04-Oct-11 02:00, Paul A. Steckler wrote: Does anyone know if macros like VS11_ROOT_FOLDER, etc., will be available in a coming version of the WiX toolset? Soon, maybe? Historically, the detection properties were added during beta. -- sig://boB http://joyofsetup.com/ -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance, security threats, fraudulent activity and more. Splunk takes this data and makes sense of it. Business sense. IT sense. Common sense. http://p.sf.net/sfu/splunk-d2dcopy1 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
