Failed to load type from build error

Question

I wrote the following simple test, trying to learn the Castle Windsor Fluent interface:

using NUnit.Framework; using Castle.Windsor; using System.Collections; using Castle.MicroKernel.Registration; namespace WindsorSample { public class MyComponent : IMyComponent { public MyComponent(int start_at) { this.Value = start_at; } public int Value { get; private set; } } public interface IMyComponent { int Value { get; } } [TestFixture] public class ConcreteImplFixture { [Test] public void ResolvingConcreteImplShouldInitialiseValue() { IWindsorContainer container = new WindsorContainer(); container.Register(Component.For<IMyComponent>().ImplementedBy<MyComponent>().Parameters(Parameter.ForKey("start_at").Eq("1"))); IMyComponent resolvedComp = container.Resolve<IMyComponent>(); Assert.AreEqual(resolvedComp.Value, 1); } } } 

When I run a test through TestDriven.NET, I get the following error:

 System.TypeLoadException : Could not load type 'Castle.MicroKernel.Registration.IRegistration' from assembly 'Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc'. at WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue() 

When I run the test through the NUnit GUI, I get:

 WindsorSample.ConcreteImplFixture.ResolvingConcreteImplShouldInitialiseValue: System.IO.FileNotFoundException : Could not load file or assembly 'Castle.Windsor, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies. The system cannot find the file specified. 

If I open the assembly that I reference in Reflector, I see that its information:

 Castle.MicroKernel, Version=1.0.3.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc 

and that it definitely contains Castle.MicroKernel.Registration.IRegistration

What could be?

I should mention that the binaries were taken from the latest Castle assembly , although I never worked with nant, so I did not worry about -compiling from the source and just taking the files in the bin directory. I should also indicate that my project compiles without problems.

Answer 1

Is the assembly in the global assembly cache (GAC), or anywhere that can override the assembly you think is loading? Usually this is the result of loading the wrong assembly, for me it means that I usually have something in the GAC that overrides the version that I have in bin / Debug.

Answer 2

If you have one project referencing another project (for example, type "Windows Application" referencing "Class Library") and both have the same Assembly name, you will get this error. You can either strongly name the project you are referring to, or (even better) rename the assembly of the project links (on the "Application" tab of the project properties in VS).

Answer 3

Sorry to post the old answer to the question, but the solution for this was not mentioned above, so I thought I would add my answer to the long tail ...

As a result, I got an old reference to the class (HttpHandler) in web.config, which was no longer used (and was no longer a valid link). For some reason, it was ignored while working in Studio (or maybe I have this class that is still available in my dev setup?), And so I got this error only after I tried to set it to IIS I looked for the assembly name in the web.config file, deleted the link to the unused handler, after which this error disappeared, and everything works fine. Hope this helps someone else.

Answer 4

I had the same problem and for me it had nothing to do with the namespace or project name.

But since several users have hinted at this, this is due to the old assembly that is still referenced.

I recommend deleting all the bin / bin folders of all projects and rebuilding the whole solution. This washed out any potentially obsolete builds, and after that MEF exported all my plugins without any problems.

Answer 5

I was getting this error and didn’t find anything on StackOverflow or it solves it elsewhere, but bmoeskau answered this question in the right direction for a fix that was not mentioned as an answer yet. My answer is not strictly related to the original question, but I post it here on the assumption that someone who has this problem will find a way here through a Google search or something similar (for example, I’m a month later when this bite me again, arg!).

My assembly is in the GAC, so theoretically only one version of the assembly is available. With the exception of IIS, it helps to cache the old version and give me this error. I just changed, rebuilt, and reinstall the assembly in the GAC. One possible solution is to use the task manager to destroy w3wp.exe . This forces IIS to re-read the assembly from the GAC: the problem is resolved.

Answer 6

Version = 1.0.3.0 points to the RC3 lock, however a free interface was developed a few months after the release of RC3. So it looks like you have a version issue. Perhaps you have an RC3 lock registered in the GAC and it uses this ...

Answer 7

I get this from time to time, and it was always unavailable for assembly in the GAC

Answer 8

If this error is caused by a change in the namespace, make sure that the folder of this project is renamed to the same name and close VS.NET Change the project that has a problem with Notepad and replace the nodes there

"RootNamespace> New_Name_Of_Folder_Of_Your_Project_Namespace" RootNamespace> "AssemblyName> New_Name_Of_Folder_Of_Your_Project_Namespace" AssemblyName>

Answer 9

Removing my .pdb file for dll solved this problem for me. I assume this is because the DLL was created using ILMerge.

Answer 10

When I encounter such a problem, I find the FUSLOGVW tool very useful. It checks assembly binding information and writes it for you. Sometimes libraries are missing, sometimes the GAC has different versions that are loading. Sometimes the reference library platform causes problems. This tool makes it clear how dependency bindings are resolved, and it can really help you investigate / debug your problem.

