Could not load file or assembly ‘Aspose.Cells, Version=19.7.0.0, Culture=neutral, PublicKeyToken=716fcc553a201e56’ or one of its dependencies. The located assembly’s manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I am getting above in .Net Standard 2.0 type library. I have added Aspose.Cell nuget package reference to the library.
I think you need to add Aspose.Cells, Version=19.7.0.0 reference in hosting project also instead of only class library projects.
You may please add System.Drawing.Common library from the NuGet package manager to resolve the issue. In some cases you may also require System.Text.Encoding. Please note, while using NuGet package manager, it may automatically fetch all the required dependencies for Aspose.Cells, it look to me not in your case though. So, you should manually install System.Drawing.common v4.5.1 after installing Aspose.Cells 19.7.0.
To check the dependencies on Nuget repos page of Aspose.Cells v19.7.0, you may click on "Dependencies" node and may confirm the following depenencies for .NET Standard 2.0:
System.Drawing.Common (>= 4.5.1)
System.Text.Encoding.CodePages (>= 4.4.0)
Hope, this helps.
PS. I am working as Support developer/ Evangelist at Aspose.
Related
I have a C# project (ProjectX) that I am trying to upgrade from using .NET Standard 2.0 framework to .NET 6.0. The upgrade seemingly goes smoothly and we package it into a nuget using GitLab. Now when I reference the updated package from another project (already upgraded to .NET 6.0) I get the following warning:
Warning CS8032 An instance of analyzer {class inheriting from Microsoft.CodeAnalysis.Diagnostics.DiagnosticAnalyzer} cannot be created from ProjectX.dll: Could not load file or assembly 'System.Collections.Immutable, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The system cannot find the file specified..
Everything I've read suggests that this is likely caused when the sdk isn't on the same version as the source generator but as far as I can tell, this not the case.
I've tried adding the Systems.Collections.Immutable package directly to ProjectX also with no luck.
I Fixed this bij downgrading 2 nugate packages in my code analyzer:
Microsoft.CodeAnalysis.CSharp to 3.8.0
icrosoft.CodeAnalysis.CSharp.Workspaces to 3.8.0
Adding EF Core to a NET Standard project introduces transitive dependency versions incompatible with NuGet packages in other projects
I have a solution with multiple .NET Standard 2.0 projects.
One Project A uses the Google.Protobuf (3.11.2) NuGet package, that depends on
System.Memory (4.5.3)
System.Buffers (4.4.0)
System.Numerics.Vectors (4.4.0)
System.Runtime.CompilerServices.Unsafe (4.5.2)
A few other projects also depend on System.Memory and all use the same dependency versions.
Another Project B uses Microsoft.EntityFrameworkCore (3.1.0) NuGet package that depends on
System.Memory (4.5.3)
System.Buffers (4.5.0)
System.Numerics.Vectors (4.5.0)
System.Runtime.CompilerServices.Unsafe (4.7.0)
Even though the System.Memory version is (4.5.3) in both cases, it depends on System.Buffers, System.Numerics.Vectors and System.Runtime.CompilerServices.Unsafe and their versions differ.
When I run the application that uses these projects (a Microsoft Prism WPF .NET Framework 4.8 app that uses Unity IoC) UnityContainer throws the following exception:
System.IO.FileLoadException: 'Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
After searching for a solution I added this to my NuGet.Config:
<config>
<add key="DependencyVersion" value="Highest" />
</config>
In both, %appdata%\Nuget and in the root folder of the .sln file.
I also deleted the %userprofile%\.nuget\packages folder.
Then I removed the NuGet packages from the projects and added them back again, but their dependecies come with the same versions as before.
If I navigate to "Manage NuGet Packages for Solution..." in Visual Studio and choose "Consolidate" it just says "No packages found"
I managed to reproduce the problem.
I created two new .net standard 2.0 project class libraries.
On the first I added EF Core.
On the second I added Google protobuf.
Both same versions as you mention.
For EF core I created a new class that just inherits from DbContext.
For Protobuf I just created an empty class as I am not familiar on how to use it.
I was still able to replicate the problem though.
Then I created a console app .net framework 4.7.2 referencing the above two projects.
I instantiated the two classes in the Console App and got error System.IO.FileLoadException: 'Could not load file or assembly...
How I resolved it
I went to all three projects and added this line to the csproj.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
to the Property Group.
<PropertyGroup>
<TargetFramework>netstandard2.0</TargetFramework>
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
</PropertyGroup>
After that I built and ran again and no error appeared.
Please let me know your results.
Even if my solution does not work for you, I believe it is good practice to have it.
To quote Oren.
"Using .NET Standard requires you to use PackageReference to eliminate the pain of “lots of packages” as well as properly handle transitive dependencies. While you may be able to use .NET Standard without PackageReference, I wouldn’t recommend it."
Also Hanselman mentions:
"The "full" Framework projects are using the older .csproj format and by default, they use package.config to manage dependencies. The newer projects can reference Packages as first-class references. So we need to tell ALL projects in this solution to manage and restore their packages as "PackageReferences.""
Here are my sources.
https://www.hanselman.com/blog/ReferencingNETStandardAssembliesFromBothNETCoreAndNETFramework.aspx
https://oren.codes/2017/04/23/using-xamarin-forms-with-net-standard-vs-2017-edition/
Updated according to Sommen's extra info from the github issues
Kudos to Sommen for providing this extra info. Also Kudos to Immo Landwerth for providing this Info at GitHub.
I will provide as is the Workarounds that already exist in the Github page just for complecity as advised by the OP jinjinov.
Taken from GitHub Issues
Workarounds
Regular .NET Framework projects
Enable automatic binding redirects in the root .NET Framework application
Make sure your root application project doesn't use packages.config but uses PackageReference for NuGet packages:
If you currently don't have packages.config, simply add
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>.
If you currently do have a packages.config, convert the contents to package references in the project file. The syntax is like this:
<PackageReference Include="package-id" Version="package-version" />
ASP.NET web applications and web sites
Web applications and web sites don't support automatic binding redirect generation. In order to resolve binding conflicts, you need to double click the warning in the error list and Visual Studio will add them to your web.config file
In web application projects, you should enable PackageReference like mentioned above. In web sites, you cannot use PackageReference as there is no project file. In that case, you need to install all NuGet packages into your web site that any of the direct or indirect project references depend on.
Unit test projects
By default, binding redirects aren't added to class library projects. This is problematic for unit testing projects as they are essentially like apps. So in addition to what's outlined in automatic binding redirects you also need to specify GenerateBindingRedirectsOutputType:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
There is also a discussion section that provides more information -> GitHub discussion
Yeah, welcome to the struggle.
Like PanosKarajohn pointed out using packagereference instead of packages.config helps with this. Unfortunately, that is Vs2017 and up and for some of us that is not yet in sight.
The problem is actually explained pretty much here:
https://github.com/dotnet/announcements/issues/31
You need to use binding redirects to redirect all the version numbers to the highest on you got and then pray that everything plays nice with each other.
I use the Microsoft.aspnetcore.signalR package in a .net 4.6.1 project and you have the same issues.
I have a .NET standard library which I would like to use in a .Net 4.6.2 project. The .Net standard library was installed via nuget. At runtime, I get the following error:
System.Runtime Version 4.1.0.0 not found
I read somewhere that you have to install the nuget package "NetStandard.Library" in this case. I did that but unfortunately it did not help.
Any ideas?
Solution was to add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> to the StartUp project file (not the project file where the external library is used). Now it works :) Thanks.
Nuget package "NetStandard.Library" is still needed (in project file where the external library is used).
Solution below
I'm trying to implement PayPal payment in an ASP.NET website, but when I run it on Azure, it tells me the assembly being referred to by RestApiSDK 0.1.1.0 is wrong. Local it all works.
Could not load file or assembly 'PayPalCoreSDK, Version=1.5.2.0, Culture=neutral, PublicKeyToken=5b4afc1ccaef40fb' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I checked with .NET Reflector and the assembly being referred to is indeed 1.5.2.0, though the latest version in NuGet Packages is 1.6.0.0. I also uninstalled both packages and re-installed them, but no luck.
So, I have two questions:
Why does this work on my localhost?
How do I fix this to work on Azure Websites as well?
Edit: As #JasonZ suggested, I installed a new version of the PayPal SDK for .NET and that worked. Thanks!
My first thought would be 32 bit local machine vs 64 bit azure?
If that's not the case, I would try manually adding them to the GAC via a webjob as stated here:
http://blogs.infosupport.com/adding-assemblies-to-the-gac-in-windows-azure/
When you "uninstall and Reinstall" do you see them in the GAC on your azure vm?
=Devon
Answer by #JasonZ: The PayPal .NET SDK has since replaced the RestApiSDK library and removes the dependency on PayPalCoreSDK.
Upgrade the nuget package
PM> install-package PayPalCoreSDK -version 1.7.0
(To upgrade the package using visual studio [Top Menu] -> Tools -> NuGet Package Manager -> Package Manager Console)
Please follow the following link for more information. https://www.nuget.org/packages/PayPalCoreSDK/
Have a serious problem: need to install a third-party web application. After deploying to my local machine getting the exception:
Could not load file or assembly 'System.Data.Entity, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
The problem is i don't have sources, also nuget packadge manager cannot find anything similar to this version. Installation of Entity Framework ver. 4.2.0 does nothing either.
Any thoughts what and where I should download?
Best regards and thanks a log
You find nothing on nuget? HAve you ever tried?
Google.... "Entity Framework 4.2" leads me to...
https://www.nuget.org/packages/EntityFramework/4.2.0
That is nuget, that is Entity framework and that is 4.2.
Maybe, instead of nuget package manager, you use the nuget tools ;)
Download old version of package with nuget
tells you how to do that - using the command line (which accepts a version parameter).
You should try to install this manually:
Open the solution
Open the Package Manager Console
Type: Install-Package EntityFramework -Version 4.2.0
This will install the specific package version that you need.
You either need :
a. the assembly referenced
b. the source code to change the reference
I would contact whoever wrote the third-party application and try to resolve it from there.