[c#] Error message 'Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information.'

I have developed an application using Entity Framework, SQL Server 2000, Visual Studio 2008 and Enterprise Library.

It works absolutely fine locally, but when I deploy the project to our test environment, I am getting the following error:

Unable to load one or more of the requested types. Retrieve the LoaderExceptions property for more information

Stack trace: at System.Reflection.Module._GetTypesInternal(StackCrawlMark& stackMark)

at System.Reflection.Assembly.GetTypes()

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadTypesFromAssembly(LoadingContext context)

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.InternalLoadAssemblyFromCache(LoadingContext context)

at System.Data.Metadata.Edm.ObjectItemCollection.AssemblyCacheEntry.LoadAssemblyFromCache(Assembly assembly, Boolean loadReferencedAssemblies, Dictionary2 knownAssemblies, Dictionary2& typesInLoading, List`1& errors)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache(ObjectItemCollection objectItemCollection, Assembly assembly, Boolean loadReferencedAssemblies)

at System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyForType(Type type)

at System.Data.Metadata.Edm.MetadataWorkspace.LoadAssemblyForType(Type type, Assembly callingAssembly)

at System.Data.Objects.ObjectContext.CreateQuery[T](String queryString, ObjectParameter[] parameters)

Entity Framework seems to have issue, any clue how to fix it?

I changed the Specific Version Property of the Refrences to false and that helped.

I encountered this issue with entity framework when typing migration commands in Nuget console.

the problem showed up when I moved my OAuthAuthorizationServerProvider codes from my application into a class library project which contained core data access logic as well as my DBContext class.

I check all my DLLs referenced by the class library project. and for all of them (except .net system DLLs) CopyToLocal was true I was completely confused.

I knew that there was something wrong with DLLs themselves not my codes. I checked them again and I noticed that when I moved my ApplicationOauthProvider class into a class library project the ApplicationOauthProvider inherits from OAuthAuthorizationServerProvider class which is located in Microsoft.Owin.Security.OAuth assembly, I checked it's package version and suddenly noticed that the version of package that I used for the class library project (not my application project) is very old 2.1, but on my application the latest version was installed (3.0.1) so I upgraded version of the Microsoft.Owin.Security.OAuth package from Nuget fo my class library project and problem got away

In short after checking CopyToLocal property of your DLLs check their versions too and update the old ones to letest version

This worked for me. Add it in your web.config

<system.web>
  <trust level="Full" />

I had the same error message reported when compiling a Visual Studio package (VSPackage). The whole solution compiles and the error is thrown when the package is being created by CreatePkgDef. Having said that, it is clear that I cannot catch the LoaderExceptions as it is not my application that throws it, but Microsoft's own tool. (Though I am responsible for the confusion of CreatePkgDef.)

In my case the root cause was that my solution creates a MyDll.dll that has already been registered to the GAC (and they are different), so the CreatePgkDef got confused which one to use and it decided just to throw an error which isn't really helpful. The MyDll.dll in the GAC was registered by the installer of the same product (obviously an earlier version, with /slightly/ different content).

How to fix it

1. Preferred way: Make sure you use the correct version of MyDll.dll
   2. When compiling your project make sure you use a different version number than you used in the previous version located in the GAC. Make sure the following attributes are correct:
      • [assembly: AssemblyVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
      • [assembly: AssemblyFileVersion("1.0.0.1")] // Assuming the old DLL file was versioned 1.0.0.0
   3. If needed, specify the fully qualified assembly name (for example, "MyDll.dll, Version=1.0.0.1, Culture=neutral, PublicKeyToken=1234567890abcdef") when you reference it in your other projects.
2. If the above failed: You can uninstall the old MyDll.dll from GAC
   1. How to Uninstall an Assembly from the GAC
   2. Uninstall the application that includes MyDll.dll

Changing the AssemblyVersion was good enough for me. :)

I hope this was helpful.

The solution was to check the LoaderException: In my case, some of the DLL files were missing.

My issue has been resolved after I deleted the redundant assembly files from the bin folder.

I had an issue with automap. In the bin folder, the file automap.4net.dll was there, but for some reason the automap.xml and automap.dll weren't. Copying them to the bin directory solved the issue.

Adding my specific problem/solution to this as this is the first result for this error message. In my case, the error was received when I deployed a second application within the folder of my first application in IIS. Both were defining connection string with the same name resulting in the child application having a conflict and in turn generating this (to me) non-obvious error message. It was solved by adding:

<clear/>

in the connection string block of the child web application which prevented it from inheriting the connection strings of web.config files higher in the hierarchy, so it looks like:

<connectionStrings>
  <clear/>
  <add name="DbContext" connectionString="MySERVER" providerName="System.Data.SqlClient" />
</connectionStrings>

A reference Stack Overflow question which helped once I determined what was going on was Will a child application inherit from its parent web.config?.

Verify that each of your projects is setup correctly in the Configuration Manager.

Similar to William Edmondson's reason for this issue, I switched my Configuration Manager setting from "Debug" "Any CPU" to "Debug" ".NET". The problem was that the ".NET" version was NOT configured to build ALL of the projects, so some of my DLLs were out of date (while others were current). This caused numerous problems with starting the application.

The temporary fix was to do Kenny Eliasson's suggestion to clean out the \bin and \obj directories. However, as soon as I made more changes to the non-compiling projects, everything would fail again.

I was updating a website via FTP. I assume the website was in use and when trying to update the bin folder, a couple of the DLL files must have been locked and did not update.

There I saw the error 500 page and on setting of the customErrors mode to be Off, saw the error message mentioned by the OP.

The problem was I did not see the failures listed in the FTP program. I retried those failed fails and they uploaded. The last DLL file updated. So the site then worked.

I got this problem when I installed a NuGet package on one of the projects and forgot to update the other project.

I solved this by just making both projects having the same reference assembly.

I also got this issue when create new Microsoft Word add-in with Visual Studio 2015. The issue is about I have 2 versions of MS Office, 2013 and 2016. I uninstall MS Office 2013 and then it works.

I had a .NET 4.0, ASP.NET MVC 2.0, Entity Framework 4.0 web application developed in Visual Studio 2010. I had the same problem, that it worked on one Windows Server 2008 R2 server but not on another Windows Server 2008 R2 server, even though the versions of .NET and ASP.NET MVC were the same, throwing this same error as yours.

I went to follow miko's suggestion, so I installed Windows SDK v7.1 (x64) on the failing server, so I could run !dumpheap.

Well, it turns out that installing Windows SDK v7.1 (x64) resolved the issue. Whatever dependency was missing must have been included in the SDK. It can be downloaded from Microsoft Windows SDK for Windows 7 and .NET Framework 4.

Set 32 bit IIS mode to true, debug mode to true in the configuration file, deleting the temp directory and resetting IIS fixes the issue temporally and it comes back after some time.

In case none of the other answers help you:

When I had this problem, it turned out my Windows service was built for an x64 platform, and I was inadvertently running the 32-bit version of InstallUtil.exe. So make sure you're using the right version of InstallUtil for the platform you built for.

I encountered this error with an ASP.NET 4 + SQL Server 2008 R2 + Entity Framework 4 application.

It would work fine on my development machine (Windows Vista 64-bit). Then when deployed to the server (Windows Server 2008 R2 SP1), it would work until the session timed out. So we'd deploy the application and everything looked fine and then leave it for more than the 20 minute session timeout and then this error would be thrown.

To solve it, I used this code on Ken Cox's blog to retrieve the LoaderExceptions property.

For my situation the missing DLL was Microsoft.ReportViewer.ProcessingObjectModel (version 10). This DLL needs to be installed in the GAC of the machine the application runs on. You can find it in the Microsoft Report Viewer 2010 Redistributable Package available on the Microsoft download site.

Check this property by clicking 'View Exception Details':

Make sure you allow 32 bits applications on IIS if you did deploy to IIS. You can define this on the settings of your current Application Pool.

It happened for me also. I solved the problem as follows: Right click Solution, Manage NuGet Packages for Solution... Consolidate packages and upgraded the packages to be in the same version.

Another solution to know why exactly nothing works (from Microsoft connect):

1. Add this code to the project:

   foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
   {
       asm.GetTypes();
   }
   

2. Turn off generation serialization assemblies.

3. Build and execute.

If you are using Entity Framework, try copying the following references locally.

• System.Data.Entity
• System.Web.Entity

Change the property "Copy Local" to "True" for these references and publish.

I had the same issue (but on my local) when I was trying to add Entity Framework migration with Package Manager Console.

The way I solved it was by creating a console application where Main() had the following code:

 var dbConfig = new Configuration();
 var dbMigrator = new DbMigrator(dbConfig);
 dbMigrator.Update();

Make sure the Configuration class is the migration Configuration of your failing project. You will need System.Data.Entity.Migrations to use DbMigrator.

Set a breakpoint in your application, and run it. The exception should be caught by Visual Studio (unless you have that exception type set to not break the debug session), and you should be able to find the info you are looking for.

The missing reference in my case was EFProviderWrapperToolkit.

I am able to fix this issue by marking "Copy Local=True" on all referenced DLL files in the project, rebuilding and deploying on a testing server.

As it has been mentioned before, it's usually the case of an assembly not being there.

To know exactly what assembly you're missing, attach your debugger, set a breakpoint and when you see the exception object, drill down to the 'LoaderExceptions' property. The missing assembly should be there.

Hope it helps!

I build a few projects for SharePoint and, of course, deployed them. One time it happened.

I found an old assembly in C:\Windows\assembly\temp\xxx (with FarManager), removed it after reboot, and all projects built.

I have question for MSBuild, because in project assemblies linked like projects and every assembly is marked "Copy local", but not from the GAC.

One solution that worked for me was to delete the bin/ and obj/ folders and rebuild the solution.

Other suggestions are all good. In my case, the problem was that the developer box was a 64-bit machine using the x86 location of various APIs, including Silverlight.

By changing the target platform to match the 32-bit server where the web application was being deployed removed the majority of the errors related to not being able to load one or more of the requested types.

My instance of this problem ended up being a missing reference. An assembly was referred to in the app.config but didn't have a reference in the project.

This error has no true magic bullet answer. The key is to have all the information to understand the problem. Most likely a dynamically loaded assembly is missing a referenced assembly. That assembly needs to be in the bin directory of your application.

Use this code to determine what is missing.

using System.IO;
using System.Reflection;
using System.Text;

try
{
    //The code that causes the error goes here.
}
catch (ReflectionTypeLoadException ex)
{
    StringBuilder sb = new StringBuilder();
    foreach (Exception exSub in ex.LoaderExceptions)
    {
        sb.AppendLine(exSub.Message);
        FileNotFoundException exFileNotFound = exSub as FileNotFoundException;
        if (exFileNotFound != null)
        {                
            if(!string.IsNullOrEmpty(exFileNotFound.FusionLog))
            {
                sb.AppendLine("Fusion Log:");
                sb.AppendLine(exFileNotFound.FusionLog);
            }
        }
        sb.AppendLine();
    }
    string errorMessage = sb.ToString();
    //Display or log the error based on your application.
}

If you're using the EntityDataSource in your project, the solution is in Fix: 'Unable to load one or more of the requested types' Errors. You should set the ContextTypeName="ProjectNameNameSpace.EntityContainerName" '

This solved my problems...

Initially I tried the Fusion log viewer, but that didn't help so I ended up using WinDbg with the SOS extension.

!dumpheap -stat -type Exception /D

Then I examined the FileNotFoundExceptions. The message in the exception contained the name of the DLL that wasn't loading.

N.B., the /D give you hyperlinked results, so click on the link in the summary for FileNotFoundException. That will bring up a list of the exceptions. Then click on the link for one of the exceptions. That will !dumpobject that exceptions. Then you should just be able to click on the link for Message in the exception object, and you'll see the text.

In My case I had one nuget package that was installed in my project however package folder was never checked in to TFS therefore, in build machine that nuget package bin files were missing. And hence in production I was getting this error. I had to compare the bin folder over production vs my local then I found which dlls are missing and I found that those were belonging to one nuget package.

I had this issue while referencing a nuget package and later on using the remove option to delete it from my project. I had to clear the bin folder after battling with the issue for hours. To avoid this its advisable to use nuget to uninstall unwanted packages rather than the usual delete

Two possible solutions:

1. You are compiling in Release mode but deploying an older compiled version from your Debug directory (or vise versa).
2. You don't have the correct version of the .NET Framework installed in your test environment.