System.TypeLoadException: Method does not have an exception

Sometimes you hit smack in to a runtime exception that requires a weekend off to get your head straight again to tackle come Monday morning.  That was my experience today, as I wrangled with an unexpected exception when doing something I’d done plenty of times before.

Our app has the following structure:

• Interfaces assembly
• Business Logic assembly (where interfaces are implemented)
• Web Application (where Interface and Business Logic are married using the Unity Framework)

We have a build script that copies the latest version of the Business Logic assembly in to the /bin directory of the Web Application, since that app does not reference the assembly directly.

It has been fairly routine for us, when adding or extending functionality, to add methods to our Interfaces library, implement the corresponding method in the Business Logic library, then use that method in our Web app.  But this time around, even after clean builds, we’d get a runtime error when the Unity framework would try to initialize.

A bit of searching online revealed that this error occurs often when you’re not looking at the most recent version of an assembly that is implementing the Interface, and so to the Framework, it appears that the implementation is missing, even though your compiler will run clean.

As a step to make sure that there were no residual versions of previously built assemblies, I went through Windows Explorer to purge the /bin directories.  Something caught my eye as I was looking at the /bin directory for the Business Logic library – an extra subdirectory names ‘x86’.  In this directory were the Debug and Release subdirectories, and then the new build of the assembly.

So, it appeared the problem was that our build script was not in fact getting the latest version of our assembly since it was in a different (unexpected) location.

The x86 name was a clue to look at the Configuration Manager in Visual Studio.  Sure enough, somehow the Business Logic project got set explicitly to x86 rather than ‘Any CPU’.

I changed the target platform for that project, did a new clean and rebuild, and this time through, the app loaded up without error.

Thankfully I didn’t spend an unrecoverable amount of time trying to sort this out, but I still thought it may be helpful to record for others who run in to that error and, as I did, mistakenly believe that nothing has changed to trigger the new runtime exception.