We Keep Coding

Type Load error in System.IdentityModel.Tokens.Jwt

I am seeing a System.Reflection.ReflectionTypeLoadException at runTime:
Could not load type 'System.IdentityModel.Tokens.ISecurityTokenValidator'
from assembly 'System.IdentityModel.Tokens.Jwt, Version=5.0.0.127, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.":"System.IdentityModel.Tokens.ISecurityTokenValidator
I am using System.IdentityModel.Tokens.Jwt version 5.0.0.127 (nuget package 5.0.0)
I have tried using fuslog to look at the binding log. It finds the dll in my bin directory and the bind succeeds (and it is the correct dll). I've also verified that I don't have this library installed in the GAC.
I used visual studio's object browser and went looking through the dll. I found that JwtSecurityTokenHandler inherits from ISecurityTokenValidator. According to the object browser ISecurityTokenValidtor comes from Microsoft.IdentityModel.Tokens. (I am using nuget package 5.0.0 of that one also).
I manually went through the various nuget dependencies related to these two packages (as well as any others in my project that I thought had a chance of being relevant). Everything appears to check out.
Can anyone explain under what circumstances you would be unable to load a type from an assembly? And can anyone explain to me how to properly resolve the issue with this specific library?

In My case I removed the "Microsoft.IdentityModel.Protocol.Extensions" from my packages. and worked like a charm.

How to resolve? Assuming assembly reference 'System.Web.Mvc

With reference to questions/26393157/windows-update-caused-mvc3-and-mvc4-stop-working. The quickest way to resolve the warning below?
Assuming assembly reference 'System.Web.Mvc, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' matches
'System.Web.Mvc, Version=4.0.0.1, Culture=neutral,
PublicKeyToken=31bf3856ad364e35', you may need to supply runtime
policy.

I've had this happen with my NuGet packages every once in a while. I haven't been able to identify exactly how it happens. (I assume user error.)
I didn't need to upgrade anything to solve it, just clear the NuGet cache:
I use the nuget command line tool found here.
You can clear all caches with this command:
nuget locals all -clear
See: https://docs.nuget.org/consume/command-line-reference
You'll probably need to restart Visual Studio if it is open.

As per the best answer to the question....
Update MVC package (Visual Studio > Right click project/solution > manage nuget packages > Updates > Microsoft ASP.NET MVC > Update)
Manually add the compilation assembly
but then
Find - System.Web.Mvc, Version=4.0.0.0
and replace with - System.Web.Mvc, Version=4.0.0.1
Which will find all the hidden references in the Views/Web.config files.

Every time I have had this issue I always start by doing a rebuild which will clear your bin folder. You likely do not need to close and open visual studio, as I never have, and it should work.
If this doesn't work then try more complicated solutions like those above but this could be a quick, clean fix.

I was getting this warning in RoslynPad because one of the dll's I was referencing (for me it was mscorlib.dll) used a different version than the retrieved version via NuGet. As the warning states, you can solve it with solve it with a runtime policy with a link to the dll of the version you want to be using. Just add something like this to the top of your file:
#r "C:\Windows\Microsoft.NET\Framework64\v2.0.50727\mscorlib.dll"

Sorry for the late reply but in my case this warning was showing up because I was using different versions of Microsoft.AspNet.Mvc across my Visual Studio solution. I was able to get rid of it by upgrading the older packages to the same version.
Hope this helps someone.

What worked for me after trying severally is to update application insights and all packages from NuGet. Then I ensured that there were no version conflicts on the App insights and it worked fine.

Don't refer NuGet Package Components and interfaces directly from your cshtml code. Instead, write your own components, extesion methods and view models referencing them from plain C# code placed in cs files. First, then you wouldn't obtain CS1702 warning. And secondly, this will facilitate future migrations to newer versions of the NuGet package or even another package: All necessary fixes will be shown you by the compiler.
This is probably the desired change in your run-time policy.

After tested all propositions, I finally succeeded to get rid of the warning by editing the .csproj of my web application and set the property MvcBuildViews to false.
Maybe this could help some of you.

Cannot run my first program from http://facebooksdk.net/docs/windows/tutorial/ - FacebookSessionClient raising exception

