What could be causing a System.TypeLoadException?

Question

I\'m developing, with VS2008 using C#, an application for Honeywell Dolphin 6100, a mobile computer with a barcode scanner that uses Windows CE 5.0 like OS.

I want to

Answer 1

Make sure the names (namespaces, class names, etc) are what they are supposed to be. I got this error when I had to start over on my project and I copied the contents of my class from a template and failed to change the class name from "Template Class" to the correct name (it was supposed to match the project name).

Answer 2

the typeName string parameter must be a fully qualified type name

For instance : Activator.CreateInstance("assemblyFullName","namespace.typename")

Answer 3

The answer of Eric Lippert perfectly describes the situation.

I just want to add a quick answer about a case which is usually not covered by help pages regarding this exception.

I've created a quick & dirty test project for some open source stuff (Akka.Net, to name it) and I name the project itself "Akka".

It perfectly builds, but at startup it throws it type load exception regarding a class in Akka.dll.

This is just because my executable (akka.exe) and the reference (akka.dll) have the same name. It took me a few minutes to figure this (I've began by things such as copy local, target platform, exact version... etc).

It's something very dumb but not forcibly the first thing which you will think (especially since I used nuget for dependancies), so I thought it could be interesting to share it : you will encounter TypeLoadException if your EXE and a dependancy have the same name.

Answer 4

This could be caused by any number of things, MSDN has it said as:

TypeLoadException is thrown when the common language runtime cannot find the assembly, the type within the assembly, or cannot load the type.

So it's clear that a type can't be found, either the assembly is missing, the type is missing or there's a clash between runtime configurations.

Sometimes the issue can arise because the assembly you're referencing is a different platform type (32bit / 64bit etc) than the one you're consuming from.

I would recommend catching the exception and examining it in more detail to identify what it's having trouble with.

---

Further to my previous information

Sometimes I've seen this issue arise because (for one reason or another) a referenced assembly can't actually be resolved, even though it's referenced and loaded.

I typically see this when AppDomain boundaries are involved.

One way I've found that sometimes resolves the issue (but only if the assembly is already in the AppDomain) is this code snippet:

AppDomain.CurrentDomain.AssemblyResolve += (s, e) =>
{
   return AppDomain.CurrentDomain.GetAssemblies()
      .SingleOrDefault(asm => asm.FullName == e.Name);
}

Like I said, I see this issue when AppDomains get involved and this does seem to solve it when the assembly is indeed already referenced and loaded. I've no idea why the framework fails to resolve the reference itself.

Answer 5

This almost drove me crazy...

I don't know how I managed this, but for some reason I had an old version of the DLL in GAC. Try looking for an old assembly there and remove it.

Best of luck!

Answer 6

You can get loader log files out of the .NET Compact Framework by enabling some settings in the registry. The Power Toys for .NET Compact Framework include a tool called NETCFLogging, which sets the registry values for you.

The registry values are documented here:

http://msdn.microsoft.com/en-us/library/ms229650(v=VS.90).aspx