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.
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.
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.