I have written the following simple test in trying to learn Castle Windsor\'s Fluent Interface:
using NUnit.Framework;
using Castle.Windsor;
using System.Col
I ran into this scenario when trying to load a type (via reflection) in an assembly that was built against a different version of a reference common to the application where this error popped up.
As I'm sure the type is unchanged in both versions of the assembly I ended up creating a custom assembly resolver that maps the missing assembly to the one my application has already loaded. Simplest way is to add a static constructor to the program class like so:
using System.Reflection
static Program()
{
AppDomain.CurrentDomain.AssemblyResolve += (sender, e) => {
AssemblyName requestedName = new AssemblyName(e.Name);
if (requestedName.Name == "<AssemblyName>")
{
// Load assembly from startup path
return Assembly.LoadFile($"{Application.StartupPath}\\<AssemblyName>.dll");
}
else
{
return null;
}
};
}
This of course assumes that the Assembly is located in the startup path of the application and can easily be adapted.
If this is a Windows app, try checking for a duplicate in the Global Assembly Cache (GAC). Something is overriding your bin / debug version.
If this is a web app, you may need to delete on server and re-upload. If you are publishing you may want to check the Delete all existing files prior to publish check box. Depending on Visual Studio version it should be located in Publish > Settings > File Publish Options
Just run into this with another cause:
I was using a merged assembly created with ILRepack. The assembly you are querying the types from must be the first one passed to ILRepack or its types will not be available.
I had the same issue and for me it had nothing to do with namespace or project naming.
But as several users hinted at it had to do with an old assembly still being referenced.
I recommend to delete all "bin"/binary folders of all projects and to re-build the whole solution. This washed out any potentially outdated assemblies and after that MEF exported all my plugins without issue.
Deleting my .pdb file for the dll solved this issue for me. I'm guessing it has something to do with the fact that the dll was created using ILMerge.
I was getting this error and nothing I found on StackOverflow or elsewhere solved it, but bmoeskau's answer to this question pointed me in the right direction for the fix, which hasn't been mentioned yet as an answer. My answer isn't strictly related to the original question, but I'm posting it here under the assumption that someone having this problem will find there way here through searching Google or something similar (like myself one month from now when this bites me again, arg!).
My assembly is in the GAC, so there is theoretically only one version of the assembly available. Except IIS is helpfully caching the old version and giving me this error. I had just changed, rebuilt and reinstalled the assembly in the GAC. One possible solution is to use Task Manager to kill w3wp.exe. This forces IIS to reread the assembly from the GAC: problem solved.