Could not load file or assembly 'PayPalCoreSDK' - c#

I have 2 webapp projects that work perfectly with this assembly.
I've tried everything, copy the BIN folder, delete, make a rebuild.
Search for things in the GAC, remove and add references again, with NUGET without NUGET, copy from the folder of projects that work.
My error was that on the first try I added the reference through the nuget manager rather than simply copying the DLLs from the projects that work
Now there is something causing version error.
System.IO.FileLoadException: Could not load file or assembly 'PayPalCoreSDK, Version = 1.7.0.0, Culture = neutral, PublicKeyToken = 5b4afc1ccaef40fb' or one of its dependencies. The localized assembly manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
How to clear this mess and fix those references?
Everything is the same as the other 2 projects that work, even code, even web.config.
I do not know where else to look for solutions.
PayPalMerchantSDK (2.16.204.0)
Dependencies: PayPalCoreSDK (1.7.1.0) - Newtonsoft.Json (9.0.0.0)

Did you check the .net framework version in same as your other 2 projects?

After many attempts I managed to make the project work.
However, I had to work with older versions of PayPalCoreSDK and Newtonsof.Json.
Now I will try to adjust the versions to see if I can align all the projects.
But the references are confusing and if it gives problem it seems that only NUGET can refresh DLLs properly
Manual settings in the BIN folder do not work much less in web.config.

I encounter this error as well. I was able to fix it by just downgrading the version of the PaypalCoreSDK to the previous one.

Related

Could not load file or assembly 'Azure.ResourceManager.ResourceGraph

Getting following error: Could not load file or assembly 'Azure.ResourceManager.ResourceGraph, Version=1.0.0.0, Culture=neutral, PublicKeyToken=92742159e12e44c8'. The system cannot find the file specified.
Have tried cleaning, removing and reinstalling the package, completely removing the .nuget folder, starting a new project and repulling the repo, eliminating all related code and references, various entries suggested on the InterWebz into the project file, but same error, over and over.
Something slightly suspicious: the package version on NuGet is 1.0.0 but the error references Version=1.0.0.0 (extra zero).
Note that the package works fine in a different solution.
Solved but in a flummoxing manner. The solution is a project that makes a DLL and a demo project that uses that DLL to illustrate how to use the DLL in practice. The Demo project does not call ResourceGraph at all, only the DLL does. But when I added the ResourceGraph to the Demo project, the error went away. That's not how it's supposed to work, right? Or am I misunderstanding how dependencies work. If a Project calls a DLL that has dependencies, does that Project also need to add the packages that the DLL uses? I have not referenced the ResourceGraph package with "using" in the Demo program, but adding the package still fixed it. Thoughts?

Dependency error (System.Net.Http) when using Azure deployment options - works when publishing in Visual Studio

I have a very weird situation I hope someone can help with!
I have a normal ASP.NET MVC website. I've set up "Deployment Options" to push to a domain on every Develop commit. However, this has started giving the dependency error:
Could not load file or assembly 'System.Net.Http' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
Now, I thought this was some caching since solution worked locally. So I have been publishing the app inside Visual Studio a couple of times (with option of deleting all remote files), and then the solution works.
However, after doing this, and I go back to a normal commit with Deployment Options, I go back to the same error:
From your description it seems like it has deployed successfully in past.
Have you upgraded project recently? If yes, look at this thread Strange issue with System.Net.Http 4.2.0.0 not found
Also, check if you are referencing DLL from NuGet and not GAC.
First thing that comes to mind is that you added a new DLL in your solution that depends on another version of System.Net.Http assembly. If you know that you added a new DLL, check for its assembly dependency.
Another solution might be to manually specify the version of the assembly in code. And select SpecificVersion. (but I'm guessing it's the first thing that causes the issue).
I have came across similar issue once. There should be a mismatch of the versions between System.Net.Http package.
Try verifying the version of System.Net.Http for the entire solution and refer the same version in all the projects.
This happens if a package is referenced in a project and different version of the same package is referenced in another project. Here, this error occurs when there is a reference between these two projects.

There was a conflict between "mscorlib, Version=4.0.0.0" and "mscorlib, Version=2.0.5.0" [duplicate]

