I got bit by this old error in a new way the other day so I thought I should make a quick checklist for myself since I made some mistakes in my troubleshooting process.
First I would start by reading How the Runtime Locates Assemblies. However, unless you are depending one of the methods that change the normal process, like including additional "codebases" or publisher policy redirection, then we can widdle this down to a few simple causes:
The Old Problems - Local Files and the GAC
Many if not most applications rely on a simple xcopy deployment, meaning that all of the application's files will be bundled together in the same directory. If you're simply copying or app folder from one place to another and it's not working on the new machine than either you simply missed a dll or you were using a GAC'd assembly on your development machine and didn't realize it. If you're using a third party component that was installed with a setup program, than there's a good chance that your referenced assembly is in the GAC. In that case you need to decide if you you want to run the third party install program as part of your deployment or figure out which dlls that you need and copy them to the folder.
GAC or otherwise, your app isn't going to find anything if it references a different version than what you have installed. There are two options if realigning the deployed version isn't an option. Either change "Specific Version" to false in the reference properties in Visual Studio or do a policy redirection. I actually recommend the latter since big companies will include policies for the GAC that point old references to newer versions. On the flip side, changing specific version to false will let your app load any version including an ancient one which might give you all sorts of strange errors.
The New Problems - 32 Bit, 64 Bit and the Platform Target Configuration
It's the last cause that is the inspiration for this post since it has now bit me multiple times. In my case i was referencing Oracle.DataAccess.dll from Oracle's data provider for .net. ODP.net throws in some additional variables like PATH and "ORACLE_HOME" environment variable dependencies that threw me off correctly debugging the problem. After double checking that the dll was in the GAC, and then even copying the dll to the app folder in desperation, I still was getting the error in question. The error also included the phrase "or one of its dependencies" which kept doubling me back to a PATH problem. In retrospect I really don't ever remember a case where this error was caused by a dependent dll so I'm not sure why I put so much stock in that route.
Finally I got my wits back and loaded a consistent savior, Sysinternals Process Monitor. I don't know why I'm so slow to use this tool some times. Maybe it's the 5 minutes you have to spend getting the filters right, but 9 times out of 10 it more or less tells me exactly what is wrong. Sure enough I saw the program trying to find my dll in GAC_32. Why is it looking for a 32 bit dll when we are on a 64 bit machine with the 64 bit oracle provider....you dumb-ass I thought to myself, knowing that I had seen this before. Sure enough the task manager showed the infamous *32 next to my process. I went back to visual studio and looked that the build properties for my exe project - once again Platform Target was set for "x86". I set it to "Any CPU", recompiled and the stupid world was right again.
I collect screenshots of errors (yes I'm a geek). I find it to be a friendly reminder that no piece of software is ever bug-free, regardless of how big the company is. And I'm not talking obscure, hard to reproduce, stuck in a feature that nobody uses, bugs. These are up front and center. I'll update this post as I get them.
3/16/2011 - Oracle Data Modeler 3
Gmail after clicking the button to register a new account:
