It seems that I keep having to come up with a regular expression that validates and parses a version string. I often use this for customising TFS build workflows for extracting and using application version information.

The AssemblyVersionAttribute appears to have the following rules:

• Major version is required
• Minor version is optional and will default to 0 if not specified
• Minor version cannot be *
• Build and Revision versions are optional and may be *
• Revision number cannot be specified if the build number is *

The following is the regular expression that covers all these rules.

How do you download the X509Certificate that secures a HTTPS channel? I want to do this for two reasons.

1. Identify the reason for a trust failure
2. Identify if the certificate is about to expire

I ran all sorts of searches on the net about how to get the certificate of the remote host. Unfortunately the results were not quite what I was after.

The answer is that the certificate is provided by HttpWebRequest.ServicePoint.Certificate. The tricky bit is that the certificate is only available once a response has come back from the host. This makes sense, but it is misleading that the certificate based on the response is stored against the original request object. It is also a little confusing that the certificate is available on the request when the attempt to get the response threw an exception (a failed certificate trust for example).

I have a pet peeve with how Action and TryAction style members are often implemented. Too often I see the following style of implementation.

It has taken a while, but I have been able to push out a new release of my Neovolve.Toolkit. The major focus of this release has been in the custom activity support for WF4. This version is now distributed via an MSI.

This release of the Neovolve.Toolkit package targets .Net 4 and contains support for WF4 as well as fixes to the existing code base. It supports the Client Profile version of the .Net 4 framework on many of the assemblies for a smaller footprint. The package now supports a VSIX package for Visual Studio integration of the toolbox for WF4 activities and the Add Reference dialog (see here for the details).
The following pages describe what each assembly in the package contains.

• Neovolve.Toolkit.dll
• Neovolve.Toolkit.Server.dll
• Neovolve.Toolkit.Unity.dll
• Neovolve.Toolkit.Workflow.dll
• Neovolve.Toolkit.Workflow.Design.dll

The package is available via Codeplex and the Visual Studio Gallery.

I recently battled the scary ExecutionEngineException. It’s scary because the exception itself does not provide any information about what has gone wrong and why. Figuring out why the exception is being thrown can get a little tricky.

In my scenario, Visual Studio was crashing when trying to display a WF designer. After attaching another Visual Studio instance to debug the crash, I found that the exception being thrown in the designer was ExecutionEngineException. The place it was being thrown was in an evaluation of a Code Contract (Requires<ArgumentNullException>). I quickly realised that I had added some code contracts into my WF design assembly but not enabled the code contract rewriter for compiling the assembly. Rather than throwing an ArgumentNullException for a given condition, the contract was not correctly written into the assembly and the framework threw ExecutionEngineException instead.

The ExecutionEngineException appears to be a fairly low level exception. Unfortunately its use in Code Contracts is confusing because of the lack of information about what is going wrong and how the developer should fix it.

It has been a long time coming, but Brian Harry has posted about how the next version of TFS will finally get a new merge/diff tool. Maybe the days of my most popular post are numbered.

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.