WiX Wednesday 1.5 Increase/Decrease the size of Event Log on Install
Introduction
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.
Introduction
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.
Intro
Oh man, have I been dreading this blog post. I wrote about 3-4 of these Custom Event Log Components last year, and basically I’m having to re-learn it in order to try to describe it, so apologies if the detail is a little light…
Intro
There are many ways to run a find and replace in a config file to environmentalize it: you can update files in the build before they are compiled into the MSI, and even here there are multiple choices: SlowCheetah being one of them. This only works if you know at runtime the servers you are deploying to, or you only want a direct 1 to 1 connection. So on those occasions that you want to deploy to more than one box, updating at runtime does not work. Fortunately there is a way to update using WiX, and is surprisingly straightforward.
Update: edited final example thanks to comments (changed first “after” to “before”)
Sometimes it is necessary to run a command line action from WiX in order to complete the configuration of the deployment. And though there is an extension for IIS called the WebAppPool Element, the features available do not completely cover all the functionality that you may want to configure in the installer. For example, you can set how often you want the app recycled in minutes, but you can’t define when you want it done (say at 5am). Defining the app to recycle every 1440 minutes isn’t the same, as you’re constricted to installing at the time you want the 24 hour refresh to occur.
Feature tags are used when we want the WiX project to actually do something. It’s usually a step after we have defined the file location of whatever it is we want to drop. Let’s say we have declared the folder location “bin” already. Typically we’d want to declare dropping any dlls at the end of the product.wxs file, after we have created the drop location. The reason I like to do it this way is that it creates a logical organisation to the WiX file.
Hello, I thought I’d make the coming month of May all about WiX. And I don’t mean the free website builder. In the past I’ve gone looking for WiX tutorials and began reading some stuff before realizing that they are referring to Wix and not WiX, so I thought it best that I get that out of the way rather than waste peoples time. Over the Wednesday’s of May, I’m going to post a short example of WiX, including:
In a lot of my examples I am going to assume that you are using an IDE like Visual Studio. As of version 3, WiX would automatically install the WiX project template for use in Visual Studio. This enables us to leverage the capabilities of WiX with our solutions as well as use features such as Intellisense when creating WiX projects. The Visual Studio package is known as Voltive, an is available to Visual Studio 2005 and later. WiX appears to be perfectly capable when being scaled up to deploy enterprise-level solutions. If you are deploying many dlls with WiX you may want to to unload the project whilst running a large number of local F5 builds as it will re-compile the dlls all over again, meaning that you waste time compiling, then compiling again!