I'm writing this mainly for the search engines.
A recent project has me using Visual Studio 2008 with web services, and I spent a bunch of time tracking down this error (click the image above for the exact dialog):
BindingFailure was detected
The assembly with display name 'MyLibrary.XmlSerializers' failed to load in the 'LoadFrom' binding context of the AppDomain with ID 1. The cause of the failure was:
System.IO.FileNotFoundException: Could not load file or assembly
I wasn't intentionally doing any LoadFrom, and the Web Services code was more or less stock output from the wsdl command. Hmmm.
It turns out this is an artifact of an optimization in Whidbey (VS2008), and easily worked around. This post includes this information from Microsoft:
The behavior you're seeing with the XmlSerializer is by design. The XmlSerializer has a new feature in whidbey that supports loading pre-generated serializers at runtime. This can greatly improve performance, as well as providing other usability benefits; however, the only way we can "probe" for the pre-generated assembly is to try to load it. This is why you're seeing these "file not found" errors -- the XmlSerializer is probing for pre-generated assemblies. These errors should be caught by the XmlSerializer and runtime should resume normally.
... XmlMessaging team
As interesting as this is, it's not showing how to make the problem go away, but a bit more digging showed that this was a self-inflicted problem on my part. Previously in the project, I had enabled every exception I could find, and this was causing a routine exception (that was designed to be caught by the platform) but breaking on it.
The solution in my case was to turn this off by selecting Debug : Exceptions... and disabling Managed Debugging Assistants:
Poof: end of problem.