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 add a functionality that can send files from the local device to the distant server. I found the library "Tamir.SharpSSH" which can guarantee this. I tested the code on a console application and on normal windows forms application and it works perfectly. But when I tried to use the same code on the winCE device, I get a TypeLoadException and I have the error message:

Could not load type 'Tamir.SharpSsh.SshTransferProtocolBase' from assembly 'Tamir.SharpSSH,   
Version=1.1.1.13, Culture=neutral, PublicKeyToken=null'.

the code that I'm use is like below :

SshTransferProtocolBase sshCp = new Scp(Tools.GlobalVarMeth.hostName, Tools.GlobalVarMeth.serverUserName);
sshCp.Password = Tools.GlobalVarMeth.serverUserpassword;
sshCp.Connect();

string localFile = Tools.GlobalVarMeth.applicationPath + "/" + fileName + ".csv";
string remoteFile = Tools.GlobalVarMeth.serverRemoteFilePath + "/" + fileName + ".csv";

sshCp.Put(localFile, remoteFile);
   
sshCp.Close();

Any one have any idea on this ? I will be really grateful !!!

You're trying to use desktop *code* or a compiled desktop *assembly* in the Compact Framework? The former might work (unusual, but possible) the latter absolutely cannot work. — ctacke, Apr 19 '13 at 02:41
Take an SFTP library for .NET CF. Eg. you can take our SecureBlackbox (http://www.eldos.com/sbb/net-sftp.php) or Rebex.Net . — Eugene Mayevski 'Callback, Apr 20 '13 at 15:36

score 45 · Accepted Answer · answered Apr 18 '13 at 14:59

45

It could be any number of things. Likely causes are:

The assembly cannot be found
An assembly that your assembly depends upon cannot be found
The assembly is found but the type isn't in it
The type's static constructor throws an exception

Your best bet is to use the Fusion log viewer to help diagnose it. Documentation is here:

http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.110).aspx

(FYI "Fusion" was the code name of the team that designed the assembly loading system; it is somewhat unfortunate that the code name ended up in the file name of the shipped product. The thing should have been called "AssemblyBindingLogViewer.exe" or some such thing.)

answered Apr 18 '13 at 14:59

Eric Lippert

647,829
179
1,238
2,067

2

For me, it was the static constructor throwing an exception. Thank you. – Thomas Nov 17 '15 at 19:31
1

In my case the DLLs at target machine were older. After updating them it worked fine. – HGMamaci Feb 17 '17 at 08:33
1

my problem was type's static constructor that throws an exception. I have ignored it until I saw your answer. Thanks a lot – smoothumut May 22 '17 at 08:56

score 26 · Answer 2 · answered Aug 25 '15 at 13:19

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.

This was problem in my case - main .exe project references another project in the same solution, but Assembly name was the same. Thanks! — miki, Jun 23 '17 at 22:24
This naming caused the same exception for me. I found this answer and see that I had already upvoted it from when naming did this to me a year ago! — Mike, Nov 29 '18 at 16:30
This was also the problem in my case. So the post fixed it for me. — Philipp Sch, Jul 12 '19 at 11:08

score 5 · Answer 3 · edited Oct 20 '22 at 21:36

5

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

edited Oct 20 '22 at 21:36

Thomas Weller

55,411
20
125
222

answered Jun 22 '17 at 07:38

Hudson

839
1
10
15

score 3 · Answer 4 · edited Apr 03 '19 at 07:47

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.

score 1 · Answer 5 · answered Apr 30 '13 at 12:15

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

score 1 · Answer 6 · answered Oct 01 '21 at 04:51

In my case the problem turned out to be a namespace conflict. I had multiple startup projects in the solution whose Main() was in class Program and I discovered that I had multiple Program classes defined in the same namespace, albeit in different assemblies.

score 0 · Answer 7 · edited Jun 20 '20 at 09:12

0

In my case problem was that I had two projects that used the same libraries in one solution. I've updated DLLs only in first project. So when I built solution, second project its override DLLs from first project(project build order).

Example:

Solution:

--MainProject

------MyDll v5.3.2.0

--Prototype

------MyDll v5.0.0.0

Problem gone after update DLLs in second project.

edited Jun 20 '20 at 09:12

Community

1
1

answered Nov 16 '17 at 12:18

Mroczny Arturek

419
1
8
22

score 0 · Answer 8 · answered Jun 27 '18 at 13:41

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).

score 0 · Answer 9 · answered Oct 22 '19 at 12:37

0

the typeName string parameter must be a fully qualified type name

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

answered Oct 22 '19 at 12:37

Eyad Husseini

1
1

score 0 · Answer 10 · answered Oct 20 '22 at 21:35

My TypeLoadException was caused by a struct with FieldOffset(1).

Could not load type '...' because it contains an object field at offset 1 that is incorrectly aligned or overlapped by a non-object field

with a struct definition starting with

[StructLayout(LayoutKind.Explicit, Pack = 1)]
unsafe struct Metadata
{
    [FieldOffset(0)]
    public readonly byte Length;
    [FieldOffset(1)]
    [MarshalAs(UnmanagedType.ByValTStr, SizeConst = 11)]
    public string ApplicationName;
...

score 0 · Answer 11 · answered Dec 03 '22 at 20:30

0

In my case, the issue was caused by the methods that were part of the new version of the software but when a previous version was loaded those methods simply did not exists. My solution was to create a separate class with all the methods that are available in one of the versions and in the main class I only call that separate class after checking the version. If you are using Revit API, you can do so with:

    application.ControlledApplication.VersionNumber

answered Dec 03 '22 at 20:30

Jaime

21
4

This does not really answer the question. If you have a different question, you can ask it by clicking [Ask Question](https://stackoverflow.com/questions/ask). To get notified when this question gets new answers, you can [follow this question](https://meta.stackexchange.com/q/345661). Once you have enough [reputation](https://stackoverflow.com/help/whats-reputation), you can also [add a bounty](https://stackoverflow.com/help/privileges/set-bounties) to draw more attention to this question. - [From Review](/review/late-answers/33331657) – Ragnar Dec 08 '22 at 06:23

What could be causing a System.TypeLoadException?

11 Answers11

Linked