dll hell, it never seems to go away. We've probably all seen this error message at one point or another but it isn't always obvious what has happened even though the error message is usually helpful. I wanted to list some reasons why you might get this error, including on web applications that are deployed to a server/cloud somewhere.

  1. You have referenced a dll indirectly and have not included it in your deployment. For instance, you've included Dependency.dll but Dependency.dll relies on SomeOther.dll which has not been included. The error message might include the name of Dependency or SomeOther.dll. If it is the name of something that you HAVE already included, then use Reflector to work out what other dependencies it might have but which are not included.
  2. You have referenced a dll that is in YOUR gac but which is not installed on your target platform gac. This is quite common because developer machines often have a raft of SDKs etc. installed with many assemblies in the gac. If you add a reference to these, they will NOT copy into the output directory by default (The "Copy local" option in properties) since they are assumed to be global dlls. Naturally, not all platforms have all the same assemblies installed so this can sometimes fail after deployment. All you need to do is choose "Copy local = true" for the reference and they will be included. In general, only the System.Whatever dlls do not need to be copied locally.
  3. You have referenced multiple versions of the same dll. Again, this is very common when using libraries which themselves might be referencing the same dlls that your top-level project is. It is OK to do this but your web.config will usually need an assembly redirect to tell the compiler that requests for Whatever.dll from versions x to y should all be passed onto the assembly with version y.
  4. You have copied your dependency from another machine without its dependencies. So imagine that you want to use Azure Storage, you copy in Microsoft.WindowsAzure.Storage into your references and then deploy. You then find that this has a dependency on Microsoft.WindowsAzure.Configuration. Naturally, you need to work out the dependencies and pull these in too or use NuGet to ensure the dependencies are included.
  5. You have multiple references with different public keys! This one caught me out recently and confused me because I had the assembly redirect which should have moved all dependencies to the latest version but unfortunately the latest version was from NuGet and had a different public key to the one pulled in by one of my libraries. Careful examination of the error message and the assembly redirect pointed this out. I could have added another redirect but instead I rebuilt the library with the NuGet version to make it neater.
That's all I can think of for now but if you think of any more, let me know and I'll add them.