I'm getting
Could not load file or assembly 'Facebook, Version=6.0.10.0,
Culture=neutral, PublicKeyToken=58cb4f2111d1e6de' or one of its
dependencies. The assembly version has a public key token that does
not match that of the request. (Exception from HRESULT: 0x80132001)
at line
facebookSessionClient = new FacebookSessionClient(myFacebookAppIdInString);
in App.xaml.cs
I was following tutorial at http://facebooksdk.net/docs/windows/tutorial/ I couldn't even run my first basic program.
My Complete Code at: http://dropbox.com/s/brh09szot8yd52x/Facebook_2.zip
How to solve this problem? I've tried re-installing facebook and facebook.client -pre packages.

I've been having the same issue and was at a bit of loss and found your question when trying to find an answer. It might not have been the same issue but the reason turned out to be my project was compiling a dll called Facebook.dll which was overwriting the SDK. You need to rename the assembly, right click the project - properties and change the "Assembly name". I had already renamed the project but forgot to rename the assembly. Oh well lesson learned.

I would recommend using Dependency Walker. http://www.dependencywalker.com/
Open up the .exe or .dll with it and it will list all of the .dll dependencies for your program. Any .dlls that are missing or in the wrong format will appear red or yellow.
If any appear red (or yellow), you will need to locate the .dlls and possible put them in the directory where you are executing your program or into a common place such as your Windows system folder. (Usually C:\Windows\System32)
Sometimes when this happens it can be resolved by installing packaged .dlls, such as the Visual C++ Redistributable Packages for Visual Studio 2013 . However, in your case it appears that your program require dlls for Windows RT, so there may be a package that you need to install or perhaps you are targeting a different platform than the one that you are running the program on.

Error: Reference to type claims it is defined, but it could not be found

I have a solution with 3 projects:
ParsersBase, that defines an interface IParseRule
ParsersLibrary, that has a reference to ParsersBase and defines a class HtmlImageUrlParseRule : IParseRule
ParsersLibraryTest, that has a reference to ParsersBase and ParsersLibrary and defines a test class with some test methods
When I'm trying to build it, I get a warning:
Reference to type 'AVSoft.ParsersBase.IParseRule' claims it is defined in 'c:\Users\Tim\Dropbox\projects\Image Downloader\ParsersLibrary\bin\Debug\ParsersLibrary.dll', but it could not be found
Why is VS trying to find AVSoft.ParsersBase.IParseRule in ParsersLibrary.dll? ParsersLibraryTest has a reference to ParsersBase; it just doesn't make any sense.

Another way this could happen is if you're using several NuGet packages where one, probably central, package has been updated but some additional functionality packages haven't been.
To work through my recent example - the error was "Reference to type 'ConsumerSubscriptionConfigurator<>' claims it is defined in 'MassTransit', but it could not be found". This is because we had updated MassTransit from 2 to 3, but we had not updated some of the other optional packages (MassTransit.log4net and MassTransit.Autofac) to the same version number. It appears as if assembly redirection had kept everything working until we tried to use one more additional feature.

This error seems to cover a variety of scenarios. In my case, closing and re-opening Visual Studio was the trick. After restarting Visual Studio, I was able to build the project as expected.

I had a similar problem. The site was running a cached version of the dll and not the one I had deployed to the bin directory. I cleared the temporary asp.net folder contents and this solved the issue.

It was my fault, I had a ParsersLibrary project at the start and then renamed it to ParsersBase, but I didn't rename an assembly name, then I added a ParsersLibrary project again.
So, two projects had the same assembly name and it's not very good, is it? :) Assemblies overlap each other, so I have this error.

I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. The problem was following: my solution had Target Framework = 3.5 and I added a reference to Microsoft.Practices.Prism v 4.0 which is built against the framework 4.0.
After changing target framework to 4.0 it worked

