In my final WiX Wednesday, I’m going to talk about how we can set the size of our custom event log file on install.
In my previous I post I showed how to make a custom event log file on install. Typically a file will be created at 1mb, large enough for most files. However there’s several resaon why you may want this to be bigger:
- if your devs are logging a considerable amount to the event viewer
- or there’s a lot of errors being generated
- or for your test environment you want to keep more history
When installing the program with the custom event file, you can define the size of the file using a mixture of Powershell and custom actions. A caveat here is that through Group Policy, the sys admins can define the size of the evtx files in the event viewer. So even if you set yours to be 40mb, even though they are installed with that size, if the group policy is to set the size to 5 mb, when Group Policy is next applied to the box your program was installed on the evtx file will have it size decreased to 5mb.
In the Product file, add a ComponentGroupRef with the Id “LimitEventLogs.
<Feature Id="ProductFeature" Title="ServiceHost" Level="1"> <ComponentGroupRef Id="LimitEventLogs"/> </Feature>
I put this fragment of WiX in it’s own file in the Votive project (the Visual Studio project). It doesn’t make much difference other than making it tidier.
<?xml version="1.0" encoding="UTF-8"?> <Wix xmlns="http://schemas.microsoft.com/wix/2006/wi"> <Fragment> <DirectoryRef Id="INSTALLLOCATION"> <Component Id="Limit_Event_Log_Size" Guid="*"> <File Id="LimitEventLogsPS1" Source="LimitEventLog.ps1"/> </Component> </DirectoryRef> <Property Id="POWERSHELLEXE"> <RegistrySearch Id="POWERSHELLEXE" Type="raw" Root="HKLM" Key="SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell" Name="Path" /> </Property> <Condition Message="This application requires Windows PowerShell."> <![CDATA[Installed OR POWERSHELLEXE]]> </Condition> <SetProperty Id="LimitEventLogsPS1" Before="LimitEventLogsPS1" Sequence="execute" Value =""[POWERSHELLEXE]" -Version 2.0 -NoProfile -NonInteractive -InputFormat None -ExecutionPolicy Bypass -Command "& '[#LimitEventLogsPS1]' ; exit $$($Error.Count)"" /> <CustomAction Id="LimitEventLogsPS1" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="yes" /> <InstallExecuteSequence> <Custom Action="LimitEventLogsPS1" After="StartServices"> <![CDATA[NOT Installed]]> </Custom> </InstallExecuteSequence> <ComponentGroup Id="LimitEventLogs"> <ComponentRef Id="Limit_Event_Log_Size"/> </ComponentGroup> </Fragment> </Wix>
First, we need to locate powershell.exe on the target system. There’s a condition to fail the installation if PowerShell is not installed.
We’re then back to using a CAQuietExec to run Powershell in silent mode, which will then execute our PowerShell script. You need a reference to WiXUtilExtension to run CAQuietExec. We’ll schedule the custom action after StartServices so that we know the EventLogs action would have been ran.
I added the Powershell script to the installer. You can if you want deploy the .ps1 and then have it run after the files have been installed, but I don’t see much value in this being dropped to the bin directory. Perhaps other ps1 scripts might be useful, or perhaps if you pla nto run multiple .ps1 files and don’t want your installer project to become bloated.
Limit-EventLog -LogName "SvcLogs" -MaximumSize 40MB
Note that the -LogName has to match the name that appears in the event viewer. I’d recommend against going any larger than 40 mb, as although that seems fairly small, it can crash the event viewer when trying to read back old data if it is too big.
So once again with WiX and deploying, we’ve seen that it is possible to get a task automated as part of the install process within WiX, but not actually using WiX. Leveraging PowerShell through a custom action is actually not a bad idea, as previous posts have shown how to run more than one custom action in an installer. And PowerShell is very good at writing single line commands that do exactly what we need to do. You could even expand upon this and pass in parameters if you needed to.
Over this series, I wanted to show that it is possible to set up MSI’s to be more than just copying over dlls into a binary. Sure, WiX can be painful to manipulate, but it’s extensibility in utilising cmdline and Powershell show that you can create an MSI and pass it to someone with a msiexec cmdline and say”run this” and be confident that no further setup is required.
- Download WiX from CodePlex here.
- As I said, I don’t think the manual for WiX is all that great. It feels like it’s been written by an expert in WiX for an expert in WiX. But I guess at least there is a manual.
- There’s also a very comprehensive tutorial written about WiX that explains it in far greater detail than I have here. It also provides plenty of examples. Such as in the advanced sections there is a tutorial on creating your own custom UI.
- I’ve probably short-changed msiexec. Aside from running msiexec /? in the cmdline, there’s plenty of examples on the TechNet site.
- There’s even a book available! I’ve not read it, however the reviews on amazon.com seem positive. For such an esoteric piece of software, and at a reasonable price it’s worth a go? Maybe I’ll buy it and review it at the end of this series….