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

Viewed 450003

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?

36 Answers

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.

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.

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

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.

If you're getting this error when referencing a .dll in PowerShell, and your .dll is .NET 5 (.NET Core, too?), then you should ensure you're executing the PowerShell script in PowerShell 6+ instead of Windows PowerShell 5.1 (or earlier version). That helped me in a specific scenario.

Related