On a new Win8.1 reinstall, with all of my code restored from backup, I'm suddenly now getting a Visual Studio warning when I build the main project of my solution:
Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
I set the Output log level to Detailed and I found a few entries like this:
There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it had a higher version.
Trouble is, I'm not referencing mscorlib anywhere in the solution—old or new. I have a couple of apps on my machine that require .NET 3.5, but I can't see how that could be related.
One difference: the old Win8.1 install on which this warning did NOT occur was a standalone machine; this time I'm domain-joined. I don't know whether that makes a difference (I can't see how), but I thought I ought to mention it at least.
Having different versions of a Nuget package on different projects may cause this problem as well. Make sure that all your packages have the same version:
(Within Visual Studio) Right click on the solution
Click on Manage Nuget packages for Solution
Click on the Consolidate tab
For every package in the Consolidate tab, update the package to the same version for every project.
I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.
BUT
Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!
I have been able to fix this issue by deleting my ".suo" file of my solution and then re-opening the solution. I then rebuild the solution and the issue is gone.
The ".suo" file is within the ".vs" folder which is what I usually delete.
Good luck!
I solved this by setting my verbosity to Diagnostic as per this answer.
Once I did that and rebuilt my solution, the build log actually listed the specific packages that depend on the two different versions of mscorlib.
In my particular case, my project had references to version 2.0.20126.16343 of System.Net.Http. I opened up the NuGet Package Manager and updated this package to the latest version (4.3.4 at the time). The next time I built my solution, the warnings were gone.
Well my solution is a little bit simpler than all of the above. I simply added a reference to the two Assemblies throwing this error (System.Runtime.Serialization and mscorlib) and rebuilt the project. By doing this, I specified the 4.0.0.0 version and removed the ambiguity.
One of the two (mscorlib) couldn't be added via the GUI because of the "A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system." error.
I needed to open the .vbproj (.csproj) file and add a reference manually via:
<Reference Include="mscorlib" />
I've tried all the following, but none has resolved the issue.
the command "update-package -reinstall".
Update and package via Consolidate tab.
Removing the ".suo" file.
However, My issue was a different case, I guess the new version of Xamarin.Forms package has used a different version of mscorlib. so I've downgraded it and it works fine.
I suggest you try all above solutions and also try to find which package is conflicting.
Following Memet Olsen's advice using VS2017 community...almost identical:
Right click Solution in Solution Explorer.
Select 'Manage Nuget Packages for Solution'
Check the packages. If any of them have a blue up-arrow rather than a green tick use the 'update' button
I also have tried all of the proposed solution to no avail.
In my project, this warning message was caused by a dll reference having a dependency on a different .net framework than the one that is targeted by my project.
In order to find out which dll reference was causing the warning, I simply used .net reflector to explore each dll reference to find out which one was referring a different .net framework (mscorlib).
In order to fix the issue, the reference dll has to be updated to a version which targets the same .net framework as the project using it, if such a version exist.
Hope this helps.

How to resolve "The located assembly's manifest definition does not match the assembly reference." error?

I downloaded source code for pdfiumviewer from git hub. I made changes to one of the projects in that solution.Then I added that project to my application and added reference of that project to one my application's project.I had to uncheck the Signing option for the PDfiumViewer project, as some of the dll in that project are unsigned.I am able to build the application successfully.But at run time when I create an object of one of the class of PDfiumviewer project.It gives me the following error:
Could not load file or assembly 'PdfiumViewer, Version=2.11.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
located assembly's manifest definition does not match the assembly
reference. (Exception from HRESULT: 0x80131040)
The version number of the assembly is correct.So, why am I getting this error?
The problem was that I had added reference of old unmodifed PdfiumViewer dll to another project.Hence, there was conflict between the two dlls (old and customized) at runtime.I removed the old dll reference and it worked.
Ive also encountered this issue, my scenario was thou that I had to add a reference from another solution into my project removing the reference was not an option - what worked for me was reinstall SQLclient from nuget package managerer on both solution. Hopes it helo someone else
The issue here is that you have a library that references v2.11.0.0 of the Pdfium library. This library could be an assembly that you built earlier, or another assembly that came from Pdfium that references this version of the library. When you built your version of the library you probably didn't use this same version number, and it wouldn't have been strong named correctly. To fix this, you can add an assembly binding redirect in your applications configuration file to redirect the offending library to your custom built one.
I wrote a program to fix this issue automatically: https://github.com/BackTrak/DependencyFixup/releases/tag/1.0.0.0
I know this question is old, but hopefully this helps out others!

Install-Package : Failed to add reference to 'System.Runtime'

I'm trying to install the Autofac nuget package in my project using the command
Install-Package -Prerelease Autofac
but it fails with the error
Install-Package : Failed to add reference to 'System.Runtime'. Please make sure that it is in the Global Assembly Cache.
I've tried re-installing .NET Framework 4.5.2 (which is the version my project targets) but got the message ".NET Framework 4.5.2 is already installed". However, searching C:\Windows\assembly\ for System.Runtime.dll doesn't find any exact matches (although there are a few instances of System.Runtime.ni.dll, which (seem to indicate) that they are really the same assembly...).
What can I do about this?
Update: apparently I was confused about the location of the GAC. Amy enlightened me, and searching in C:\Windows\Microsoft.NET\assembly instead I do find System.Runtime.dll. Why doesn't Visual Studio?
I had the same problem.
Found the solution here: https://github.com/aspnet/WebHooks/issues/18
To fix it, I added <Reference Include="System.Runtime"/> to the .csproj
file for the project, rebuilt it and it worked.
Please make sure that it is in the Global Assembly Cache.
That is an excessively unhelpful error message. It not only doesn't describe the real problem, it also leads you drastically astray to find a workaround. An assembly reference for a .NET Framework assembly must never come from the GAC. The kind of failure modes when it does can be exceedingly nasty to diagnose. Reference assemblies must come from the C:\Program Files (x86)\Reference Assemblies directory.
Looking at the .nuspec file for the Autofac nuget package you are trying to install, it supports two distinct targets. One is for DNXCore version 4.0.10-beta-22816. Hopefully you are not using it, that project is changing rapidly.
The other is .NET Portable, profile 259. Which allows your project to target .NET 4.5.x, Store, Phone80 and Phone81. What the blunt error message is telling you is that it has trouble finding that profile. Use Windows Explorer to have a look-see, the profile is stored in the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.5\Profile\Profile259 directory. It has the required System.Runtime.dll reference assembly.
Well, surely it awol, I can't guess at the underlying reason.
They did make subtle mistakes in the .nuspec file. Do consider a more stable release of Autofac, you probably don't want to be a beta tester. And don't target 4.5.2, there is no point to that. It doesn't add anything interesting and forcing your user to update his .NET install is not very reasonable.

Categories

Resources