Seeing strange inexplicable issues in your Visual Basic .NET code? Keep this option in your back pocket… try to delete the Project’s .suo file.

I ran into the following error while trying to integrate Microsoft’s Sho library into a VB.NET project at work:

For the sake of google indexing, the error is:

BindingFailure was detected
The assembly with display name ‘ArrayT’ failed to load in the ‘Load’ binding context of the AppDomain with ID1. The cause of the failure was: System.IO.FileNotFoundException

I made sure to closely follow the installation information, and searching through the directory structure I found the ArrayT.dll was indeed in the /bin/ directory. It actually had two versions one for x86 another for x64. I tried to move each one at a time into the base bin directory just to try and help .NET track it down, no luck. I tried blowing away the compiled objects in the Projects own /bin/ and /obj/ directories, no luck. I tried using the Visual Studio menu option to Clean Solution, this manages to horribly break any ActiveX controls you might have added to a Form, and didn’t fix the Sho problem. (In another post I’ll talk about how to fix this ActiveX problem).

I downloaded the Sho C# example program, which had no problems running. Very curious.

Next, I tried creating a new VB project from scratch and added Sho… no problems. Perhaps its a pathing issue I thought, so I moved the new same named VB program into the original’s directory, the new project still worked.

At this point, I decided the problem might be related to the fact the non-working VB project was originally from an older version of Visual Studio and pushed to VS2010 using the auto-upgrade tools. I noticed there were significant differences between the two project’s core files, the .vbproj, .sln, .vbproj.user and several of the files in the /My Project/ subdirectory.

My next move was to recreate my original broken project from scratch in a shiny brand new VB2010 project. (A herculean task for a project this size). After the project was rebuilt, I added in Sho, and clicked run… and magically the BindingFailure was no more! Very curious.

Now in a quest to understand why the difference in behavior between the two projects, I spent the next several hours, with the help of Kdiff3, merging all of differences from the new project into the old project. Boy was there a lot of junk added into the old project from the VS2005 to VS2008 to VS2010 Upgrade path. After every few lines of merging code, I would rerun the solution to see if the problem was fixed. After all the files were almost identical (things like GUID‘s needed to be preserved), the problem was still not fixed.

My last resort was to just start deleting non user created code. My first choice, for reasons I’ll explain in a moment, was to blow away the project’s .suo file, a file which seems to be mostly unreadable binary format. After removing this file (actually I just renamed it) I fired up the project only to find the Error was gone!, my problem was solved just by deleting, and letting Visual Studio rebuild this file. Why? I have absolutely no idea. I sent an email to the Sho team divulging the same details of this adventure and I have yet to hear their thoughts on it. I’m staying hopeful some gears are grinding inside Microsoft to get this issue fixed.

The project I’ve been working on not only has been through a long upgrade path, but has also been switched between x64 and x86, and passed between developers. Unfortunately, I pulled the project from source control before this .suo file was excluded from the commit. Had it been excluded from the initial commit, I might never have seen this issue. However, this is also how I was able to directly target the .suo when I went into “start deleting arbitrary files” mode.

Basically, I opened the .suo file in Kdiff3 and noticed some fragmented bits of file paths. I noticed that some of my colleagues names were in the file paths, stuff like: C:\Users\{Colleague's Name}\... , somehow it seems this persisted information was enough to totally and un-obviously break Sho’s driver bindings, or perhaps its path resolution algorithm.

So lesson learned, when all else fails… actually, long before all else fails, delete that .suo project file.

Fingers crossed this blog post saves someone else from a day full of frustration.

If this has helped you, or you’ve had similar head scratching issues like this, leave a comment below and we can take solace in commiserating.