What could be causing a System.TypeLoadException in a Visual Studio Unit Test?

Question

I've got a C# .NET class library MyClassLibrary that compiles fine. I'm trying to create a unit test project for it (using Visual Studio Unit Testing Framework, with Visual Studio 2010). The class library does have big classes in it, but whenever I run even the simplest test against the simplest class, I get the following exception:

Test method MyClassLibraryTest.MyClassLibraryTests.MySimpleClassTest threw exception: System.TypeLoadException: Could not load type 'MyClassLibrary.MySimpleClass' from assembly 'MyClassLibrary, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

All of the projects I'm dealing with are in the same solution, and all are compiled for .NET 4.0. All of this is on a Windows 7 64-bit machine.

Here's the weird part: when I "Run" the test, I get the above error. But when I "Debug" the test, it runs fine. Why?

Presentationism

MySimpleClass is not defined in the assembly or it has problems loading. Can you show the source for this class? – Mickimickie

Like I said, it ran fine in Debug. It shouldn't matter what the definition for MySimpleClass is; ANY class from the project fails to load in Run mode. I can't really fit any of the code on here, but I'm assuming this a build configuration issue (or visual studio setting, or something) rather than a code issue. – Presentationism

Try enabling Fusion logging to see where this assembly is being loaded from. – Multiplicity

Answer 1

The MyClassLibrary assembly was set to x86 mode in the configuration manager. Changing this to x64 fixed it. I really wish Visual Studio would detect this and report it as a less obscure error.

Presentationism

Answer 2

I just banged my head against this one for an hour. The problem was that I had a command line project named Something.exe, which was using a class library project named Something.dll.

Han

Same here. Thanks Amir. I still don't get why having the .dll and .exe the same causing an error – Wagner

Because for performance reasons the .NET runtime assumes that MyAssembly resides in either MyAssembly.dll or MyAssembly.exe (rather than scanning too many files). It's a feature of the language where you can load an .exe into your app as any other assembly (I've used this on a few occassions). Therefore when the .NET runtime attempts to load MyAssembly it tries MyAssembly.exe, sees that it's a valid .NET assembly, loads it, and fails to find the relevant class. – Han

Small error in the last comment - MyAssembly is already loaded, since we've executed MyAssembly.exe. – Han

Answer 3

Happened to me too. In my case the problem arised because the tested project and the unit tests project had the same name. If this is your case too then rename one of the projects and rename output file name to fix it.

Hackery

fyi: My project name was different. But in the settings, the assembly name / default namespace was the same. – Pignus

I had the same issue - had renamed a project to a different name, then created another project using the old name. Thanks for pointing this out! – Esquibel

@Pignus 4 years later, still saving lives! Thanks! – Kilian

Answer 4

Happened to me too. It is related to building for x64, Release and x86 mode. In my case, I deleted folders in my bin (debug/release/x86 in reference assemblies and unit test) and re-run my unit test. VS2010 somewhat reported the error in Output Window. That solved it for me.

Retrochoir

Answer 5

It happened to me when i was trying to add test project with the same main project name.

My main project name was : Calculator.OperationsManager my test project name was : Calculator.OperationsManager

i have changed the test project name as Calculator.OperationsManager.Test and everything went well.

Bruton

Same here. Two projects had the same default namespace and this problem arised. – Polonium

Answer 6

Came through this today and though I would leave my fix.

Specs: VS 2013 / .Net 4.0

Solution: Go into Menu > Test > Test Settings > Default Processor Architechture > X64

Lunna

Answer 7

Same message here, but I couldn't Debug the test either.

In my case, the DLL I was testing was deployed to the GAC (a BizTalk requirement). I had created a new class and was testing it, but hadn't GAC'd the DLL again since adding the class under test.

Dismember

Answer 8

I had similar problem as Trey, but instead of BizTalk, I have SharePoint solution which also uses GAC deployment. GAC had an older assembly. When I removed the GAC assembly by retracting the solution, the test passed.

Rowdy

For biztalk redeploying the application (Including assemblies to the GAC) worked – Istle

Answer 9

In case this helps others with the same error (I realise it doesn't directly answer the question re Release vs Debug); I merged in a legacy project with a namespace that conflicted with an existing one, so renamed it. I got this error when trying to create a form from that project.

I checked the platform target was the same, and deleted the .\bin\ directories to ensure a clean rebuild, removed the reference to the merged project and re-added it, but still the same error.

Eventually (!) I checked the Assembly Name in the project's properties (right click on project, select 'properties', select the 'Application' tab) and changed that to match the Default namespace, and all is now well.

Archbishop

Answer 10

I had this error using NUnit 3 in VS 2013. I solved it by deleting the assembly reference in my test project for the assembly that contained the type that was not being found, and then re-added the reference.

Washery

Answer 11

Just in case anyone needs this: I had created a test project in Visual Studio and had wondered why some Classes couldn't be found even if Visual Studio repeatedly asked me to add "System.Web" as reference.

I had done that and the error kept occurring. The problem for me was simple (and I should have checked that before, I know): I had created a test project from a template that created a .NET Core project. After changing it to .NET Framework 4.6.1 and adding "System.Web" as reference, everything worked fine.

Longevous

Answer 12

Encountered the same issue. Just in case if it helps anyone - I managed to get it to work by downgrading the nuget package NUnit3TestAdapter from version 3.13.0 to 3.11.2.

You can find more information on this - https://github.com/nunit/nunit-console/issues/424

Ustkamenogorsk

Answer 13

This happened to me as well. I had a nuget package installed on my domain project with version 1.5, but only had version 1.1 on my unit test project. I resolved the issue by updating the version on the unit test project to match the version on the domain project (the project being tested against).

Enrico

Answer 14

In my case obfuscated code caused the issue. I have disabled the code obfuscation and resolved the problem.

Bette