// TODO: name this blog

Setting up Team Build 2010 to build installer projects (i’ll rant about installer projects some other time) as detailed by Jakob Ehn here I ran into the error message:

Package ‘Microsoft.VisualStudio.TestTools.TestCaseManagement.QualityToolsPackage, Microsoft.VisualStudio.QualityTools.TestCaseManagement, Version=10.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a’ failed to load.

It turns out I’m not the only one fighting this, see this thread on the msdn forums. Unfortunately there doesn’t seem to be much of a response on how to deal with your Team Build failing because of this anywhere. After plugging away for a bit I realized that if I didn’t include the MSTest related files (.vsmdi and .testrunsettings) in the solution the package load failure didn’t come up. This was a pain though, as it meant having to maintain a second solution without the test projects or configuration files. It also meant having to provide the means to have one solution compiled via msbuild to run tests on and the other “Installer” solution compiled via devenv.com. After a while I hacked up a work around I that seems cleaner for now (until hopefully someone at Microsoft so helpfully posts a real fix).

Interestingly enough the hack was inspired by the unused ExitCode variable Jakob sets up in his example. What I found was that the package load failure does not affect the exit code from devenv.com, it will still return success if the compilation succeeds and non-zero when it fails.

Based on this I decided instead of outputting the Error Output from the Invoke Process Activity directly with a WriteBuildError Activity as the sample shows:

I created another variable ErrorOutput scoped the same as the ExitCode, at the “Compile the Project” level, and Assign the Error Output to that variable:

Then after the Invoke Process Activity completes, I added a check to see if the ExitCode was successful. If it didn’t then I use WriteBuildError passing the saved ErrorOutput and throw an Exception so that the build picks up on the compilation failure.

When a build succeeds you can still see that package load failure occured if you enable diagnostic loggging and look at the Assign Activity output.

And when the compilation fails you end up with something like this in the build summary.

If the build fails like this you then dig into the log to see the actual compilation failure as it is masked by the package load failure.

A hack for sure, but the best one I could come up with for now.