Re: [WiX-users] Dealing with ICE48 warning
Okay, I'm looking at the installer in Orca. I see that all the directories declared in the modules have the package guid appended to them (e.g. ASPdirectory0.1A39512D_87E4_4FD4_AEFC_88DE0E1C2536), but that's the same for those that went to the right place and those that went somewhere else. A lot of the binary modules had a Directory Id=INSTALLDIR inside the module's Directory Id=TARGETDIR, so all those INSTALLDIRs are differentiated by the guid... Thanks Mark -Original Message- From: Peter Shirtcliffe [mailto:pshirtcli...@sdl.com] Sent: Wednesday, October 05, 2011 4:38 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dealing with ICE48 warning Open the MSI up in Orca or Inst Ed and you might find that the directory IDs in the merge modules have had Guids added to them. Ids in modules are modularised to avoid name clashes. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 04 October 2011 23:14 To: General discussion for Windows Installer XML toolset. Subject: 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
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
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] 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
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. http://p.sf.net/sfu
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 Id
Re: [WiX-users] Dealing with ICE48 warning
Okay, now this is getting strange and I hope someone can help me figure out what's going on here... I just discovered that having a type 51 custom action to set TARGETDIR puts half the directories in the wrong place when I copy the msi to a machine and run it locally. When I copy the msi to the machine and run it remotely through WMI, the directories are put in the right place. So when I *thought* I'd resolved it by moving the CA from Before=CostInitialize to Before=CostFinalize it would appear the bigger difference was running the msi through our little utility using WMI instead of running it manually on the spot. So again, anyone have any clue why running the msi locally with TARGETDIR set in a custom action would result in the directories being placed in the wrong spots? And why running the same msi through WMI would put them in the right places? Thanks Mark -Original Message- From: Mark Modrall [mailto:mmodrall@...] Sent: Wednesday, September 28, 2011 3:57 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Dealing with ICE48 warning Hi... Our installers are used internally to install to a farm, so we had Property Id=TARGETDIR Value=C:\OurPath / In our old Wix 2.0 scripts. We recently updated to Wix 3.5, and I started getting ICE48 warnings. I googled around on how to do this properly, and I found some posts about moving the definition of the target directory to a custom action at an early stage. So I replaced the definition above with Custom Action=SetTarget Before=CostInitialize / Custom Action=InstallConfig Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence CustomAction Id=SetTarget Property=TARGETDIR Value=C:\OurPath\ / CustomAction Id=InstallConfig Impersonate=no Return=check Execute=deferred FileKey=InstallConfig.exe ExeCommand=[TARGETDIR] / That did get rid of the warning, but now when I run the installers produced most of the subdirectories end up at C:\ instead - except for a couple which end up in the right place for reasons I haven't figured out. For example, my main msi wxs file has Directory Id=TARGETDIR Name=SourceDir Directory Id=Binaries Name=Binaries Merge Id=PTCoreModule Language=1033 SourceFile=..\PTCoreModule\bin\Release\PTCoreModule.msm DiskId=1 / ... Component Id=InstallConfig Guid=D746C5C0-12CB-4d4a-AA65-361D578F09F5 File Id='InstallConfig.exe' Name='InstallConfig.exe' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.exe' Vital='yes' / File Id='InstallConfig.pdb' Name='InstallConfig.pdb' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.pdb' / /Component /Directory Directory Id=ASP Name=ASP Merge Id=AspModule Language=1033 SourceFile=..\AspModule\bin\Release\AspModule.msm DiskId=1 / /Directory Directory Id=Ptt Name=Ptt Merge Id=PttModule Language=1033 SourceFile=..\PttModule\bin\Release\PttModule.msm DiskId=1 / /Directory /Directory The Component under Binaries ends up in C:\OurPath\Binaries\InstallConfig.exe, but PTCore's contents end up in C:\Binaries. The AspModule ends up in C:\ASP\, but PttModule ends up in C:\OurPath\Ptt. So a) did I just pick the wrong way to deal with ICE 48? Or more importantly, what did I do wrong? b) What's the right way? c) Any guesses why some directories would seem to work and others not? Seems like I should just live with the warnings until I figure out how to do it right... Thanks mark -- 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 re-read some of the posts I found on Google, and in them they say to move the custom action to before CostFinalize where I had before CostInitialize. I made the change, and it worked. Not clear why it seemed to work partially when done before CostInitialize, though. Thanks Mark -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Wednesday, September 28, 2011 3:57 PM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] Dealing with ICE48 warning Hi... Our installers are used internally to install to a farm, so we had Property Id=TARGETDIR Value=C:\OurPath / In our old Wix 2.0 scripts. We recently updated to Wix 3.5, and I started getting ICE48 warnings. I googled around on how to do this properly, and I found some posts about moving the definition of the target directory to a custom action at an early stage. So I replaced the definition above with Custom Action=SetTarget Before=CostInitialize / Custom Action=InstallConfig Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence CustomAction Id=SetTarget Property=TARGETDIR Value=C:\OurPath\ / CustomAction Id=InstallConfig Impersonate=no Return=check Execute=deferred FileKey=InstallConfig.exe ExeCommand=[TARGETDIR] / That did get rid of the warning, but now when I run the installers produced most of the subdirectories end up at C:\ instead - except for a couple which end up in the right place for reasons I haven't figured out. For example, my main msi wxs file has Directory Id=TARGETDIR Name=SourceDir Directory Id=Binaries Name=Binaries Merge Id=PTCoreModule Language=1033 SourceFile=..\PTCoreModule\bin\Release\PTCoreModule.msm DiskId=1 / ... Component Id=InstallConfig Guid=D746C5C0-12CB-4d4a-AA65-361D578F09F5 File Id='InstallConfig.exe' Name='InstallConfig.exe' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.exe' Vital='yes' / File Id='InstallConfig.pdb' Name='InstallConfig.pdb' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.pdb' / /Component /Directory Directory Id=ASP Name=ASP Merge Id=AspModule Language=1033 SourceFile=..\AspModule\bin\Release\AspModule.msm DiskId=1 / /Directory Directory Id=Ptt Name=Ptt Merge Id=PttModule Language=1033 SourceFile=..\PttModule\bin\Release\PttModule.msm DiskId=1 / /Directory /Directory The Component under Binaries ends up in C:\OurPath\Binaries\InstallConfig.exe, but PTCore's contents end up in C:\Binaries. The AspModule ends up in C:\ASP\, but PttModule ends up in C:\OurPath\Ptt. So a) did I just pick the wrong way to deal with ICE 48? Or more importantly, what did I do wrong? b) What's the right way? c) Any guesses why some directories would seem to work and others not? Seems like I should just live with the warnings until I figure out how to do it right... Thanks mark -- 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] Strange behavior with date modifying of installed files
Nope, FILETIME is not timezone aware... Want to hear something even stranger? When you ask for a FILETIME to be resolved, it uses the is daylight savings time? setting from *now*, not the date on the file to adjust the timestamp. Want to hear something even stranger than that? The C runtime library function _stat() has the same daylight savings time behavior because underneath it's all driven by the FILETIME behavior. When I reported it as a bug to Microsoft, it took months to get to the bottom of it. Finally got to one of the OS engineers who said #1 was because some OS processes were checking mod timestamps on logs a lot, and it was too much of a performance drag to re-calculate the DST offset every time. On #2, they said Well, people are depending on it working this way now My response was The answer to the question When was FDR's last Fireside chat? shouldn't be Depends... what day is it today? Mark -Original Message- From: Christopher Painter [mailto:chr...@iswix.com] Sent: Wednesday, September 28, 2011 10:59 AM To: General discussion for Windows Installer XML toolset.; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Strange behavior with date modifying of installed files I did some googling but had decided not to post since I'm not an expert. I found some doco in MSDN describing a structure with Date and Time fields and a note saying that it's generally date modified but that the meaning is up to the application. Nothing in the datatype seemed to be UTC aware. I also found some SDK doco down in DTF describing date time members for local and and UTC but I suspect that's just translating the time provided and then applying it to the CAB at which point probably becomes lossy. An interesting thought excercise would be to use InstallShield and WiX to consume the same set of files and deploy them to a VM and see if they express differently. Then again, I don't really find it a problem one way or the other as datetimes are meaningless to me. I care about version numbers and file hashes. From: Rob Mensching r...@robmensching.com Sent: Wednesday, September 28, 2011 9:19 AM To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Strange behavior with date modifying of installed files I believe this is a limitation of .cab files that store the times as FILETIME. Timezone is not stored. I'd be happy to be wrong if someone could show otherwise. On Wed, Sep 28, 2011 at 4:53 AM, Grigory Konovalov grigory.konova...@confirmit.com wrote: Why WIX save local time for files, but doesn't save UTC time? For example, a file has 10.00 time modified in a server with UTC+01.00 (it is 9.00 in UTC time). I create msi on this server and install it on a new server with UTC-01.00. The file have 10.00 time modified on the new server after installation, but there should be 8.00 time (real date creation 9.00 in UTC minus 1 hour of time zone). If we change UTC on the new server to UTC+01.00 like on the first server, modified time will change to 12.00 (it is 11.00 in UTC time). Therefore modified date increase on 2 hours. I guess, it is strange. Grigory Konovalov Software Engineer grigory.konova...@confirmit.commailto:grigory.konova...@confirmit.com | Phone +7 4852 586 924 | Mobile +7 902 221 6886 Confirmit(r) [everywhere] Software for Market Research and Enterprise Feedback Management Confirmit Ltd., 56 Lisizina str., Yaroslavl, Russia, 150014 www.confirmit.comhttp://www.confirmit.com/ | Main/fax +7 4852 586 924; +7 4852 586 925 The information contained in this email message may be privileged, confidential or exempt from disclosure under applicable law. If you are not the intended recipient, you are hereby notified that any use, dissemination, distribution or copying of this transmission is strictly prohibited. If you have received this communication in error, or if any problems occur with transmission, please notify the sender immediately. -- 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 -- virtually, Rob Mensching - http://RobMensching.com LLC -- All the data continuously generated in your IT infrastructure contains a definitive record of customers, application performance,
[WiX-users] Dealing with ICE48 warning
Hi... Our installers are used internally to install to a farm, so we had Property Id=TARGETDIR Value=C:\OurPath / In our old Wix 2.0 scripts. We recently updated to Wix 3.5, and I started getting ICE48 warnings. I googled around on how to do this properly, and I found some posts about moving the definition of the target directory to a custom action at an early stage. So I replaced the definition above with Custom Action=SetTarget Before=CostInitialize / Custom Action=InstallConfig Before=InstallFinalizeNOT Installed/Custom /InstallExecuteSequence CustomAction Id=SetTarget Property=TARGETDIR Value=C:\OurPath\ / CustomAction Id=InstallConfig Impersonate=no Return=check Execute=deferred FileKey=InstallConfig.exe ExeCommand=[TARGETDIR] / That did get rid of the warning, but now when I run the installers produced most of the subdirectories end up at C:\ instead - except for a couple which end up in the right place for reasons I haven't figured out. For example, my main msi wxs file has Directory Id=TARGETDIR Name=SourceDir Directory Id=Binaries Name=Binaries Merge Id=PTCoreModule Language=1033 SourceFile=..\PTCoreModule\bin\Release\PTCoreModule.msm DiskId=1 / ... Component Id=InstallConfig Guid=D746C5C0-12CB-4d4a-AA65-361D578F09F5 File Id='InstallConfig.exe' Name='InstallConfig.exe' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.exe' Vital='yes' / File Id='InstallConfig.pdb' Name='InstallConfig.pdb' DiskId='1' Source='..\InstallConfig\bin\Release\InstallConfig.pdb' / /Component /Directory Directory Id=ASP Name=ASP Merge Id=AspModule Language=1033 SourceFile=..\AspModule\bin\Release\AspModule.msm DiskId=1 / /Directory Directory Id=Ptt Name=Ptt Merge Id=PttModule Language=1033 SourceFile=..\PttModule\bin\Release\PttModule.msm DiskId=1 / /Directory /Directory The Component under Binaries ends up in C:\OurPath\Binaries\InstallConfig.exe, but PTCore's contents end up in C:\Binaries. The AspModule ends up in C:\ASP\, but PttModule ends up in C:\OurPath\Ptt. So a) did I just pick the wrong way to deal with ICE 48? Or more importantly, what did I do wrong? b) What's the right way? c) Any guesses why some directories would seem to work and others not? Seems like I should just live with the warnings until I figure out how to do it right... Thanks mark -- 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] Dependency warnings I don't quite get...
Thanks Bill... I just checked the man page for the Dependency element (http://wix.sourceforge.net/manual-wix3/wix_xsd_dependency.htm) and I don't see a GUID attribute on the node. Is it just missing from the documentation? Mark -Original Message- From: bpackard [mailto:bill.pack...@kepware.com] Sent: Monday, September 26, 2011 9:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dependency warnings I don't quite get... Mark, When I have dependencies, I have had to include the GUID of the merge module in the dependency declaration, in order to match the signature. Try adding the GUID to the dependency declaration: lt;Dependency RequiredId=quot;PTCoreModule.lt;GUIDgt; RequiredLanguage=1033 RequiredVersion=1.0.0.0 / bill packard -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.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] Dependency warnings I don't quite get...
D'oh... The html encoding of your example threw me... I get it now. Guid goes *in* the RequiredId... Thanks mark -Original Message- From: bpackard [mailto:bill.pack...@kepware.com] Sent: Monday, September 26, 2011 9:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dependency warnings I don't quite get... Mark, When I have dependencies, I have had to include the GUID of the merge module in the dependency declaration, in order to match the signature. Try adding the GUID to the dependency declaration: lt;Dependency RequiredId=quot;PTCoreModule.lt;GUIDgt; RequiredLanguage=1033 RequiredVersion=1.0.0.0 / bill packard -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.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] Dependency warnings I don't quite get...
Thanks Bill, adding the guide to the dependency id seems to have done the trick! Mark -Original Message- From: bpackard [mailto:bill.pack...@kepware.com] Sent: Monday, September 26, 2011 9:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dependency warnings I don't quite get... Mark, When I have dependencies, I have had to include the GUID of the merge module in the dependency declaration, in order to match the signature. Try adding the GUID to the dependency declaration: lt;Dependency RequiredId=quot;PTCoreModule.lt;GUIDgt; RequiredLanguage=1033 RequiredVersion=1.0.0.0 / bill packard -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Dependency-warnings-I-don-t-quite-get-tp6825122p6831923.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] Dependency warnings I don't quite get...
I know that's what the error message description says, but I'm not seeing what I'm missing. In the example below, PTCoreModule is declared as described, and all 8 other modules that have a Dependency on it declare that dependency as below - yet all 8 are issuing the ICE25 errors. I mean, it *looks* like PTCoreModule is declaring the same language and version as all the Dependencies, but the errors are coming anyway. That's what i don't get... Thanks Mark From: Rob Mensching [r...@robmensching.com] Sent: Saturday, September 24, 2011 2:33 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Dependency warnings I don't quite get... The Merge Modules you're are pulling in have declared dependencies on Merge Modules you have not added to your project. Or the identifiers are not matching correctly. On Fri, Sep 23, 2011 at 10:53 AM, Mark Modrall mmodr...@mzinga.com wrote: Hi... I'm getting a bunch of ICE25 warnings about dependencies missing, and I'm not quite getting what I'm doing wrong... To give some examples, I have a merge module with Module Id=PTCoreModule Language=1033 Version=1.0.0.0 ... /Module There are several other merge modules that have Dependency RequiredId=PTCoreModule RequiredLanguage=1033 RequiredVersion=1.0.0.0 / My Product package merges a lot of these modules Merge Id=PTCoreModule Language=1033 SourceFile=..\PTCoreModule\bin\Release\PTCoreModule.msm DiskId=1 / Merge Id=OtherModule Language=1033 SourceFile=..\OtherModule\bin\Release\PTCookiesModule.msm DiskId=1 / ... /Directory But I'm getting these warnings from every module that has a dependency on PTCoreModule: 23light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find PTCoreModule@1033 v1.0.0.0 in ModuleSignature table I tried re-ordering the merge list so the main dependencies came first, thinking it might have been a single-pass process that hadn't seen it yet but that didn't help. I'm getting ~20-30 of these warnings for every package built. Looks like things should be okay, so what am I missing? Thanks Mark -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Dependency warnings I don't quite get...
Thanks Bob and Ed... Actually installing the msi on a machine, I see that the merge module did, in fact, get into the package. It's there post install and nothing would run without it. That's among the things that puzzles me about the warning. Thanks mark From: Bob Arnson [b...@joyofsetup.com] Sent: Saturday, September 24, 2011 3:21 PM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Dependency warnings I don't quite get... On 24-Sep-11 15:06, Mark Modrall wrote: I know that's what the error message description says, but I'm not seeing what I'm missing. Use Orca to see if the resources in the merge module were merged in. If they weren't, the warning is telling you the merge module wasn't merged into the .msi. -- sig://boB http://joyofsetup.com/ -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Dependency warnings I don't quite get...
Hi... I'm getting a bunch of ICE25 warnings about dependencies missing, and I'm not quite getting what I'm doing wrong... To give some examples, I have a merge module with Module Id=PTCoreModule Language=1033 Version=1.0.0.0 ... /Module There are several other merge modules that have Dependency RequiredId=PTCoreModule RequiredLanguage=1033 RequiredVersion=1.0.0.0 / My Product package merges a lot of these modules Merge Id=PTCoreModule Language=1033 SourceFile=..\PTCoreModule\bin\Release\PTCoreModule.msm DiskId=1 / Merge Id=OtherModule Language=1033 SourceFile=..\OtherModule\bin\Release\PTCookiesModule.msm DiskId=1 / ... /Directory But I'm getting these warnings from every module that has a dependency on PTCoreModule: 23light.exe(0,0): warning LGHT1076: ICE25: Possible dependency failure as we do not find PTCoreModule@1033 v1.0.0.0 in ModuleSignature table I tried re-ordering the merge list so the main dependencies came first, thinking it might have been a single-pass process that hadn't seen it yet but that didn't help. I'm getting ~20-30 of these warnings for every package built. Looks like things should be okay, so what am I missing? Thanks Mark -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Build vs rebuild with wix
We're just moving up from Wix 2.0 to wix 3.5. In Wix 2.0, we always did a rebuild on the solution (I presume because the people who came before me didn't think wix would be able to differentiate whether anything changed and needed rebuilding). Now with Wix 3.5 I thought I'd ask whether the wixproj's remembered enough state to make a good differentiation between build and rebuild? Just asking because our Wix project is taking 20 minutes to run rebuild and if it could take a good stab as build it might reduce the build time... Thanks Mark -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2dcopy2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall question in Wix 2.0
Thanks for the reply Michael... I tried changing it to Builtin\NetworkService and then to [ComputerName]\NetworkService, but then I started getting Error 1923. Service 'Prospero Chat Service' (DChatServer) could not be installed. Verify that you have sufficient privileges to install system services. I'm an admin on the box so the latter portion of the message doesn't seem to apply, but it didn't seem to like either of the alternatives... Thanks mark -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, August 22, 2011 6:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstall question in Wix 2.0 Mark Not 100% sure on this answer, but try BuiltIn\NetworkService or [ComputerName]\NetworkService Michael -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Tuesday, 23 August 2011 8:00 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] ServiceInstall question in Wix 2.0 Hi... Sorry to keep asking questions about Wix 2.0, but I haven't gotten clearance to upgrade the tools. I'm trying to get a windows service to install running under the NETWORK SERVICE account for some new dependencies. I tried adding Account=NT Authority\NetworkService to my ServiceInstall node, but for some reason it doesn't seem to be having any impact. The installer runs, the code gets installed and in the end it's still running under Local System. Here's my whole node: ServiceInstall Id=NewServiceInstall Name=DChatServer Account=NT Authority\NetworkService DisplayName=Prospero Chat Service Type=ownProcess Start=auto ErrorControl=normal ServiceDependency Id=MSMQ / /ServiceInstall Am I doing something obviously wrong? Thanks mark -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] ServiceInstall question in Wix 2.0
Okay, this may be my leverage to upgrade... Account=NT Authority\NetworkService *installed* but did not set the Log On account under Wix 2.0. The other variants failed with error 1923. But Account=NT Authority\NetworkService installed and did set the Log On account using Wix 3.5. So now I can tell the people who want this fixed that they'll need to take the newer Wix and I can stop pestering people here for debugging help on the Dead Sea Scrolls :) Thanks Mark -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Tuesday, August 23, 2011 11:52 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstall question in Wix 2.0 Thanks for the reply Michael... I tried changing it to Builtin\NetworkService and then to [ComputerName]\NetworkService, but then I started getting Error 1923. Service 'Prospero Chat Service' (DChatServer) could not be installed. Verify that you have sufficient privileges to install system services. I'm an admin on the box so the latter portion of the message doesn't seem to apply, but it didn't seem to like either of the alternatives... Thanks mark -Original Message- From: Michael Osmond [mailto:mosm...@baytech.com.au] Sent: Monday, August 22, 2011 6:06 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] ServiceInstall question in Wix 2.0 Mark Not 100% sure on this answer, but try BuiltIn\NetworkService or [ComputerName]\NetworkService Michael -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Tuesday, 23 August 2011 8:00 AM To: General discussion for Windows Installer XML toolset. Subject: [WiX-users] ServiceInstall question in Wix 2.0 Hi... Sorry to keep asking questions about Wix 2.0, but I haven't gotten clearance to upgrade the tools. I'm trying to get a windows service to install running under the NETWORK SERVICE account for some new dependencies. I tried adding Account=NT Authority\NetworkService to my ServiceInstall node, but for some reason it doesn't seem to be having any impact. The installer runs, the code gets installed and in the end it's still running under Local System. Here's my whole node: ServiceInstall Id=NewServiceInstall Name=DChatServer Account=NT Authority\NetworkService DisplayName=Prospero Chat Service Type=ownProcess Start=auto ErrorControl=normal ServiceDependency Id=MSMQ / /ServiceInstall Am I doing something obviously wrong? Thanks mark -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Get a FREE DOWNLOAD! and learn more about uberSVN rich system, user administration capabilities and model configuration. Take the hassle out of deploying and managing Subversion and the tools developers use with it. http://p.sf.net/sfu/wandisco-d2d-2 ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ServiceInstall question in Wix 2.0
Hi... Sorry to keep asking questions about Wix 2.0, but I haven't gotten clearance to upgrade the tools. I'm trying to get a windows service to install running under the NETWORK SERVICE account for some new dependencies. I tried adding Account=NT Authority\NetworkService to my ServiceInstall node, but for some reason it doesn't seem to be having any impact. The installer runs, the code gets installed and in the end it's still running under Local System. Here's my whole node: ServiceInstall Id=NewServiceInstall Name=DChatServer Account=NT Authority\NetworkService DisplayName=Prospero Chat Service Type=ownProcess Start=auto ErrorControl=normal ServiceDependency Id=MSMQ / /ServiceInstall Am I doing something obviously wrong? Thanks mark -- uberSVN's rich system and user administration capabilities and model configuration take the hassle out of deploying and managing Subversion and the tools developers use with it. Learn more about uberSVN and get a free download at: http://p.sf.net/sfu/wandisco-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Thanks for the link, Bob; I'll give it a read. By the by, are there known quirks when running a Wix solution via msbuild? My build works just fine when I'm in VS 2010, but when I use msbuild to launch it there's one module that doesn't build and doesn't give any errors. In the build log, I see candle and light getting run, but in obj\Release I only see Product.Generated.wxs and nothing in bin\Release (no merge module). What's in the log is below. The other wix projects are producing msm and msi but for some reason this one quirks out. Should I be using devenv.exe on the command line instead? Thanks Mark Compile: C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe -dDevEnvDir=*Undefined if not building from within Visual Studio* -dSolutionDir=C:\svn\trunk\Installation\Wix\ -dSolutionExt=.sln -dSolutionFileName=AllProducts.sln -dSolutionName=AllProducts -dSolutionPath=C:\svn\trunk\Installation\Wix\AllProducts.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dProjectExt=.wixproj -dProjectFileName=PttModule.wixproj -dProjectName=PttModule -dProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj -dTargetDir=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\ -dTargetExt=.msm -dTargetFileName=PttModule.msm -dTargetName=PttModule -dTargetPath=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -dPttPreBuild.Configuration=Release -dPttPreBuild.FullConfiguration=Release|Win32 -dPttPreBuild.Platform=Win32 -dPttPreBuild.ProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dPttPreBuild.ProjectExt=.vcxproj -dPttPreBuild.ProjectFileName=PttPreBuild.vcxproj -dPttPreBuild.ProjectName=PttPreBuild -dPttPreBuild.ProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttPreBuild.vcxproj -dPttPreBuild.TargetDir=C:\svn\trunk\Installation\Wix\PttModule\ -dPttPreBuild.TargetExt=.wxi -dPttPreBuild.TargetFileName=Ptt.wxi -dPttPreBuild.TargetName=Ptt -dPttPreBuild.TargetPath=C:\svn\trunk\Installation\Wix\PttModule\Ptt.wxi -out obj\Release\ -arch x86 PttModule.wxs obj\Release\Product.Generated.wxs Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved. PttModule.wxs Product.Generated.wxs Link: C:\Program Files (x86)\Windows Installer XML v3.5\bin\Light.exe -cultures:null -out C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -pdbout C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.wixpdb obj\Release\PttModule.wixobj obj\Release\Product.Generated.wixobj Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved. Done Building Project C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj (default targets). -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, July 20, 2011 12:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 On 19-Jul-11 12:25, Mark Modrall wrote: For #2, we have some installation stuff we only want done once (the stuff that the custom action does). So the first thing the custom action exe does is try to check the registry setting to see if it's been done (that's what's failing now). When the custom action code is done, it sets that registry flag to show it's been done. See http://www.joyofsetup.com/2007/07/01/semi-custom-actions/. -- sig://boB http://joyofsetup.com/ -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Okay, I compared the output of the msbuild log and the devenv log. When it comes to this one project, the only difference in the candle command arguments was -dDevEnvDir=*Undefined if not building from within Visual Studio* And the light arguments were the same. But for some result the outputs are not the same. It does work if I use devenv.exe from the command line so I guess I'll stick with that... Thanks Mark -Original Message- From: Tobias S [mailto:tobias.s1...@gmail.com] Sent: Wednesday, July 20, 2011 11:37 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 VS2010 includes the same MSBuild concept than building within MSBuild directly. Try to build it within VS2010 and then copy the commands from build output and maybe remove the product.generated.* stuff and try it that way. What's the output when building it in visual studio Command Prompt ? Mean there msbuild mySolution.sln ? 2011/7/20 Mark Modrall mmodr...@mzinga.com: Thanks for the link, Bob; I'll give it a read. By the by, are there known quirks when running a Wix solution via msbuild? My build works just fine when I'm in VS 2010, but when I use msbuild to launch it there's one module that doesn't build and doesn't give any errors. In the build log, I see candle and light getting run, but in obj\Release I only see Product.Generated.wxs and nothing in bin\Release (no merge module). What's in the log is below. The other wix projects are producing msm and msi but for some reason this one quirks out. Should I be using devenv.exe on the command line instead? Thanks Mark Compile: C:\Program Files (x86)\Windows Installer XML v3.5\bin\candle.exe -dDevEnvDir=*Undefined if not building from within Visual Studio* -dSolutionDir=C:\svn\trunk\Installation\Wix\ -dSolutionExt=.sln -dSolutionFileName=AllProducts.sln -dSolutionName=AllProducts -dSolutionPath=C:\svn\trunk\Installation\Wix\AllProducts.sln -dConfiguration=Release -dOutDir=bin\Release\ -dPlatform=x86 -dProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dProjectExt=.wixproj -dProjectFileName=PttModule.wixproj -dProjectName=PttModule -dProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj -dTargetDir=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\ -dTargetExt=.msm -dTargetFileName=PttModule.msm -dTargetName=PttModule -dTargetPath=C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -dPttPreBuild.Configuration=Release -dPttPreBuild.FullConfiguration=Release|Win32 -dPttPreBuild.Platform=Win32 -dPttPreBuild.ProjectDir=C:\svn\trunk\Installation\Wix\PttModule\ -dPttPreBuild.ProjectExt=.vcxproj -dPttPreBuild.ProjectFileName=PttPreBuild.vcxproj -dPttPreBuild.ProjectName=PttPreBuild -dPttPreBuild.ProjectPath=C:\svn\trunk\Installation\Wix\PttModule\PttPreBuild.vcxproj -dPttPreBuild.TargetDir=C:\svn\trunk\Installation\Wix\PttModule\ -dPttPreBuild.TargetExt=.wxi -dPttPreBuild.TargetFileName=Ptt.wxi -dPttPreBuild.TargetName=Ptt -dPttPreBuild.TargetPath=C:\svn\trunk\Installation\Wix\PttModule\Ptt.wxi -out obj\Release\ -arch x86 PttModule.wxs obj\Release\Product.Generated.wxs Microsoft (R) Windows Installer Xml Compiler version 3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved. PttModule.wxs Product.Generated.wxs Link: C:\Program Files (x86)\Windows Installer XML v3.5\bin\Light.exe -cultures:null -out C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.msm -pdbout C:\svn\trunk\Installation\Wix\PttModule\bin\Release\PttModule.wixpdb obj\Release\PttModule.wixobj obj\Release\Product.Generated.wixobj Microsoft (R) Windows Installer Xml Linker version 3.5.2519.0 Copyright (C) Microsoft Corporation. All rights reserved. Done Building Project C:\svn\trunk\Installation\Wix\PttModule\PttModule.wixproj (default targets). -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Wednesday, July 20, 2011 12:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 On 19-Jul-11 12:25, Mark Modrall wrote: For #2, we have some installation stuff we only want done once (the stuff that the custom action does). So the first thing the custom action exe does is try to check the registry setting to see if it's been done (that's what's failing now). When the custom action code is done, it sets that registry flag to show it's been done. See http://www.joyofsetup.com/2007/07/01/semi-custom-actions/. -- sig://boB http://joyofsetup.com/ -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Okay, I'm sure this is going to sound like a dumb question, but... In these old Wix 2.0 projects I'm upgrading, we generate a bunch of msms that get pulled into the several product msis. In the module projects there was something like the following: Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLDIR ... /Directory /Directory Then the Merge references would be included in the product directory tree. Chalk it up to my ignorance, but I thought the Directory Id=INSTALLDIR in the modules seemed superfluous, so trying to clean things up while I did the upgrade, I removed them - thinking that the Merge element in the desired Directory of the Product was sufficient to say where I wanted the result put. The msis all build but when I went to install one, all of the msm output gets dumped in the Product INSTALLDIR, not in the subdirectory defined in the Product setup. Below are some examples of what I mean, and I was just wondering why the modules had to have that extra directory declaration? Obviously there's something I'm missing. Thanks Mark Module Id=_3rdPartyModule Language=1033 Version=1.0.0.0 Package Id=AD4BA45B-4093-4ff6-A532-21DB00F9B5AB Description=3rd Party Components Comments=Functionality provided by external modules Manufacturer=MyCompany InstallerVersion=300 / Directory Id=TARGETDIR Name=SourceDir Directory Id=INSTALLDIR Component Id=AspChart.Dll Guid=215DE3EB-BE47-4741-8C0B-3AFF00E51F5C SharedDllRefCount=yes File Id=ASPCHART.DLL Name=ASPCHART.DLL Source=$(var.TheBuildFolder)\Build\3rdParty\AspChart.dll Vital=yes KeyPath=yes TypeLib Id=F174ED14-F7A9-11D0-A014-080009AB4447 Language=0 MajorVersion=1 MinorVersion=0 Description=ASPChart Library HelpDirectory=TARGETDIR Cost=1 Advertise=yes Class Id=F174ED16-F7A9-11D0-A014-080009AB4447 Context=InprocServer32 Description=ChartObject Version=1.0 ProgId Id=ASPChart.Chart Description=ChartObject / /Class /TypeLib /File /Component /Directory /Directory /Module Included in Product Id=$(var.GUID) Name=Prospero Forums Server v1.00.$(var.Version) Language=1033 Version=1.0.$(var.Version) Manufacturer=Prospero Technologies Package Id=* Description=Prospero Forums Server Installer Comments=http://www.prospero.com; InstallerVersion=300 InstallScope=perMachine Compressed=yes/ Media Id=1 Cabinet=Product.cab EmbedCab=yes / Property Id=TARGETDIR Value=C:\MyHome / Directory Id=TARGETDIR Name=SourceDir Directory Id=Binaries Name=Binaries Merge Id=_3rdPartyModule Language=1033 SourceFile=..\3rdPartyModule\bin\$(var.config)\3rdPartyModule.msm DiskId=1 / Component Id=InstallConfig Guid=D746C5C0-12CB-4d4a-AA65-361D578F09F5 File Id='InstallConfig.exe' Name='InstallConfig.exe' DiskId='1' Source='..\InstallConfig\bin\$(var.config)\InstallConfig.exe' Vital='yes' / File Id='InstallConfig.pdb' Name='InstallConfig.pdb' DiskId='1' Source='..\InstallConfig\bin\$(var.config)\InstallConfig.pdb' / /Component /Directory Directory Id=Other Name=Other Merge Id=OtherModule Language=1033 SourceFile=..\OtherModule\bin\$(var.config)\OtherModule.msm DiskId=1 / /Directory /Directory Feature Id=Complete Title=Prospero Forums Server Description=The complete package. Level=1 MergeRef Id=_3rdPartyModule / /Feature /Product -- 10 Tips for Better Web Security Learn 10 ways to better secure your business today. Topics covered include: Web security, SSL, hacker attacks Denial of Service (DoS), private keys, security Microsoft Exchange, secure Instant Messaging, and much more. http://www.accelacomm.com/jaw/sfnl/114/51426210/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Hi... I'm trying to upgrade my Wix 2.0 installer scripts to Wix 3.5, and at the moment I'm stuck on the fact that my product msi's are coming out essentially empty and I don't see why. The individual merge modules look like they're about the right size but none of the content is ending up in the msi. I'm seeing the empty shell of the directory structures in .\bin\Release\ for the product installer but none of the files are in there either. The project below used to work in 2.0; essentially all I tweaked so far was the InstallerVersion and the root Directory Id=TARGETDIR instead of INSTALLDIR. I've found some 3.5 sample projects, and the biggest difference I can see is a lot more use of DirectoryRef and ComponentRef in Feature. Does anyone see if I'm doing something obviously wrong in a 3.5 sense? Thanks Mark Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; ?ifdef env.PTBuildVersion ? ?define Version=$(env.PTBuildVersion) ? ?else? ?define Version=0.0 ? ?endif? ?ifdef env.TheBuildFolder ? ?define TheBuildFolder=$(env.TheBuildFolder) ? ?else? ?define TheBuildFolder=..\..\.. ? ?endif? ?ifdef env.PTBuildConfig ? ?define config=$(env.PTBuildConfig) ? ?else? ?define config=Debug ? ?endif? ?if $(env.PTBuildPlatform)=x64 ? ?define PPlat=x64 ? ?else? ?define PPlat=x86 ? ?endif? ?define ForumGUID=CDFDFE94-1896-4BE5-AECB-23083B74E484 ? Product Id=$(var.ForumGUID) Name=My Product v1.00.$(var.Version) Language=1033 Version=1.0.$(var.Version) Manufacturer=My Company Package Id=* Description=Prospero Forums Server Installer Comments=bar InstallerVersion=300 Platform=$(var.PPlat)/ Media Id=1 Cabinet=Product.cab EmbedCab=yes / Property Id=INSTALLDIR Value=C:\Mydir / Property Id=DISABLEROLLBACK Value=1 / Directory Id=TARGETDIR Name=SourceDir Directory Id=Binaries Name=Binaries Merge Id=AuthModule Language=1033 SourceFile=..\AuthModule\bin\$(var.config)\AuthModule.msm DiskId=1 / ... bunch more merges Merge Id=_3rdPartyModule Language=1033 SourceFile=..\3rdPartyModule\bin\$(var.config)\3rdPartyModule.msm DiskId=1 / Component Id=InstallConfig Guid=D746C5C0-12CB-4d4a-AA65-361D578F09F5 File Id='InstallConfig.exe' Name='InstallConfig.exe' DiskId='1' Source='..\InstallConfig\bin\$(var.config)\InstallConfig.exe' Vital='yes' / File Id='InstallConfig.pdb' Name='InstallConfig.pdb' DiskId='1' Source='..\InstallConfig\bin\$(var.config)\InstallConfig.pdb' / /Component /Directory Directory Id=ASP Name=ASP Merge Id=ForumsAspModule Language=1033 SourceFile=..\ForumsAspModule\bin\$(var.config)\ForumsAspModule.msm DiskId=1 / /Directory Directory Id=Ptt Name=Ptt Merge Id=PttModule Language=1033 SourceFile=..\PttModule\bin\$(var.config)\PttModule.msm DiskId=1 / /Directory /Directory Feature Id=Complete Title=Prospero Forums Server Description=The complete package. Level=1 MergeRef Id=DelphiAuthModule / ... bunch more mergerefs MergeRef Id=_3rdPartyModule / ComponentRef Id=InstallConfig / /Feature Property Id=ALLUSERS2/Property Property Id=INSTALLLEVEL3/Property /Product /Wix -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Thanks Bob, that got the content into the installer package - which got me to the point of trying to run it. I ran into a couple of new issues 1) Looking at the installer log, it's unpacking into a directory other than the INSTALLDIR; throughout I've been a little confused going to 3.5 about the relation of INSTALLDIR and TARGETDIR; did TARGETDIR supplant/replace INSTALLDIR? As noted before, I used to have my root Directory Id=INSTALLDIR and 3.5 said it had to be TARGETDIR; was I to take from that it should be TARGETDIR throughout? 2) I have a custom action in my installer, and that needs to look at/tweak registry settings. On top of moving from VS 2005 to VS 2010, we're also trying to move from Server 2003 to Server 2008, and like Windows 7, etc it's a lot more snarky about execution permissions. I saw this in the 3.5 manual for the CustomAction element: Impersonate YesNoType This attribute specifies whether the Windows Installer, which executes as LocalSystem, should impersonate the user context of the installing user when executing this custom action. Typically the value should be 'yes', except when the custom action needs elevated privileges to apply changes to the machine. To run things that need more serious access, I take it I should have an attribute Impersonate=no? Thanks mark -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, July 19, 2011 10:33 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 On 19-Jul-11 10:20, Mark Modrall wrote: Package Id=* Description=Prospero Forums Server Installer Comments=bar InstallerVersion=300 Platform=$(var.PPlat)/ Try Compressed=yes. -- sig://boB http://joyofsetup.com/ -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Hi Bob... For #2, we have some installation stuff we only want done once (the stuff that the custom action does). So the first thing the custom action exe does is try to check the registry setting to see if it's been done (that's what's failing now). When the custom action code is done, it sets that registry flag to show it's been done. As I said a lot that stuff just used to slide by in Windows Server 2003 when running as an administrator... Thanks Mark -Original Message- From: Bob Arnson [mailto:b...@joyofsetup.com] Sent: Tuesday, July 19, 2011 11:45 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 On 19-Jul-11 11:10, Mark Modrall wrote: 1) Looking at the installer log, it's unpacking into a directory other than the INSTALLDIR; throughout I've been a little confused going to 3.5 about the relation of INSTALLDIR and TARGETDIR; did TARGETDIR supplant/replace INSTALLDIR? As noted before, I used to have my rootDirectory Id=INSTALLDIR and 3.5 said it had to be TARGETDIR; was I to take from that it should be TARGETDIR throughout? WiX v2 and v3 have the same requirements about TARGETDIR, because that's what MSI requires. INSTALLDIR is just a convention. 2) I have a custom action in my installer, and that needs to look at/tweak registry settings. Custom actions should be avoided for things like registry that MSI already handles. What do you need to do that you can't do in MSI? -- sig://boB http://joyofsetup.com/ -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Magic Quadrant for Content-Aware Data Loss Prevention Research study explores the data loss prevention market. Includes in-depth analysis on the changes within the DLP market, and the criteria used to evaluate the strengths and weaknesses of these DLP solutions. http://www.accelacomm.com/jaw/sfnl/114/51385063/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Thanks for your response, Pally... I've got things converted over for the most part but am still puzzled by a few new warnings. One is this one: Warning 58 ICE25: Possible dependency failure as we do not find module@1033 v in ModuleSignature table light.exe 0 1 MyProduct All my modules have Language=1033 in them, so I'm puzzled what the warning is about. The other is that when I have: Media Id=1 Cabinet=Product.cab EmbedCab=yes / In my build projects, I get the warning The cabinet 'Product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it. But if I don't have it, I get a lot of errors about having an undefined media reference with the DiskId=1 attributes on file and module refs. If I take the DiskId=1 off, it says it's required. Warnings are better than errors, but I'm trying to understand what's driving them. Thanks Mark -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, July 18, 2011 7:00 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 I don't think there is an upgrade from v2.0 .wixproj to v3.x. Votive was very much experimental unsupported in WiX v2.0. You're probably better off creating new .wixproj files in v3.5 as it's pretty quick to do. Palbinder Sandher Software Deployment Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 17 July 2011 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 I had been running msbuild to product my msis and it wasn't throwing any errors, but now I went into my solution using the IDE (both 2005 and 2010). In both I get the error that I have to use the IDE to upgrade my .wixproj (2.0) files but in the IDE it just says all the projects are (unavailable). I'm not prompted for upgrade nor does VS appear to do them. It 2.0 = 3.5 just too big a jump for automated upgrade? Thanks Mark -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, July 16, 2011 1:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 The Windows Installer Error Message http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says: 2756 The property '[2]' was used as a directory property in one or more tables, but no value was ever assigned. That suggest something is wrong in your MSI. A verbose log file will probalby tell you more. On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall mmodr...@mzinga.com wrote: Hi everybody... I imagine I'll take some flak for this, but we still have installers being cobbled together by Wix 2.0. Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 (and moving our production environment from Windows Server 2003 to 2008). I just got all the product build converted and running under VS 2010 (with a side nightmare thanks to Sourcegear Vault). My Wix project cranked out .msis without complaint. But when I went to install the msi on Windows 2008, it threw an exception 2765. Not a lot of information on what the problem is. Not sure if it's some kind of difference between W2003 and 2008, the version of the msi installer on the os or what. It did say there was one specific merge module at the time, a .net assembly that was going to be put in the gac. I'd run Wix under VS 2005 figuring that the bundling of the build product didn't need to be upgraded, but to start eliminating variables I upgraded the Wix solution to VS 2010 and tried the msi outcome of that. Same error. I went to install Wix 3 (baby steps), but that installer still only offered VS 2005 integration. I haven't worked with Windows Server 2008 much and I haven't seen this installer error before. Is this a Wix compatibility issue or an OS issue? Thanks Mark -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
I guess I spoke too soon... Early in the Wix 2.0 = 3.5 upgrade, I was seeing the error: Error 54 The Directory with Id 'INSTALLDIR' is not a valid root directory. There may only be a single root directory per product or module and its Id attribute value must be 'TARGETDIR' and its Name attribute value must be 'SourceDir'. So I switched the root Directory Id=TARGETDIR and the error stopped happening - *but* when I looked more closely at the output, my .msi was nearly empty and all the subdirectories that were supposed to be *in* the msi are instead peer directories to it in MyProduct\bin\Release\. Seems like there's some 2.0/3.5 incompatibility speed bump I haven't internalized yet... Any tips? Thanks Mark -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Monday, July 18, 2011 5:15 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 Thanks for your response, Pally... I've got things converted over for the most part but am still puzzled by a few new warnings. One is this one: Warning 58 ICE25: Possible dependency failure as we do not find module@1033 v in ModuleSignature table light.exe 0 1 MyProduct All my modules have Language=1033 in them, so I'm puzzled what the warning is about. The other is that when I have: Media Id=1 Cabinet=Product.cab EmbedCab=yes / In my build projects, I get the warning The cabinet 'Product.cab' does not contain any files. If this installation contains no files, this warning can likely be safely ignored. Otherwise, please add files to the cabinet or remove it. But if I don't have it, I get a lot of errors about having an undefined media reference with the DiskId=1 attributes on file and module refs. If I take the DiskId=1 off, it says it's required. Warnings are better than errors, but I'm trying to understand what's driving them. Thanks Mark -Original Message- From: Pally Sandher [mailto:pally.sand...@iesve.com] Sent: Monday, July 18, 2011 7:00 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 I don't think there is an upgrade from v2.0 .wixproj to v3.x. Votive was very much experimental unsupported in WiX v2.0. You're probably better off creating new .wixproj files in v3.5 as it's pretty quick to do. Palbinder Sandher Software Deployment Engineer T: +44 (0) 141 945 8500 F: +44 (0) 141 945 8501 http://www.iesve.com **Design, Simulate + Innovate with the Virtual Environment** Integrated Environmental Solutions Limited. Registered in Scotland No. SC151456 Registered Office - Helix Building, West Of Scotland Science Park, Glasgow G20 0SP Email Disclaimer -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: 17 July 2011 15:16 To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 I had been running msbuild to product my msis and it wasn't throwing any errors, but now I went into my solution using the IDE (both 2005 and 2010). In both I get the error that I have to use the IDE to upgrade my .wixproj (2.0) files but in the IDE it just says all the projects are (unavailable). I'm not prompted for upgrade nor does VS appear to do them. It 2.0 = 3.5 just too big a jump for automated upgrade? Thanks Mark -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, July 16, 2011 1:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 The Windows Installer Error Message http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says: 2756 The property '[2]' was used as a directory property in one or more tables, but no value was ever assigned. That suggest something is wrong in your MSI. A verbose log file will probalby tell you more. On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall mmodr...@mzinga.com wrote: Hi everybody... I imagine I'll take some flak for this, but we still have installers being cobbled together by Wix 2.0. Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 (and moving our production environment from Windows Server 2003 to 2008). I just got all the product build converted and running under VS 2010 (with a side nightmare thanks to Sourcegear Vault). My Wix project cranked out .msis without complaint. But when I went to install the msi on Windows 2008, it threw an exception 2765. Not a lot of information on what the problem is. Not sure if it's some kind of difference between W2003 and 2008, the version of the msi installer on the os or what. It did say there was one specific merge module
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Hi Rob... I enabled verbose logging and I didn't really see any more explanation in the log file. I did find this old thread: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Installing-NET-4-assemblies-into-the-GAC-using-WiX-2-td4443469.html Which seemed to be pertinent, so I upgraded to Wix 3.5 (though I didn't do anything particular to change my wix projects), but no luck. Still have the same error. I found another thread where you advised someone to add a supportedRuntime entry to the light config, but I checked and light already had it in there. I know this is an ignorant question, but what's the relation between Tallow and light? Thanks Mark -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, July 16, 2011 1:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 The Windows Installer Error Message http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says: 2756 The property '[2]' was used as a directory property in one or more tables, but no value was ever assigned. That suggest something is wrong in your MSI. A verbose log file will probalby tell you more. On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall mmodr...@mzinga.com wrote: Hi everybody... I imagine I'll take some flak for this, but we still have installers being cobbled together by Wix 2.0. Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 (and moving our production environment from Windows Server 2003 to 2008). I just got all the product build converted and running under VS 2010 (with a side nightmare thanks to Sourcegear Vault). My Wix project cranked out .msis without complaint. But when I went to install the msi on Windows 2008, it threw an exception 2765. Not a lot of information on what the problem is. Not sure if it's some kind of difference between W2003 and 2008, the version of the msi installer on the os or what. It did say there was one specific merge module at the time, a .net assembly that was going to be put in the gac. I'd run Wix under VS 2005 figuring that the bundling of the build product didn't need to be upgraded, but to start eliminating variables I upgraded the Wix solution to VS 2010 and tried the msi outcome of that. Same error. I went to install Wix 3 (baby steps), but that installer still only offered VS 2005 integration. I haven't worked with Windows Server 2008 much and I haven't seen this installer error before. Is this a Wix compatibility issue or an OS issue? Thanks Mark -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
I had been running msbuild to product my msis and it wasn't throwing any errors, but now I went into my solution using the IDE (both 2005 and 2010). In both I get the error that I have to use the IDE to upgrade my .wixproj (2.0) files but in the IDE it just says all the projects are (unavailable). I'm not prompted for upgrade nor does VS appear to do them. It 2.0 = 3.5 just too big a jump for automated upgrade? Thanks Mark -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Saturday, July 16, 2011 1:03 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010 The Windows Installer Error Message http://msdn.microsoft.com/en-us/library/aa372835(VS.85).aspx says: 2756 The property '[2]' was used as a directory property in one or more tables, but no value was ever assigned. That suggest something is wrong in your MSI. A verbose log file will probalby tell you more. On Fri, Jul 15, 2011 at 2:39 PM, Mark Modrall mmodr...@mzinga.com wrote: Hi everybody... I imagine I'll take some flak for this, but we still have installers being cobbled together by Wix 2.0. Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 (and moving our production environment from Windows Server 2003 to 2008). I just got all the product build converted and running under VS 2010 (with a side nightmare thanks to Sourcegear Vault). My Wix project cranked out .msis without complaint. But when I went to install the msi on Windows 2008, it threw an exception 2765. Not a lot of information on what the problem is. Not sure if it's some kind of difference between W2003 and 2008, the version of the msi installer on the os or what. It did say there was one specific merge module at the time, a .net assembly that was going to be put in the gac. I'd run Wix under VS 2005 figuring that the bundling of the build product didn't need to be upgraded, but to start eliminating variables I upgraded the Wix solution to VS 2010 and tried the msi outcome of that. Same error. I went to install Wix 3 (baby steps), but that installer still only offered VS 2005 integration. I haven't worked with Windows Server 2008 much and I haven't seen this installer error before. Is this a Wix compatibility issue or an OS issue? Thanks Mark -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] How to burn petrified wood? Upgrading from VS 2005 to 2010
Hi everybody... I imagine I'll take some flak for this, but we still have installers being cobbled together by Wix 2.0. Recently I was tasked with upgrading our product builds from VS 2005 to VS 2010 (and moving our production environment from Windows Server 2003 to 2008). I just got all the product build converted and running under VS 2010 (with a side nightmare thanks to Sourcegear Vault). My Wix project cranked out .msis without complaint. But when I went to install the msi on Windows 2008, it threw an exception 2765. Not a lot of information on what the problem is. Not sure if it's some kind of difference between W2003 and 2008, the version of the msi installer on the os or what. It did say there was one specific merge module at the time, a .net assembly that was going to be put in the gac. I'd run Wix under VS 2005 figuring that the bundling of the build product didn't need to be upgraded, but to start eliminating variables I upgraded the Wix solution to VS 2010 and tried the msi outcome of that. Same error. I went to install Wix 3 (baby steps), but that installer still only offered VS 2005 integration. I haven't worked with Windows Server 2008 much and I haven't seen this installer error before. Is this a Wix compatibility issue or an OS issue? Thanks Mark -- AppSumo Presents a FREE Video for the SourceForge Community by Eric Ries, the creator of the Lean Startup Methodology on Lean Startup Secrets Revealed. This video shows you how to validate your ideas, optimize your ideas and identify your business strategy. http://p.sf.net/sfu/appsumosfdev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix and tricky environment variables
Hi John... Actually, putting your .net pdbs in _NT_SYMBOL_PATH *does* work; that's why I'm trying to do it. http://blog.softwareishardwork.com/2010/02/enable-stack-trace-line-numbers-in.html I came to adding it to my installers after proving that it worked by doing it manually. Your note about keeping the pdbs in reserve for performance reasons is a good one, and I'll keep that in mind. Thanks Mark -Original Message- From: John Robbins [mailto:j...@wintellect.com] Sent: Thursday, February 10, 2011 10:33 PM To: General discussion for Windows Installer XML toolset.; Mark Modrall Subject: RE: [WiX-users] Wix and tricky environment variables Mark, As someone who's concentrated on debugging and debuggers his whole career, it warms my heart to hear people talking about _NT_SYMBOL_PATH. :) However, _NT_SYMBOL_PATH is only used by debuggers. The .NET StackTrace class, which is generating the call stacks in your exceptions, will only look for the PDB files in the same directory as the .EXE. So even if you add this to your installer, you still won't get source and line information on any exception stack trace. Also, I recommend that you keep the PDB file installer separate from the main installer. As there's extra file I/O and overhead for reading the PDB files when the exceptions are thrown, you only want to install the PDB files when you are certain you've got a problem and need that information. Hope it helps! John Wintellect http://www.wintellect.com +1-877-968-5528 -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Thursday, February 10, 2011 6:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables Well, you caught me flat footed with the App Path stuff, so I could be misunderstanding the Symbol Server stuff :) But here's my understanding of what that's about: 1) Microsoft has a public service that will vend .pdb files for Microsoft components and you can set _NT_SYMBOL_PATH to pull from there 1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server locally if you want with a special syntax 2) If you're using a debugger and interactively watching something, you can use Symbol Server directly without _NT_SYMBOL_PATH 3) For your own symbols you're on your own. Though I gather from your question (SDK vs internal process), there may be a way to register your symbols in the Microsoft Symbol Server. I might be missing something, but it doesn't seem like you can get away from _NT_SYMBOL_PATH entirely. At the least you have to register your symbols with Microsoft and set _NT_SYMBOL_PATH to point at the server. Our use is for logging exception stack traces in a database, not hands-on interactive debugging. The problem is that when you put things in the GAC it's considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too. If the pdbs are lying right next to the .exes and .dbgs, you don't need to use _NT_SYMBOL_PATH because the default behavior checks the immediate environs before looking in the paths defined in _NT_SYMBOL_PATH. Alas the GAC messes that up. We've always been dumping the .pdbs in our install directory but the stack traces that get logged blank out on anything that's gone through the GAC because the executables aren't located there. Another frustrating thing about the gac is that even if you have a copy of the executable, say, in the /bin directory of your ASP.Net application it's going to use the GAC version instead and not infer anything about where your symbols might be from the one in your /bin directory. So we're down to getting _NT_SYMBOL_PATH set properly in our installer. But not wanting the installer to keep accreting our directory on the front/back every time we install. And not destroying an environment variable that's a shared resource in the process, which is why I'm trying to form the right test in Wix to see if we're already in there. In our case, we're a saas provider, installing our stuff across a farm of ~100 of our servers. We're not a re-seller or SDK vendor. We're just trying to manage our farm. Thanks Mark -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 8:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables I'm no expert wrt to symbols so treat this advice as an old drunk sailor sitting at the bar telling a story. :-) I did a google search and a lot of people seem to not like _NT_SYMBOL_PATH. There seems to be some good things to be said about Symbol Server. Can I assume that your installer is some sort of SDK? Or are you perhaps automating an internal process? Any advice given would depend on the answer to that question (e.g. does the end user want to contol his own
Re: [WiX-users] Wix and tricky environment variables
That's a very good question, Ed. I've only tested it on our boxes, and we only ever have 1 rev of our code there at a time. Don't know what would happen if we started installing multiple versions, but thanks for making that point. Mark -Original Message- From: Maillet, Ed [mailto:email...@unum.com] Sent: Friday, February 11, 2011 8:06 AM To: General discussion for Windows Installer XML toolset.; John Robbins Subject: Re: [WiX-users] Wix and tricky environment variables Doesn't that only work if you have one version of an assembly? Two Acme.dlls (v1 and v2) in the gac present a problem, doesn't it? -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Friday, February 11, 2011 7:19 AM To: John Robbins; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables Hi John... Actually, putting your .net pdbs in _NT_SYMBOL_PATH *does* work; that's why I'm trying to do it. http://blog.softwareishardwork.com/2010/02/enable-stack-trace-line-numbers-in.html I came to adding it to my installers after proving that it worked by doing it manually. Your note about keeping the pdbs in reserve for performance reasons is a good one, and I'll keep that in mind. Thanks Mark -Original Message- From: John Robbins [mailto:j...@wintellect.com] Sent: Thursday, February 10, 2011 10:33 PM To: General discussion for Windows Installer XML toolset.; Mark Modrall Subject: RE: [WiX-users] Wix and tricky environment variables Mark, As someone who's concentrated on debugging and debuggers his whole career, it warms my heart to hear people talking about _NT_SYMBOL_PATH. :) However, _NT_SYMBOL_PATH is only used by debuggers. The .NET StackTrace class, which is generating the call stacks in your exceptions, will only look for the PDB files in the same directory as the .EXE. So even if you add this to your installer, you still won't get source and line information on any exception stack trace. Also, I recommend that you keep the PDB file installer separate from the main installer. As there's extra file I/O and overhead for reading the PDB files when the exceptions are thrown, you only want to install the PDB files when you are certain you've got a problem and need that information. Hope it helps! John Wintellect http://www.wintellect.com +1-877-968-5528 -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Thursday, February 10, 2011 6:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables Well, you caught me flat footed with the App Path stuff, so I could be misunderstanding the Symbol Server stuff :) But here's my understanding of what that's about: 1) Microsoft has a public service that will vend .pdb files for Microsoft components and you can set _NT_SYMBOL_PATH to pull from there 1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server locally if you want with a special syntax 2) If you're using a debugger and interactively watching something, you can use Symbol Server directly without _NT_SYMBOL_PATH 3) For your own symbols you're on your own. Though I gather from your question (SDK vs internal process), there may be a way to register your symbols in the Microsoft Symbol Server. I might be missing something, but it doesn't seem like you can get away from _NT_SYMBOL_PATH entirely. At the least you have to register your symbols with Microsoft and set _NT_SYMBOL_PATH to point at the server. Our use is for logging exception stack traces in a database, not hands-on interactive debugging. The problem is that when you put things in the GAC it's considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too. If the pdbs are lying right next to the .exes and .dbgs, you don't need to use _NT_SYMBOL_PATH because the default behavior checks the immediate environs before looking in the paths defined in _NT_SYMBOL_PATH. Alas the GAC messes that up. We've always been dumping the .pdbs in our install directory but the stack traces that get logged blank out on anything that's gone through the GAC because the executables aren't located there. Another frustrating thing about the gac is that even if you have a copy of the executable, say, in the /bin directory of your ASP.Net application it's going to use the GAC version instead and not infer anything about where your symbols might be from the one in your /bin directory. So we're down to getting _NT_SYMBOL_PATH set properly in our installer. But not wanting the installer to keep accreting our directory on the front/back every time we install. And not destroying an environment variable that's a shared resource in the process, which is why I'm trying to form the right test in Wix to see if we're already in there. In our case, we're a saas provider, installing our stuff
Re: [WiX-users] Wix and tricky environment variables
Hi Chris... Thanks for the tip on App Path; I didn't know about that one. Unfortunately, I used PATH as an example because I thought that's the one people would be most familiar with, but there are a number of environment variables that function similarly. My own fault for not being more direct. What I'm actually trying to maintain is _NT_SYMBOL_PATH. I'm trying to add the directory where my .pdbs live so that my GAC'ed components can still get symbol info in stack traces. _NT_SYMBOL_PATH works similarly to PATH in terms of syntax and function and Wix would act on them pretty much the same way. Mark -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 6:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables I'll be honest, it's 2011 and I'm hard pressed to understand why software applications still cling to the need to be in the PATH... a concept that originated some 30 years earlier. Can you redesign your application to not need to be in the path? Or, can you use AppPaths to make certain executables and http://www.sepago.de/d/helge/2010/08/26/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer Otherwise, I'd suggest that if the built in Env@Part First|Last isn't working that you could change it to All and then use a custom action to do your own parsing ( dedupication, sorting, appending and so on. ) I'd test it really good though because I've never done this and I'm not sure what the gotchas would be. --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Mark Modrall mmodr...@mzinga.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Wed, February 9, 2011 2:58:40 PM Subject: [WiX-users] Wix and tricky environment variables Hi... I'm looking to get my installer to appropriately set an entry in one of those tricky environment variables, like %PATH%. By tricky I mean shared and accretive - it's a multi-value crossroads that everybody and their brother will be mucking with. I want to make sure our addition gets in there but don't want to just keep appending our root every time the installer is run. In the same vein, I can't just blank the variable when our product is uninstalled. So I was thinking I'd add a custom action type 51 to get the value into a property and a conditionalized component with a test on the value, but I'm not quite clear on how all the pieces would fit together... Something like Component Id=SetPath Condition![CDATA[NOT EnvPathC:\Program Files\Mypath;]]/Condition Environment Id=EnvSetPath Action=set Name=PATH Part=first Permanent=yes System=yes Value=C:\Program Files\MyPath / /Component ... CustomAction Id=EnvPath Property=EnvPath Value=[%PATH] / Problem is that all the examples I'm cribbing from are using ellipsis too, so I'm not sure if I have to declare what phase the custom action will be executed in, etc. Am I on the right track? Thanks Mark -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Wix and tricky environment variables
Well, you caught me flat footed with the App Path stuff, so I could be misunderstanding the Symbol Server stuff :) But here's my understanding of what that's about: 1) Microsoft has a public service that will vend .pdb files for Microsoft components and you can set _NT_SYMBOL_PATH to pull from there 1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server locally if you want with a special syntax 2) If you're using a debugger and interactively watching something, you can use Symbol Server directly without _NT_SYMBOL_PATH 3) For your own symbols you're on your own. Though I gather from your question (SDK vs internal process), there may be a way to register your symbols in the Microsoft Symbol Server. I might be missing something, but it doesn't seem like you can get away from _NT_SYMBOL_PATH entirely. At the least you have to register your symbols with Microsoft and set _NT_SYMBOL_PATH to point at the server. Our use is for logging exception stack traces in a database, not hands-on interactive debugging. The problem is that when you put things in the GAC it's considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too. If the pdbs are lying right next to the .exes and .dbgs, you don't need to use _NT_SYMBOL_PATH because the default behavior checks the immediate environs before looking in the paths defined in _NT_SYMBOL_PATH. Alas the GAC messes that up. We've always been dumping the .pdbs in our install directory but the stack traces that get logged blank out on anything that's gone through the GAC because the executables aren't located there. Another frustrating thing about the gac is that even if you have a copy of the executable, say, in the /bin directory of your ASP.Net application it's going to use the GAC version instead and not infer anything about where your symbols might be from the one in your /bin directory. So we're down to getting _NT_SYMBOL_PATH set properly in our installer. But not wanting the installer to keep accreting our directory on the front/back every time we install. And not destroying an environment variable that's a shared resource in the process, which is why I'm trying to form the right test in Wix to see if we're already in there. In our case, we're a saas provider, installing our stuff across a farm of ~100 of our servers. We're not a re-seller or SDK vendor. We're just trying to manage our farm. Thanks Mark -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 8:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables I'm no expert wrt to symbols so treat this advice as an old drunk sailor sitting at the bar telling a story. :-) I did a google search and a lot of people seem to not like _NT_SYMBOL_PATH. There seems to be some good things to be said about Symbol Server. Can I assume that your installer is some sort of SDK? Or are you perhaps automating an internal process? Any advice given would depend on the answer to that question (e.g. does the end user want to contol his own destiny or is it a captive audience ). However, I'm not going to go there anyways because I'm just an old drunk old sailor today. (PS- No offense meant for any squids that might be out there. Oorah ) --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me - Original Message From: Mark Modrall mmodr...@mzinga.com To: General discussion for Windows Installer XML toolset. wix-users@lists.sourceforge.net Sent: Thu, February 10, 2011 7:39:08 AM Subject: Re: [WiX-users] Wix and tricky environment variables Hi Chris... Thanks for the tip on App Path; I didn't know about that one. Unfortunately, I used PATH as an example because I thought that's the one people would be most familiar with, but there are a number of environment variables that function similarly. My own fault for not being more direct. What I'm actually trying to maintain is _NT_SYMBOL_PATH. I'm trying to add the directory where my .pdbs live so that my GAC'ed components can still get symbol info in stack traces. _NT_SYMBOL_PATH works similarly to PATH in terms of syntax and function and Wix would act on them pretty much the same way. Mark -Original Message- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 6:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and tricky environment variables I'll be honest, it's 2011 and I'm hard pressed to understand why software applications still cling to the need to be in the PATH... a concept that originated some 30 years earlier. Can you redesign your application to not need to be in the path
[WiX-users] Wix and tricky environment variables
Hi... I'm looking to get my installer to appropriately set an entry in one of those tricky environment variables, like %PATH%. By tricky I mean shared and accretive - it's a multi-value crossroads that everybody and their brother will be mucking with. I want to make sure our addition gets in there but don't want to just keep appending our root every time the installer is run. In the same vein, I can't just blank the variable when our product is uninstalled. So I was thinking I'd add a custom action type 51 to get the value into a property and a conditionalized component with a test on the value, but I'm not quite clear on how all the pieces would fit together... Something like Component Id=SetPath Condition![CDATA[NOT EnvPathC:\Program Files\Mypath;]]/Condition Environment Id=EnvSetPath Action=set Name=PATH Part=first Permanent=yes System=yes Value=C:\Program Files\MyPath / /Component ... CustomAction Id=EnvPath Property=EnvPath Value=[%PATH] / Problem is that all the examples I'm cribbing from are using ellipsis too, so I'm not sure if I have to declare what phase the custom action will be executed in, etc. Am I on the right track? Thanks Mark -- The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Include question.
Thanks Blair... Interestingly, Wix isn't complaining about Component as a child of include... As a test, I tweaked the little mini version of Tallow my predecessor left to take the Component wrapper off the top level files, so it was Include xmlns=http://schemas.microsoft.com/wix/2003/01/wi; File Id=ASPfile1 Name=DEFAUL_1.ASP LongName=default.aspx src=..\..\..\ASP\ChatServer\default.aspx / File Id=ASPfile2 Name=GLOBAL_1.ASA LongName=Global.asax src=..\..\..\ASP\ChatServer\Global.asax / File Id=ASPfile3 Name=WEB_1.CON LongName=Web.config src=..\..\..\ASP\ChatServer\Web.config / Directory Id=ASPdirectory0 Name=bin Component Id=ASPcomponent0 Guid=81ac5844-6243-40a2-862f-1626438040e5 File Id=ASPfile4 Name=Auth.dll src=..\..\..\ASP\ChatServer\bin\Auth.dll / ... /Component /Directory /Include Going into Directory Id=TARGETDIR Name=SourceDir ?include MyInclude.wxi ? /Directory And then Candle really did throw a nutter. As you predicted, Include was treated as a direct insertion, so File wasn't a legal child of Directory, and that was the exception Candle threw. So it seems that in Wix 2, it won't throw an error with Component as a child of Include but it won't include it either... I may just have to upgrade as you say... Probably long overdue... Thanks Mark -Original Message- From: Blair [mailto:os...@live.com] Sent: Wednesday, October 20, 2010 8:00 PM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Include question. I took a quick glance in the XSD for WiX 2.0 and Component isn't allowed as a child of Include. It is, however, allowed in WiX 3.0. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Wednesday, October 20, 2010 4:31 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Include question. I did find another example in our old wix code in a different merge module. It uses the same syntax as before for the include file(s) but there's a slight twist: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Module Id=ForumsAspModule Guid= ---- Language=1033 Version=1.0.0.0 Package Id= ---- Description=Files in /ASP Comments=Files in /ASP Manufacturer=Prospero Technologies InstallerVersion=200 Compressed=yes / Directory Id=TARGETDIR Name=SourceDir ?include ForumsAsp.wxi ? Directory Id=dcard Name=dcard ?include ForumsAspDcard.wxi ? /Directory /Directory /Module /Wix The first ?include? file has only subdirectories in it. The 2nd one, like my original problem has root files and subdirs - but wrapping it in an explicit subdirectory seems to avoid the problem. So it looks like it's only a problem to include Component Id=xxx Guid= File.../ /Component Directly under Directory Id=TARGETDIR Name=SourceDir I did make sure that the msi wix file did actually have a Merge and MergeRef for the modules being produced... Thanks Mark -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 1:21 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Include question. That suggestion doesn't make sense to me. ?include? doesn't incorporate the included file as a different fragment, it imports the file at the location of the processing instruction in building the DOM actually presented to the compiler proper, making it lay in the same fragment. Also, merge modules don't include features, so there's no Feature under which to place the ComponentRef. And, in when building MSIs instead of MSMs, if you miss the ComponentRef under some Feature, your component is still included in the MSI (assuming the fragment the component is in was otherwise included by the linker) but you get an error indicating that the component won't be installed because it isn't included in any components. It may possibly be a bug. If you migrate your solution to WiX 3.whatever, does it still happen? I don't know if 2.0 would be fixed or not for something like this since 3.0 has been RTM for quite some time now. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Monday, October 18, 2010 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Include question. Thanks for the reply... I'm not adding any ComponentRef, so that's probably it. Just out of curiosity, adding a Directory under a Directory is automatically included but file references (bundled under a Component) won't? Thanks Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Friday, October 15, 2010 7:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Include question. Are you adding
Re: [WiX-users] Include question.
I did find another example in our old wix code in a different merge module. It uses the same syntax as before for the include file(s) but there's a slight twist: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Module Id=ForumsAspModule Guid= ---- Language=1033 Version=1.0.0.0 Package Id= ---- Description=Files in /ASP Comments=Files in /ASP Manufacturer=Prospero Technologies InstallerVersion=200 Compressed=yes / Directory Id=TARGETDIR Name=SourceDir ?include ForumsAsp.wxi ? Directory Id=dcard Name=dcard ?include ForumsAspDcard.wxi ? /Directory /Directory /Module /Wix The first ?include? file has only subdirectories in it. The 2nd one, like my original problem has root files and subdirs - but wrapping it in an explicit subdirectory seems to avoid the problem. So it looks like it's only a problem to include Component Id=xxx Guid= File.../ /Component Directly under Directory Id=TARGETDIR Name=SourceDir I did make sure that the msi wix file did actually have a Merge and MergeRef for the modules being produced... Thanks Mark -Original Message- From: Blair [mailto:os...@live.com] Sent: Tuesday, October 19, 2010 1:21 AM To: 'General discussion for Windows Installer XML toolset.' Subject: Re: [WiX-users] Include question. That suggestion doesn't make sense to me. ?include? doesn't incorporate the included file as a different fragment, it imports the file at the location of the processing instruction in building the DOM actually presented to the compiler proper, making it lay in the same fragment. Also, merge modules don't include features, so there's no Feature under which to place the ComponentRef. And, in when building MSIs instead of MSMs, if you miss the ComponentRef under some Feature, your component is still included in the MSI (assuming the fragment the component is in was otherwise included by the linker) but you get an error indicating that the component won't be installed because it isn't included in any components. It may possibly be a bug. If you migrate your solution to WiX 3.whatever, does it still happen? I don't know if 2.0 would be fixed or not for something like this since 3.0 has been RTM for quite some time now. -Original Message- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Monday, October 18, 2010 6:45 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Include question. Thanks for the reply... I'm not adding any ComponentRef, so that's probably it. Just out of curiosity, adding a Directory under a Directory is automatically included but file references (bundled under a Component) won't? Thanks Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Friday, October 15, 2010 7:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Include question. Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it will not be included in the MSI. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-questi on-tp5631284p5638617.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Include question.
Thanks for the reply... I'm not adding any ComponentRef, so that's probably it. Just out of curiosity, adding a Directory under a Directory is automatically included but file references (bundled under a Component) won't? Thanks Mark -Original Message- From: jhennessey [mailto:jack.hennes...@hyland.com] Sent: Friday, October 15, 2010 7:52 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Include question. Are you adding a ComponentRef for ASPcomponent0 under a feature? If not it will not be included in the MSI. -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Include-question-tp5631284p5638617.html Sent from the wix-users mailing list archive at Nabble.com. -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Download new Adobe(R) Flash(R) Builder(TM) 4 The new Adobe(R) Flex(R) 4 and Flash(R) Builder(TM) 4 (formerly Flex(R) Builder(TM)) enable the development of rich applications that run across multiple browsers and platforms. Download your free trials today! http://p.sf.net/sfu/adobe-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Include question.
Just stumbled across an odd artifact left behind by my predecessor's use of Wix. He built a system that generates a wix include file by crawling various directories. He also built his own version of Tallow because he rather liked negative filters than positive ones I gather (i.e. his command line options were -xf and -xd for patterns to exclude). It looks like this: Include xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Component Id=ASPcomponent0 Guid=1351dd8e-8c30-42d0-8193-a0edfe366270 File Id=ASPfile1 Name=CROSSD_1.XML LongName=crossdomain.xml src=..\..\..\ASP\ChatServer\crossdomain.xml / File Id=ASPfile2 Name=DEFAUL_1.ASP LongName=default.aspx src=..\..\..\ASP\ChatServer\default.aspx / File Id=ASPfile3 Name=GLOBAL_1.ASA LongName=Global.asax src=..\..\..\ASP\ChatServer\Global.asax / File Id=ASPfile4 Name=WEB_1.CON LongName=Web.config src=..\..\..\ASP\ChatServer\Web.config / /Component Directory Id=ASPdirectory0 Name=bin Component Id=ASPcomponent1 Guid=834b33e2-a194-41ce-98ae-1e95d9616d49 ... File Id=ASPfile21 Name=Process.dll src=..\..\..\ASP\ChatServer\bin\Process.dll / File Id=ASPfile22 Name=Process.pdb src=..\..\..\ASP\ChatServer\bin\Process.pdb / ... /Component /Directory ... /Include It's included into the Wix project like this: ?xml version=1.0 encoding=UTF-8? Wix xmlns=http://schemas.microsoft.com/wix/2003/01/wi; Module Id=ChatAspModule Guid=A7D317BB-9169-481c-9881-09C36AA76F88 Language=1033 Version=1.0.0.0 Package Id=461A965B-AF1F-466d-927A-2AE3FEEE01C7 Description=Files in /ASP Comments=Files in /ASP Manufacturer=Prospero Technologies InstallerVersion=200 Compressed=yes / Directory Id=TARGETDIR Name=SourceDir ?include ChatAsp.wxi ? /Directory /Module /Wix The odd artifact mentioned above is that the files specified in the first naked Component don't get included in the install, and I'm wondering why? The included form would resolve to something like Directory Id=TARGETDIR Name=SourceDir Component Id=ASPcomponent0 Guid=1351dd8e-8c30-42d0-8193-a0edfe366270 File Id=ASPfile1 Name=CROSSD_1.XML LongName=crossdomain.xml src=..\..\..\ASP\ChatServer\crossdomain.xml / File Id=ASPfile2 Name=DEFAUL_1.ASP LongName=default.aspx src=..\..\..\ASP\ChatServer\default.aspx / File Id=ASPfile3 Name=GLOBAL_1.ASA LongName=Global.asax src=..\..\..\ASP\ChatServer\Global.asax / File Id=ASPfile4 Name=WEB_1.CON LongName=Web.config src=..\..\..\ASP\ChatServer\Web.config / /Component Directory .../Directory /Directory Why wouldn't Web.config, etc get installed as a result? There are no errors in the msi build... Thanks Mark -- Beautiful is writing same markup. Internet Explorer 9 supports standards for HTML5, CSS3, SVG 1.1, ECMAScript5, and DOM L2 L3. Spend less time writing and rewriting code and more time creating great experiences on the web. Be a part of the beta today. http://p.sf.net/sfu/beautyoftheweb ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] running ngen from an msi?
I know there's a chicken/egg issue with running anything to work on the files you're installing during the installation process, but I was wondering what people usually do around ngen? I mean you install a bunch of .net assemblies and I know the way to deal with GACing them is to essentially set your wix file to install directly in the gac rather than use gacutil. If you have a bunch of msil assemblies and you want them to go native on whatever machine you install them to, you have to use ngen on that machine. Do you schedule it to run after next reboot or something? Thanks Mark -- This SF.net email is sponsored by Make an app they can't live without Enter the BlackBerry Developer Challenge http://p.sf.net/sfu/RIM-dev2dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] Newbie x64 msi question
Hi...
I've got some old wix scripts installing msil .net assemblies
in the gac and adding registry entries for com interop. These things will work
x64 as is, so I tried the installer without making any particular changes to
the old scripts.
What I found, though, was that
...
Registry Id=Registry4 Root=HKCR
Key=CLSID\{6D7F6B50-88B9-11D4-A757-006008A7291E}\InprocServer32 Type=string
Value=mscoree.dll /
Registry Id=Registry5 Root=HKCR
Key=CLSID\{6D7F6B50-88B9-11D4-A757-006008A7291E}\InprocServer32
Name=ThreadingModel Type=string Value=Both /
...
All the class id registry settings ended up in the \Wow6432Node\ subtree while
all the class names ended up in the top HKCR root.
What do I need to set in the wix script to tell it to put the
entries in the 64-bit hive? I mean, theoretically I could make all the entries
in both since the msil code could run in either circumstance...
Thanks
Mark
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
WiX-users mailing list
WiX-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] ServiceInstall/ServiceDependency
Hi... I've been slapping together an installer for a window service, and I added ServiceDependency Id=MSMQ / ServiceDependency Id=MSSQLServer / To the .wxs file. When I ran the resulting msi on my dev box, the service was installed but not all the dependencies applied. Specifically, I have SqlExpress on my dev box, but not the full Sql Server. When I looked at the properties of the installed service, it had the MSMQ dependency, but the Sql Server one was simply dropped. So a) Is there any way to get it to put the dependency in even when the dependency isn't there? (i.e. it won't run until the other dependency is installed) or b) Is there any way to make the msi conditional (i.e. either Sql Server *or* SqlExpress are there)? Thanks Mark -- This SF.net email is sponsored by Sprint What will you do first with EVO, the first 4G phone? Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for MSVCR71.dll
We recently ran into something very similar... We build our .net assemblies MSIL, but a 3rd party assembly (dtSearch) was built platform-specific because it had a dependency on an unmanaged dll. We didn't find any MSVCR71 for x64, but the vendor did supply an x64 build of their code (both .net and unmanaged). Their unmanaged dll didn't depend on msvcr71 (though I forget which rev the x64 build was on). Same thing with the Oracle drivers (and the .Net wrapper). Thanks Mark -Original Message- From: Wilson, Phil [mailto:phil.wil...@invensys.com] Sent: Tuesday, April 27, 2010 3:44 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for MSVCR71.dll Forget the build, the issue is the binary that needs msvcr71.dll. As far as I know, there is no native x64 version of the Microsoft VS 2003 C++ runtime support library msvcr71.dll. If someone has built a native x64 binary that requires a native x64 msvcr71.dll then I have no idea what you can do. Because this seems to be a situation that a reasonable person would not get into, I'm suggesting that you verify that it really is a native x64 binary, because people can get very loose in their descriptions, and it's still extremely common to run x86 code on 64-bit systems. Phil Wilson -Original Message- From: jeff00seattle [mailto:jeff_tan...@earthlink.net] Sent: Tuesday, April 27, 2010 11:53 AM To: wix-users@lists.sourceforge.net Subject: Re: [WiX-users] Windows 7 x64: Windows application x64 is looking for MSVCR71.dll Thanks for the reply, I do not have control of the build; in other words, I am provided with an x64 build and I do not have the sources. This x64 binary is from the open source community. Thereby I must merge msvcr71.dll with install upon a Windows 7 x64, or a getting missing error dialog at runtime. - Thanks Jeff in Seattle -- View this message in context: http://windows-installer-xml-wix-toolset.687559.n2.nabble.com/Windows-7-x64-Windows-application-x64-is-looking-for-MSVCR71-dll-tp4970053p4970279.html Sent from the wix-users mailing list archive at Nabble.com. -- ___ 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 Portland House, Bressenden Place, London, SW1E 5BF (Registered number 166023). For a list of European legal entities within the Invensys Group, please go to http://www.invensys.com/legal/default.asp?top_nav_id=77nav_id=80prev_id=77. You may contact Invensys plc on +44 (0)20 7821 3848 or e-mail inet.hqhelpd...@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). -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] A couple of Wix 2.0 questions
I noticed that it's legal to have InstallFiles/ and InstallFinalize/ as a child of any of the sequences... Can you put InstallFiles and InstallFinalize in one sequence (say the AdminExecuteSequence) and run InstallUtil from another? And which order do the Sequences get run in? Thanks Mark -Original Message- From: Rob Mensching [mailto:r...@robmensching.com] Sent: Tuesday, April 20, 2010 1:08 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] A couple of Wix 2.0 questions 0. Nothing wrong with WiX v2.0. Now InstallUtil, that's a big problem. smile/ 1. Assemblies are not committed to the GAC until InstallFinalize. Thus, you cannot depend on them during your install. 2. Nothing built into the Preprocessor about MSBuild or VS. You need to push the values down from VS or MSBuild into candle.exe. My MSBuild-fu isn't that strong so others may be of more use yere. On Tue, Apr 20, 2010 at 9:56 AM, Mark Modrall mmodr...@mzinga.com wrote: I know I know... I shouldn't even be using it... But I inherited this old hairball when I got here and no one has wanted to spend the time to upgrade. I tried to make a quick new installer using our already-written merge modules but I ran into a couple of odd quirks... 1) One merge module installs a few .net assemblies in the GAC. The last, custom step of the new installer is to run InstallUtil.exe on an assembly *using* one of the gac components. But InstallUtil fails because trying to run up the assembly - bind failures, saying the gac components aren't there. I've tried a number of things (declaring InstallFiles explicitly, trying to explicitly set the sequence numbers, moving all the actions to AdminExecuteSequence) and nothing has worked. Oddly, moving everything to AdminExecuteSequence ran to completion just fine - it just didn't execute the custom actions. Anyone out there contended with this? Trying to put some pieces in the gac with the installer yet still have them available to run InstallUtil.exe on something consuming them? 2) In my wxs, I tried to default the platform to the setting from the VS Configuration Manager, but none of the methods I found with Google appeared to work. None of the supposed pre-defined variables existed, and I couldn't put a DefineConstants group in a 2.0 wix project. Are there any preprocessor variables in 2.0 that will tell you what configuration you're running in? Thanks mark -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Download Intel#174; Parallel Studio Eval Try the new software tools for yourself. Speed compiling, find bugs proactively, and fine-tune applications for parallel performance. See why Intel Parallel Studio got high marks during beta. http://p.sf.net/sfu/intel-sw-dev ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] Problems with XmlConfig
But msxml can be told to preserve whitespace when parsing... In all likelihood Wix isn't doing that, but it is conceivably possible... Mark -Original Message- From: Michael Owings [mailto:[EMAIL PROTECTED] Sent: Tuesday, October 14, 2008 4:41 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Problems with XmlConfig If you're trying to format the xml itself, you may be out of luck -- msxml (which I believe wix is using) will do the formatting however it feels like doing it. This is true of most programmatic xml access. If the text in question is in a CDATA section, however, I'd think that should work, assuming #xA is really the right escape. Pierson Lee (PIE) wrote: I was attempting to insert #xA; into my web configs to specify a carriage return for some lines of text I'm adding into the config, but it seems like during the process, those characters are getting stripped. Anyone have any idea how to do this? Thanks :) -- --- This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Teleoperate a roving mobile robot from the web: http://www.swampgas.com/robotics/rover.html - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] testing for environment variable definition in Wix
Hi... I recently ran into a number of problems trying to change wix project behavior based on environment variable settings. A number of the things that sounded intuitive to me didn't work. For example ?ifdef $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? ?endif? didn't work because ifdef returns false for all environment variables always whether they are set or not. ?if $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? works as long as $(env.A) is defined, but if it's not, Candle generates an exception. Is there any way to test for environment variable existence before you try to use it in Wix? Thanks Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] preprocessor and environment variables?
Sorry, I should have included that in the first place... V2.0.5325.0... Thanks Mark -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 6:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] preprocessor and environment variables? What version of the WiX toolset are you using? -Original Message- From: Mark Modrall [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 14:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] preprocessor and environment variables? Hi... I recently ran into a number of problems trying to change wix project behavior based on environment variable settings. A number of the things that sounded intuitive to me didn't work. For example ?ifdef $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? ?endif? didn't work because ifdef returns false for all environment variables always whether they are set or not. ?if $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? works as long as $(env.A) is defined, but if it's not, Candle generates an exception. Is there any way to test for environment variable existence before you try to use it in Wix? Thanks Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] preprocessor and environment variables?
Sorry... Should have included that to begin with - v2.0.5325.0 Thanks Mark -Original Message- From: Rob Mensching [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 6:13 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] preprocessor and environment variables? What version of the WiX toolset are you using? -Original Message- From: Mark Modrall [mailto:[EMAIL PROTECTED] Sent: Tuesday, September 30, 2008 14:38 To: wix-users@lists.sourceforge.net Subject: [WiX-users] preprocessor and environment variables? Hi... I recently ran into a number of problems trying to change wix project behavior based on environment variable settings. A number of the things that sounded intuitive to me didn't work. For example ?ifdef $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? ?endif? didn't work because ifdef returns false for all environment variables always whether they are set or not. ?if $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? works as long as $(env.A) is defined, but if it's not, Candle generates an exception. Is there any way to test for environment variable existence before you try to use it in Wix? Thanks Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] preprocessor and environment variables?
Hi... I recently ran into a number of problems trying to change wix project behavior based on environment variable settings. A number of the things that sounded intuitive to me didn't work. For example ?ifdef $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? ?endif? didn't work because ifdef returns false for all environment variables always whether they are set or not. ?if $(env.A) ? ?define myVar=foo ? ?else? ?define myVar=bar ? works as long as $(env.A) is defined, but if it's not, Candle generates an exception. Is there any way to test for environment variable existence before you try to use it in Wix? Thanks Mark - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
