Geeks With Blogs
Path Notes of a Kodefu Master blog
I typically enjoy debugging. I think most developers do. We seem to be hard wired for puzzle solving.
I don't enjoy debugging cryptic errors or untruthful errors. Today, I've spent all my time trying to figure this gem out:
C:\dev\test.proj (227,5):  error MSB4061: The "StarTeamCheckout" task could not be instantiated from the assembly "C:\Program Files\MSBuild\MSBuildCommunityTasks\MSBuild.Community.Tasks.dll". System.IO.FileNotFoundException: Could not load file or assembly 'Interop.StarTeam, Version=, Culture=neutral, PublicKeyToken=e8bf2261941c3948' or one of its dependencies. The system cannot find the file specified. File name: 'Interop.StarTeam, Version=, Culture=neutral, PublicKeyToken=e8bf2261941c3948' at MSBuild.Community.Tasks.StarTeam.StarTeamCheckout..ctor() WRN: Assembly binding logging is turned OFF. To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1. Note: There is some performance penalty associated with assembly bind failure logging. To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
You see, I had to make StarTeam work with MSBuild. In the process, I ended up with an Interop dll for StarTeam. Naturally, the error message indicated to me that there was something wrong with the binding. I spent the entire day playing around with half the tools in .NET, trying to make the interop load, bind or do something! I even tried to enable the Fusion logging, according to the directions in the error message. Even that didn't work!
Eventually, I enlisted the help of one of the architects on the team. He instructed me to ignore the message, and load up FUSLOGVW.exe. After going through the settings in there, I looked back in the registry. Yep, the keys the error message spoke of were wrong.
The Fusion Log mentioned nothing of the StarTeam bindings. It did a problem with the logger. I was missing Kobush.Build.dll. However, that didn't seem to have anything to do with the error messages we were receiving.
An hour later, we had exhausted every possibility. The MSBuild project worked outside of CruiseControl.NET, and there weren't any security messages warning us of permissions. The CruiseControl.NET service was running as an administrator and should have access to the GAC and even the dll. Then Scott suggested we fix the Kobush problem, just to get it out of the Fusion Log.
The StarTeam error message went away.
I'm not sure if I'll ever figure out why the error was referencing the wrong assembly. I did learn a lot more about COM and .NET tools, so it wasn't a total waste of time.
Error messages are a nice debugging tool. Except for when they lie to you; then debugging becomes a nightmare of chasing phantom rabbits down thorny bunny trails.
Posted on Monday, June 25, 2007 5:24 PM Kodefu | Back to top

Comments on this post: Untruthful Errors

No comments posted yet.
Your comment:
 (will show your gravatar)

Copyright © Chris Eargle | Powered by: