Just had a HDD failure on my server which took out my website. It seems like there was also an issue with the RAID setup as the restore returned the drive to an old image. Good thing I had a recent backup from which the site could be restored.
The site is backup with just a few comments missing. I was fortunately able to grab them from Google cache and manually enter them back into the database.
The previous post looked at a proof of concept for building a simple bootstrapper solution to elevate the execution of an MSI package. This post will outline how this proof of concept was converted into a VSIX project template.
Using a project template was going to be the best way to achieve portability and reusability of this bootstrapper concept. The initial attempts at producing a project template were to use the inbuilt File –> Export template function in Visual Studio on the proof of concept project. This was very cumbersome and difficult to debug. I came across a post by Aaron Marten that explains how to use the Visual Studio SDK tools to make this a smooth development process. Now that we can actually produce a VSIX package, the main issue from the previous post needs to be addressed.
The previous post discussed the pain points of putting validation into the UI sequence of an MSI package that require elevation. The outcome of some research was that a bootstrapper was the best way to get around this.
To recap, my design requirements for a bootstrapper solution were:
- Seamless Visual Studio integration and compilation
- Bootstrapper must be completely self-contained
- Bootstrapper must be quiet (no UI) and simply execute the MSI package
- Automatically elevate the packaged MSI
- Support change/repair/remove actions on the package
- Flexible design to add/remove bootstrapper functionality
Last month I was creating a WiX setup package to deploy a new system. In the past we have typically required the user to execute the MSI from the command line and provided all the MSI arguments required by the package. We have also played with transform packages to achieve the same result.
I am not a fan of either of these methods and want to push configuration options into the installer UI as a way of minimising user error while maintaining flexibility. I came across the excellent MsiExt project on CodePlex which provided a wide variety of customisations for WiX including custom actions and dialogs. One of the issues I hit was that several of the validation options in the custom dialogs required elevated privileges. Validating service credentials against the domain and verifying account rights is an example of this.
I’ve been creating a VSIX project template for Visual Studio over the last week or two. The project contains an IWizard class implementation to allow the user to define some information for the template.
I have noticed one weird quirk when it comes to cancelling the wizard. The project template is written to disk before the IWizard.RunStarted method is invoked. This raises some questions about how to cancel the wizard process and make the solution (and disk) look like nothing ever happened.
Gated check in with TFS 2010 is a brilliant feature. Unfortunately the “Preserve my pending changes locally” checkbox is sometimes disabled and it isn’t clear from the UI why this is the case.
There is an MSDN forum thread (here) that provides some reasons why this happens. The checkbox will be disabled if there are locks on some of the files in the changeset, the changeset contains binary files or exclusive check-out option is used on the team project.
The one that has been hitting me a lot recently is a docx deployment guide that is disabling this checkbox.
Over the last week I have posted a series of entries about how to execute custom tasks as part of a build process without TFS. The result of this process is the Neovolve.BuildTaskExecutor 1.0 application which is now available on Codeplex.
The following posts document how BuildTaskExecutor has come about:
- Executing build tasks without a build server – Design
- Executing build tasks without a build server – Implementation
- Executing build tasks without a build server – In action
- Executing build tasks without a build server – Example scenario
- Executing build tasks without a build server – Creating a custom ITask
You can download Neovolve.BuildTaskExecutor from here.
Following on from the previous posts in this series, this post will look at how to create a custom task that can then be executed via BTE.
This post will provide an example of how to create a task that will allow execution of multiple tasks from a single command line execution. The task itself is fairly meaningless as you can simply invoke BTE several times to get the same result. It does however provide a good example of how to use some of the services provided by BTE.
The first thing to do is create a new library project in Visual Studio. You will then need to add BuildTaskExecutor.exe as a reference. You will also need to add a reference to System.ComponentModel.Composition.dll to get access to MEF.
My last few posts have described the process of building an application that can manage custom build tasks without the availability of a full TFS environment (here, here and here). This post will look at how I use this application and all its tasks to manage the product version of a Visual Studio solution. The product I originally wrote BuildTaskExecutor (BTE) for is the .Net port of my old VB6 Switch program which is now hosted out on Codeplex (here).
The build tasks I want to execute when this solution compiles are:
- Increment the build number of the product version
- Check out from TFS as required
- Sync updated product version into wix project
- Check out from TFS as required
- Rename wix output to include the product version