Fusion Log Viewer / fuslogvw / binding viewer assembly. More details / download here: http://msdn.microsoft.com/en-us/library/e74a18c4.aspx .

Answer 11

Just do it for another purpose:

running unit tests in release mode, but the loadable library was a version of debug mode that was not updated

Answer 12

Just run into this for another reason:

I used a federated assembly created using ILRepack. The assembly from which you request types must be the first one passed to ILRepack, otherwise its types will not be available.

Answer 13

Another solution: old DLLs pointing to each other and cached by Visual Studio in

C:\Users\[yourname]\AppData\Local\Microsoft\VisualStudio\10.0\ProjectAssemblies

Exit VS, delete everything in this folder and your uncle's bob.

Answer 14

I had this problem after factoring the class name:
Could not load type 'Namspace.OldClassName' from assembly 'Assembly name...'.

Stopping IIS and deleting content in Temporary ASP.NET Files fixed it for me.

Depending on your project (version 32 / 64bit, .net, etc.), the correct Temporary ASP.NET Files is different:

• 64 bit
  %systemroot%\Microsoft.NET\Framework64\{.netversion}\Temporary ASP.NET Files\
• 32 bit
  %systemroot%\Microsoft.NET\Framework\{.netversion}\Temporary ASP.NET Files\
• On my dev machine, that was (because its IIS Express maybe?)
  %temp%\Temporary ASP.NET Files

Answer 15

I had the same problem. I just solved it by updating the assembly through the GAC.

To use gacutil on a development machine, go to: Start -> programs -> Microsoft Visual studio 2010 -> Visual Studio Tools -> Visual Studio Command Prompt (2010) .

I used these commands to remove and reinstall accordingly.

 gacutil /u myDLL gacutil /i "C:\Program Files\Custom\mydllname.dll" 

Note: I did not delete my dll in my case, I just updated the dll with the current path.

Answer 16

Perhaps this is not so likely, but for me it caused my application trying to load the library with the same assembly name (xxx.exe, loading xxx.dll).

Answer 17

I came across this scenario when trying to load a type (via reflection) in an assembly that was created against a different version of the link common to the application where this error appeared.

Since I am sure that the type has not changed in both versions of the assembly, I have finished creating a custom assembly resolver that maps the missing assembly to the one already loaded by my application. The easiest way is to add a static constructor to the program class as follows:

 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, suggests that the Assembly is on the way to launching the application and can be easily adapted.

Answer 18

You may be able to solve this problem with link forwarding in * .config. http://blogs.msdn.com/b/dougste/archive/2006/09/05/741329.aspx is well discussed using older .net components in the new framework. http://msdn.microsoft.com/en-us/library/eftw1fys(vs.71).aspx

Answer 19

This usually happens when you have one version of your assembly deployed to the GAC but have not been updated with new classes that you might have added to the assembly in your IDE. Therefore, make sure the build in the GAC is updated with the changes that you could make to your project.

eg. if you have a generic class library, and in this class library you have the type Common.ClassA and expand it for the strong GAC name. You come back later and add another type called Common.ClassB, and you run your code in your IDE without first deploying the changes you made to the GAC Common along with the recently added Common.ClassB type.

Answer 20

I got the same error after updating the reference DLL in an executable project on the desktop. The problem was that the people mentioned here referred to the old link and were easy to fix, but were not mentioned here, so I thought this could save other people's time.

In any case, I updated dll A and got an error from another dll link, calling her B here, where dll A has a link to dll B.

Updating dll B fixed the problem.

Answer 21

Adding your DLL to the GAC (Global Assembly Cache)

Visual Studio Command Prompt => Run as Administrator

gacutil / i "dll file path"

You can see the added assembly C: \ Windows \ system32 \

It will also decide that the dll is missing or "Failed to load the file or assembly" in the SSIS Script task

Answer 22

I ran into a similar issue in Visual Studio 2017, using MSTest as a testing environment. I received System.TypeLoadException exceptions when running some (not all) unit tests, but those unit tests were passed during debugging. I eventually decided the following:

1. Open the Local.testsettings file in the solution
2. Go to the "Test Device" settings
3. Uncheck the "Use download context for assemblies in the test directory" box. check box

After completing these steps, all unit tests began to pass at startup.

Answer 23

I experienced the same thing as above after removing the assembly signature in the solution. Projects will not build.

I found that one of the projects refers to the StrongNamer NuGet package, which modifies the build process and tries to sign unsigned Nuget packages.

After removing the StrongNamer package, I was able to create the project again without signing / strongly calling assemblies.

Answer 24

I just solved this by running the iisreset command using the command line ... Always the first thing I do when I get such errors.