Re: [WiX-users] non-vital files in an installation
Excellent, thanks for your help all. Got it done :) cheers, Andrew On 23 May 2012 23:36, Hoover, Jacob jacob.hoo...@greenheck.com wrote: Yes, the file would have to exist at compile time if you are going to use a File element. On the media tag for the file, ensure it isn't in an embedded CAB. I believe a Media Tag with no Cabinet attribute would result in the file being expected to be located alongside the source. Since this is an image file, the only thing I can think of that you may have to do at runtime is update the file hash in a custom action. An alternate (and probably easier) option would be to eliminate the File element and then in the CopyFile refer to the file by name. This would mean you would have to add another element in the component to be the key path, such as a registry value. Component Id=CustomLogo Guid=A5FF53DE-4321-42c4-BE39-60F810C9CD69 Condition ![CDATA[LOGOEXISTS]] /Condition RegistryKey Root=HKLM Key=Software\Mfg\AppName Action=createAndRemoveOnUninstall RegistryValue Name=CustomLogo Value=1 Type=integer KeyPath=yes/ /RegistryKey CopyFile Id=customLogoFileCopy SourceDirectory=[SourceDir] SourceName=custom-logo.png DestinationDirectory=APPLICATIONROOTDIRECTORY/ RemoveFile Id=customLogoFileRemove Name=custom-logo.png On=uninstall / /Component -Original Message- From: Andrew Maxwell [mailto:andrew.maxw...@papercut.com] Sent: Tuesday, May 22, 2012 9:28 PM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] non-vital files in an installation thanks Jacob, that's got me thinking. So, right now I have: !-- check if the custom logo exists or not -- Property Id=LOGOEXISTS DirectorySearch Id=CheckFileDir Path=[SourceDir] Depth=0 FileSearch Id=CheckFile Name=custom-logo.png/ /DirectorySearch /Property !-- declare components -- DirectoryRef Id=APPLICATIONROOTDIRECTORY Component Id=CustomLogo Guid=A5FF53DE-4321-42c4-BE39-60F810C9CD69 Condition ![CDATA[LOGOEXISTS]] /Condition File Id= customLogoFile Name=custom-logo.png Source=custom-logo.png Vital=no / CopyFile Id=customLogoFileCopy SourceName=customLogoFile DestinationDirectory=APPLICATIONROOTDIRECTORY / /Component !-- and then include this component in features as normal -- Feature Id=blah Title=blahblah# Level=1 ComponentGroupRef Id=main application/ ComponentRef Id=ApplicationShortcut / ComponentRef Id=CustomLogo / /Feature This gives the error: custom logo not found, and won't compile. Is it required that the file exists at compile time? If so this gets very tricky to automate... :\ (duplicate entries with heat-harvested custom-logo.png and manual condition reference above. cheers, Andrew On 22 May 2012 23:49, Hoover, Jacob jacob.hoo...@greenheck.com wrote: One option would be to create a custom action that would create temporary records on install if the file exists on the installation media. This would allow you to avoid the prompt, but it would mean you would need to handle all the scenarios (install, upgrade, remove, repair, etc) with temporary records. This would lend itself well if you don't know the content that might be included up front but is the more complex option. Since it seems you do know the files at build time, you could create a component with a condition that would evaluate a custom property to determine if it needs to be installed. Then in your installer you would have a custom action which would enable the component (via a property) if the file exist in the installation media. -Original Message- From: Andrew Maxwell [mailto:andrew.maxw...@papercut.com] Sent: Tuesday, May 22, 2012 2:20 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] non-vital files in an installation Hrm, alright - suppressing the GUI prompt itself is out of the question, then. Can anyone give any advice on what the best way to do this would be? - optional file might be placed in the distribution directory (eg. a logo file), with a specific name and location - at MSI runtime if the file exists, the MSI will copy it to the destination - if not, continues on without bothering the user My approach at the moment is to simply create a dummy file in my source directory when harvesting with heat, and setting its Vital flag to false. This works fine, apart from the GUI popup. cheers, Andrew On 22 May 2012 14:58, Rob Mensching r...@robmensching.com wrote: Never seen anything in the MSI SDK that suggests you can suppress that UI if you show the internal UI. You could develop your own
Re: [WiX-users] non-vital files in an installation
Hrm, alright - suppressing the GUI prompt itself is out of the question, then. Can anyone give any advice on what the best way to do this would be? - optional file might be placed in the distribution directory (eg. a logo file), with a specific name and location - at MSI runtime if the file exists, the MSI will copy it to the destination - if not, continues on without bothering the user My approach at the moment is to simply create a dummy file in my source directory when harvesting with heat, and setting its Vital flag to false. This works fine, apart from the GUI popup. cheers, Andrew On 22 May 2012 14:58, Rob Mensching r...@robmensching.com wrote: Never seen anything in the MSI SDK that suggests you can suppress that UI if you show the internal UI. You could develop your own external UI (but that's a lot of work). Burn could maybe make it a bit easier to develop the external UI. On Mon, May 21, 2012 at 7:42 PM, Andrew Maxwell andrew.maxw...@papercut.com wrote: Hi all, I've got a scenario where in some cases a file may be included in our distribution, but if it's not - no big deal, the installation should continue on anyway. At the moment I've got the file flagged as Vital=no , and this achieves my goal - except for a popup asking to retry/cancel/ignore. Is there a way to suppress this dialogue and automatically select 'Ignore' ? Or is there a better way of achieving this? thanks for any input! Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] non-vital files in an installation
thanks Jacob, that's got me thinking. So, right now I have: !-- check if the custom logo exists or not -- Property Id=LOGOEXISTS DirectorySearch Id=CheckFileDir Path=[SourceDir] Depth=0 FileSearch Id=CheckFile Name=custom-logo.png/ /DirectorySearch /Property !-- declare components -- DirectoryRef Id=APPLICATIONROOTDIRECTORY Component Id=CustomLogo Guid=A5FF53DE-4321-42c4-BE39-60F810C9CD69 Condition ![CDATA[LOGOEXISTS]] /Condition File Id= customLogoFile Name=custom-logo.png Source=custom-logo.png Vital=no / CopyFile Id=customLogoFileCopy SourceName=customLogoFile DestinationDirectory=APPLICATIONROOTDIRECTORY / /Component !-- and then include this component in features as normal -- Feature Id=blah Title=blahblah# Level=1 ComponentGroupRef Id=main application/ ComponentRef Id=ApplicationShortcut / ComponentRef Id=CustomLogo / /Feature This gives the error: custom logo not found, and won't compile. Is it required that the file exists at compile time? If so this gets very tricky to automate... :\ (duplicate entries with heat-harvested custom-logo.png and manual condition reference above. cheers, Andrew On 22 May 2012 23:49, Hoover, Jacob jacob.hoo...@greenheck.com wrote: One option would be to create a custom action that would create temporary records on install if the file exists on the installation media. This would allow you to avoid the prompt, but it would mean you would need to handle all the scenarios (install, upgrade, remove, repair, etc) with temporary records. This would lend itself well if you don't know the content that might be included up front but is the more complex option. Since it seems you do know the files at build time, you could create a component with a condition that would evaluate a custom property to determine if it needs to be installed. Then in your installer you would have a custom action which would enable the component (via a property) if the file exist in the installation media. -Original Message- From: Andrew Maxwell [mailto:andrew.maxw...@papercut.com] Sent: Tuesday, May 22, 2012 2:20 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] non-vital files in an installation Hrm, alright - suppressing the GUI prompt itself is out of the question, then. Can anyone give any advice on what the best way to do this would be? - optional file might be placed in the distribution directory (eg. a logo file), with a specific name and location - at MSI runtime if the file exists, the MSI will copy it to the destination - if not, continues on without bothering the user My approach at the moment is to simply create a dummy file in my source directory when harvesting with heat, and setting its Vital flag to false. This works fine, apart from the GUI popup. cheers, Andrew On 22 May 2012 14:58, Rob Mensching r...@robmensching.com wrote: Never seen anything in the MSI SDK that suggests you can suppress that UI if you show the internal UI. You could develop your own external UI (but that's a lot of work). Burn could maybe make it a bit easier to develop the external UI. On Mon, May 21, 2012 at 7:42 PM, Andrew Maxwell andrew.maxw...@papercut.com wrote: Hi all, I've got a scenario where in some cases a file may be included in our distribution, but if it's not - no big deal, the installation should continue on anyway. At the moment I've got the file flagged as Vital=no , and this achieves my goal - except for a popup asking to retry/cancel/ignore. Is there a way to suppress this dialogue and automatically select 'Ignore' ? Or is there a better way of achieving this? thanks for any input! Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- virtually, Rob Mensching - http://RobMensching.com LLC -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114
[WiX-users] non-vital files in an installation
Hi all, I've got a scenario where in some cases a file may be included in our distribution, but if it's not - no big deal, the installation should continue on anyway. At the moment I've got the file flagged as Vital=no , and this achieves my goal - except for a popup asking to retry/cancel/ignore. Is there a way to suppress this dialogue and automatically select 'Ignore' ? Or is there a better way of achieving this? thanks for any input! Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
Re: [WiX-users] building an msi in the same dir as source files?
thanks! this, and the realisation I had an unspecified SourceName have done the trick. cheers, Andrew On 18 May 2012 17:16, Neil Sleightholm n...@x2systems.com wrote: I think what you need to add is -var var.SourceFiles; from the help file: -var VariableName Substitute File/@Source=SourceDir with a preprocessor or a wix variable (e.g. -var var.MySource will become File/@Source=$(var.MySource)\myfile.txt and -var wix.MySource will become File/@Source=!(wix.MySource)\myfile.txt. This will result in the File elements having the source folder set to a pre-processor variable, e.g.: File Id=fil8E5129A8454C2AA40A71DF50F7CD8484 KeyPath=yes Source=$(var.SourceFiles)\File1.exe / You can then set this a compile time. Neil -Original Message- From: Andrew Maxwell [mailto:andrew.maxw...@papercut.com] Sent: 18 May 2012 06:01 To: wix-users@lists.sourceforge.net Subject: [WiX-users] building an msi in the same dir as source files? Hi again all, My last post was a bit of a brain-dump, so I can boil my question down to a few points here: :) - using heat, is there a way to harvest a directory and suppress directory id/name insertion in the resulting .wxs? (when automating heat output , this is an annoyance) eg . heat.exe dir MyDirectory -gg -cg MyComponents -o output.wxs would generate something like: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment DirectoryRef Id=TARGETDIR *Directory Id=dir682EE88536E915B58CEC9559EC161A89 Name=MyDirectory* Component Id=cmp789AABFBE814C745D68B0EC1FE51DF26 . etc - I'm trying to build an installer where the .msi *sits in the same directory as the uncompressed source files*. However, if my dir structure looks like: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONROOTDIRECTORY Name=MyApplication/ /Directory /Directory DirectoryRef Id=APPLICATIONROOTDIRECTORY ...components... /DirectoryRef This will happily install MyAppliation to Program Files/MyApplication however will require my msi to reside one level down, and expect the source files to be in a dir called MyApplication. Can anyone set me in the right direction? My process is something like this atm: heat dir AppSource -gg -sfrag -sreg -svb6 -scom -cg MainAppComps -o installer.wxs [modify heat .wxs] candle -out installer.wxsobj installer.wxs light -b AppSource -sl -spdb AppSource/installer.wxsobj -out AppSource/installer.msi Will create a .msi in the AppSource directory (good!), but when installed expects the files to reside in AppSource/MyApplication/ ! Sorry again for the double post. Any thoughts anyone? ps. if anyone's interested the reason for this seemingly bizarre project layout is the .msi exists purely to simplify deployment via a group policy. cheers, Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] building an msi in the same dir as source files?
Hi again all, My last post was a bit of a brain-dump, so I can boil my question down to a few points here: :) - using heat, is there a way to harvest a directory and suppress directory id/name insertion in the resulting .wxs? (when automating heat output , this is an annoyance) eg . heat.exe dir MyDirectory -gg -cg MyComponents -o output.wxs would generate something like: ?xml version=1.0 encoding=utf-8? Wix xmlns=http://schemas.microsoft.com/wix/2006/wi; Fragment DirectoryRef Id=TARGETDIR *Directory Id=dir682EE88536E915B58CEC9559EC161A89 Name=MyDirectory* Component Id=cmp789AABFBE814C745D68B0EC1FE51DF26 . etc - I'm trying to build an installer where the .msi *sits in the same directory as the uncompressed source files*. However, if my dir structure looks like: Directory Id=TARGETDIR Name=SourceDir Directory Id=ProgramFilesFolder Directory Id=APPLICATIONROOTDIRECTORY Name=MyApplication/ /Directory /Directory DirectoryRef Id=APPLICATIONROOTDIRECTORY ...components... /DirectoryRef This will happily install MyAppliation to Program Files/MyApplication however will require my msi to reside one level down, and expect the source files to be in a dir called MyApplication. Can anyone set me in the right direction? My process is something like this atm: heat dir AppSource -gg -sfrag -sreg -svb6 -scom -cg MainAppComps -o installer.wxs [modify heat .wxs] candle -out installer.wxsobj installer.wxs light -b AppSource -sl -spdb AppSource/installer.wxsobj -out AppSource/installer.msi Will create a .msi in the AppSource directory (good!), but when installed expects the files to reside in AppSource/MyApplication/ ! Sorry again for the double post. Any thoughts anyone? ps. if anyone's interested the reason for this seemingly bizarre project layout is the .msi exists purely to simplify deployment via a group policy. cheers, Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
[WiX-users] some questions about Heat automation
Hi fellow Wixians, I've been tasked with automating MSI creation , tying it into our build processes, and running into some grief with heat. So, I've got two questions for the list: a) There doesn't seem to be a way to fully automate the process from directory harvest all the way through to msi compilation, using the Wix toolchain exclusively - so far my approach is to create a template .wxs file describing our application installation, fill it with keywords, and then populate the template , including one colossal dump of the directory structure from heat. Essentially munging a .wxs file together, adding a header, start-menu definition etc programatically - then Candle, then Light. Am I going about this the stupid way? Any hints on streamlining the workflow? and b) We require the final .msi to reside in the application's base directory, simply referencing its surrounding files, but not archiving them (this is just for easy distribution). If I harvest the directory's contents like so: [application_dir]:\ heat.exe dir . -cg MainApp -sfrag -sreg -scom -svb6 -gg -o appHarvest.wxs I can see in the resulting .wxs it creates a DirectoryRef Id=TARGETDIR Directory Id=[some dir id Name=[application_dir] When it comes time to compile and run, this will create something like: application_dir\application_dir\installer.msi ...with both application_dirs containing copies of all files. Obviously this isn't right! When using heat's dir argument, it seems to always define a subdirectory within the fragment. Is there a way to disable this? thanks for any input and advice! - Andrew -- Live Security Virtual Conference Exclusive live event will cover all the ways today's security and threat landscape has changed and how IT managers can respond. Discussions will include endpoint security, mobile security and the latest in malware threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ ___ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