It looks like things are a bit easier now than they were before.
As other answer(s) have basically already stated, this error can result from an older version of the same NuGet package not having some of the newer types in it. While in production, this is generally managed through proper versioning, in development, you may end up reusing the same version number when making changes. And that's a likely place where this problem can arise.
To fix this, you can often just clear the cache by doing the following:
In Visual Studio, go to Tools > NuGet Package Manager > Package Manager Settings.
In the pop-up menu, navigate to NuGet Package Manager > General.
In the options on the right, click Clear All NuGet Cache(s).

I hit this exception today. The problem in my case was I had some.package v2.1installed in my host and some.package v2.3 installed in other projects. Update-Package on the host project to v2.3 fixed the issue.

I my case, I tried to test a WPF project with a .NET Core (3.1) test project which could not reference the needed WindowsBase.dll.

Updating/consolidating packages didn't help. Even a clean repo and a restart of Visual Studio didn't solve it for for me.
But rebooting did fix the problem!

#binki's comment helped me;
deleting all .vs, bin, and obj folders, and then reopening the project

ParsersLibraryTest needs to reference ParsersBase. The second part of the error should read "You must add a reference to assembly 'ParsersBase..."

I tried all of the above answers but none resolved my issue.
In the end, I checked in my latest code (GIT), then recloned the repository in a different location.
Not ideal, but at least problem solved.

I had the similar problem: Reference to type 'Func<>' claims it is defined in 'mscorlib', but it could not be found. I have a lib of .Net 4 that was referenced by a .Net 3.5 program. After upgrading both to 4.61 it worked.
Seems like Func<T> is missing in .Net 3.5 and just upgrading that sample app would have been enough.
Further exp: Someone had added a signature in the library project (.Net 4) that uses a Func<T> parameter. But the sample program (3.5) already existed and ran fine so far. But at time of recompilation a dependency of a dependency clashed. Because mscorelib-3.5 had been already loaded. All happens at compilation time.

The only way I could overcome this error was to force uninstall of all nuget packages related and then reinstalling them. Sad but true.

I've just struggled with this error for a while now and finally get around it.
This is how to re-produce it and how I fixed it.
The problem was:
The packages were referenced by Right clicked -> add refernece -> Browse (choose). Then were added again as NuGet packages.
The solution was:
Remove the added references.
Remove the installed packages from .csproj.
Re-install the required packages from NuGet package mangager.
Close Visual Studio and re-open it.
Clean Project.
Build Project.
Note: If you couldn't remove the referenced files (no Remove option on right click) try close Visual studio and re-open it. Or delete or move the dll that were referenced then try again.

For me, I had chosen incorrect project, I was creating a class library project, I had to chose "Class Library (.Net framework)" but I had chosen "Class Library (.Net standard)"
Replacing the same resolved the issue.

The problem was following: my solution had Target Framework = 3.1 and I added a reference to Microsoft.EntityFrameworkCore.SqlServer v 2.0 which is built against the framework .

I had this problem with one of my library projects inside of a solution, after I switched from .NET Framework to .NET Standard. Eventually I just removed the project reference and added it again inside the application project that was reporting the problem. Oddly enough, the only thing that changed was project GUID switching to lower case from the previous upper case.

getting a entity framework query to work on a production environment proving impossible to debug [duplicate]

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?

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

I solved this issue by setting the Copy Local attribute of my project's references to true.

One solution that worked for me was to delete the bin/ and obj/ folders and rebuild the solution.
Update:
Or you can try to right-click the Solution node in the "Solution Explorer" and click "Clean Solution", then click "Rebuild Solution" (thanks Emre Guldogan)

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

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!

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

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.

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.

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.

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.

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

Another solution to know why exactly nothing works (from Microsoft connect):
Add this code to the project:
foreach (var asm in AppDomain.CurrentDomain.GetAssemblies())
{
asm.GetTypes();
}
Turn off generation serialization assemblies.
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 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.

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

This worked for me. Add it in your web.config
<system.web>
<trust level="Full" />

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

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.

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.

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

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
Preferred way: Make sure you use the correct version of MyDll.dll
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
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.
If the above failed: You can uninstall the old MyDll.dll from GAC
How to Uninstall an Assembly from the GAC
Uninstall the application that includes MyDll.dll
Changing the AssemblyVersion was good enough for me. :)
I hope this was helpful.

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

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.

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

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.

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

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.