I've been fighting with IIS the last few days and the error that IIS generates is:

Exception: System.Runtime.Serialization.SerializationException

Message: Unable to find assembly 'FluentNHibernate, Version=, Culture=neutral, PublicKeyToken=8aa435e3cb308880'.

What's strange is that if I check in procmon, I can watch the IIS process find the dll in the directory where I would expect it to find it, and then it continues to search other directories for the exact same dll. It is also searching for the PDB for some reason for the DLL. The DLL also exists in the temp directory that IIS creates:

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files\ws-sm\bc2df7a7\729516d\assembly\dl3\42ab9d3b\00d491a3_3e6bcd01\FluentNHibernate.DLL

So it was clearly able to copy the dll to it's running location, but it reports it can't find it.

I checked all of my web.config files and compilation debug is set to false in all cases so I'm surprised to see it looking for pdbs.

Googling this error didn't return anything useful.

I'm using Win2k8 x86 with IIS 7 and my application pool is ASP.NET v4.0 Integrated.


This is a typical .NET troubleshooting issue.

A couple of things:

  1. The SerializationException you see is a higher level error. It is not the root cause.
  2. The Message where it was unable to find the assembly means a couple of things:
    1. You either do not have the required file in the bin directory of the application.
    2. The file in the bin directory is not the right version. (most likely)
  3. The temp file path has nothing to do with it, this is just that a temp place and the file may already have been copied over from before.
  4. The PDB or debug database is looked for to help extract symbols and other debug information to provide you with a more detailed error, either way it is not required and seldom deployed with compiled production DLLs.

I would definately make sure that the version of the Fluent NHibernate DLL matches what the software expects to run. You may have to contact the developer/vendor to clarify the issue though. Most likely this is not an IIS problem as much as it is an application problem.

  • In this case I am the developer, and I checked the version of the dll, and the version it's looking for is the version that is there. This install has working in many other cases so I don't believe that the DLLs is the direct cause. It is only on this one machine, and I've reinstalled just to make sure that it is correct. – Zipper Aug 6 '12 at 15:33
  • Have you verified that the web.config modules and handlers have the same version and thumbprint as the version of the actual file? – Brent Pabst Aug 6 '12 at 16:09
  • In this case the web.config doesn't actually list the DLL. This DLL gets loaded through another dll which in turn gets loaded from an ASMX page. – Zipper Aug 6 '12 at 16:41
  • OK, well regardless most of the time when I have had to troubleshoot .NET errors loading DLLs it has centered around an error either in configuration or code. As it stands there is nothing that you have posted that points to IIS, it all points to the application. – Brent Pabst Aug 6 '12 at 16:43

I finally figured it out and it wasn't related to IIS. Posting my answer in case someone else comes along in the future with a similar problem.

What ended up being my issue was that I was unable to connect to one of my databases, and this caused an exception to be thrown. Somehow (still not sure how) this was caught by one thing, and then caught by IIS which tried to serialize an error message, but it couldn't find a DLL it needed since where it ended up catching it was in another AppDomain. I ended up finding this problem by attaching windbg to the w3wp process and watching it start up.

So if you get this error try attaching windbg to your process and see what errors are being thrown.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.