The Located Assembly's Manifest Definition Does Not Match the Assembly Reference

This is a common error in many .NET applications, not just DNN. If you want to start with some light background reading on the reasons why this error occurs, read this blog post. Otherwise, this article will specify how we resolve the issue in DNN sites.

 

The error manifests within DNN logs like this:

InnerMessage:Could not load file or assembly 'DotNetNuke.Web.Deprecated' or one of its dependencies. 
The located assembly's manifest definition does not match the assembly reference.  

As stated, this is caused when the version of a .dll file in the /bin directory (assembly reference), is not the same as specified in the web.config (assembly manifest).

The actual assembly referenced, 'DotNetNuke.Web.Deprecated', might be any number of other files. Commonly seen assemblies:

• NewtonSoft.JSON
• AWSSDK
• DotNetNuke.HttpModules
• Third-party libraries

Root Cause

The root cause for the error occurring can vary widely:

• A version upgrade replacing files.
• A script which does not replace files as expected.
• Someone manually copying items into the /bin directory.
• The web.config being write-locked.
• Etc.

Resolution

In most cases, unless the issue repeatedly occurs, the root cause is not that relevant. Quickly resolving the error so that the page loads is more important. To do that we consider two possible cases:

1. The file version is correct, but the assembly binding is wrong.
2. The assembly binding is correct, but the file version is wrong.

 

The "correct version" depends on the context. If you just installed a module which uses a newer library than previous versions, the new version number is the correct one. Conversely, if you uninstall a module, but it does not remove the shared file, then the old number is the correct one.

Based on which case your site is experiencing, the solution is one of the following:

1. Update the assembly binding in the web.config file to match the version of the file which currently exists in the /bin directory.
2. Replace the file in the /bin directory with the version which matches the assembly binding within the web.config.

 

Note: If you need a default file which was overwritten by a third-party extension, you can find them within the Install package. Similarly, if you need to check the version specified for a default assembly binding, check the web.config file of an unmodified DNN site.

 

Troubleshooting

By this point, you should have resolved the error bringing your site or page down. However, if you are unlucky enough to have the issue reoccur, there is still work to be done. Knowing that the error is caused by a version mismatch between the file in the /bin directory and the assembly binding declaration in the web.config, we need to determine one of the following:

1. Why those numbers are not updated as required.
2. Why they might be changed unnecessarily.

 

For the first situation, you need to look for additional errors logged around the same time. For example, a 500.19 with:

The error code 0x80070005 E_ACCESSDENIED - General access denied error
“Config Error Cannot read configuration file due to insufficient permissions ”

Which would indicate an issue with the site's worker process accessing the web.config.

For the second situation, a helpful tool which can provide some insights into who or what is changing the files is Procmon from Sysinternals.

 

If you have fixed the version numbers so they match, yet the error persists, another possibility is that the assembly being used actually exists in the GAC or ASP.NET temp files so you may need to clear these as well.