Improving unit test coverage with NCrunch

My team has been doing a lot to improve unit test coverage lately, and one of the tools we rely on is NCrunch.

NCrunch provides real time feedback on your unit tests and coverage by running your tests in the background while you edit your code.

This provides a near instantaneous view of which lines of code are covered and what tests are failing and which lines are causing them to fail.

Check it out, it’s a great tool!

Mixed Content in Internet Explorer

I spent a significant amount of time today tracking down a problem on one of our web applications.

One of our customers complained about seeing the infamous This Page Contains Both Secure and Nonsecure Items warning every time they viewed any of the site’s pages with Internet Explorer.

This page contains both secure and nonsecure items

This error occurs when you are viewing a web site over an SSL (HTTPS) connection, but there are one or more nonsecure items on the page.

In the end, our particular manifestation was due to having numerous iframe objects embedded in our pages with their src properties set to either javascript:void(0) or nothing at all.

The fix was to change all of these to use javascript:""; for their src property.

I found several resources online that were helpful in getting to the bottom of this problem:

The first is EricLaw’s excellent blog posting on the subject.

The other is this checklist for ruling out the possible causes.

Mercurial and Kiln

I’ve been working with the FogBugz bug tracker for quite a while now and I noticed that they offer a Mercurial based online version control system named Kiln.

I’ve been wanting to adopt one of these new-fangled distributed version control systems for some time now, so I decide to dive in and find out what all the fuss was about.

I read Joel Spolsky‘s excellent Mercurial tutorial, Hg Init and then set about installing Mercurial clients on all of my various workstations.

I ended up with TortoiseHG on my PC and MacHg on my Mac and so far I’m finding it to be a very flexible and easy to use system.

If you’re using Subversion or some other old-school version control system you should definitely take a look at Mercurial or GIT and see what you’re missing out on!

Dealing with the latest form of DLL hell

I’m working on a project which integrates a lot of legacy C++ code in several DLLs with a C# wrapper application.  Of course, the legacy code also references several third party libraries, just to make things interesting.

Everything was going well until I tried to run the application on a test VM and it displayed a very unhelpful error message:

This application has failed to start because the application configuration is incorrect.  Reinstalling the application may fix this problem.

The first thing I discovered, was that in order to run exectutables on a test machine that are linked to the DEBUG versions the VC runtime libraries, I’d need to copy the appropriate folders from the C:Program FilesMicrosoft Visual Studio 9.0VCredistDebug_NonRedist folder to the executable’s directory on the test machine.  Here’s some relevant information on MSDN regarding this:

Unfortunately this was just the tip of the iceberg.

After copying the correct runtime library DLLs, I was still greeted with the same error when I tried to run my application.  The system event log contained a clue in the form of a SideBySide error:

A component version required by the application conflicts with another component version already active.

Hmm.  Some component wasn’t playing nice with some other component!

After a lot of googling, I ran across this Stack Overflow question which led to the eventual resolution:

Apparently, some of the third party libraries were causing the linker to reference older VC runtime library versions, so our component’s manifest file was listing multiple versions.

This was apparently what was causing the problems on the test machine.

The fix was to add the following to the pre-processor directives for each of our projects which forces everything to reference the latest runtime libraries:


If you run into this, pay attention to this paragraph from the accepted answer which details a great way to debug this problem:

A great way to debug which libraries don’t have the preprocessor directives set: temporarily modify your platform headers so that compilation stops when it tries to embed the old manifest. Open C:Program FilesMicrosoft Visual Studio 9.0VCcrtincludecrtassem.h. Search for the ‘21022’ string. In that define, put something invalid (change ‘define’ to ‘blehbleh’ or so). This way, when you’re compiling a project where the _BIND_TO_CURRENT_CRT_VERSION preprocessor flag is not set, your compilation will stop and you’ll know that you need to add them or made sure that it’s applied everywhere.

This tip really helped me to identify and correct the projects which where causing the problem.

It’s amazing to me how far we’ve come from the days when this type of problem was routine.  With the advent of .NET, this sort of thing is rarely a problem until you try to use some old C++ libraries.  I hope you never have to deal with this sort of thing!