I have to use a DLL as an API in my application (C#, .NET 4.5). I can reference the DLL normaly. No error at all. But if I want to use any class of this DLL, I get the following compile error:
Error CS1705 Assembly 'Assembly_X' with identity 'Assembly_X,
Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d00'
uses 'Assembly_YY, Version=65535.65535.65535.65535, Culture=neutral,
PublicKeyToken=c878e80841e75d00' which has a higher version than
referenced assembly 'Assembly_YY' with identity 'Assembly_YY,
Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d00'
Then i checked the DLL (Assembly_X) in ILSpy. The Assembly_X has two references to Assembly_YY: One with the version 12.3.0.0 and one with the version 65535.65535.65535.65535.
I tried the "bindingRedirect" in the App.config. But since the error occures during compile time this doesn't help.
I don't have the source code of Assembly_X or Assembly_YY.
How can I use this DLL or repair it?
UPDATE
The developers of the dll finally answered my call for help. The only work around they know of is to use Visual Studio 2013 instead of Visual Studio 2015 or 2017. It seems VS 2013 is not bothered by these double reference at all.
They write, that the error is created by a encrypting tool for the dll.
Thank you all for your ideas and help.
It looks like the first DLL is referencing a library which is a higher version than the other DLL you are using.
so you have 3 DLL's to consider: A, B & Bv2
Your project is referencing A & B
But A references Bv2 (an updated version of B)
SO when you go to use functions of A it throws an error because it finds B instead of Bv2.
The problem basically that you are referencing 'Assembly_X' which references assemblies 'Assembly_YY' versions 12.3.0.0 and 65535.65535.65535.65535 and you referenced only 'Assembly_YY' version 12.3.0.0 in your application and didn't reference 65535.65535.65535.65535
Now according to the problem explanation on Microsoft Docs, and your example which you don't have the source code for the assemblies you have to:
Add a reference to 'Assembly_YY' version 65535.65535.65535.65535 of the DLL to your application to make it compile and to enable the application to run, you can provide an application configuration file that includes a <dependentAssembly> element that uses <assemblyIdentity> and <codeBase> child elements to specify the location of version 12.3.0.0 of the DLL.
You are referencing a higher version of DLL then the one you currently have.
You will need to add the reference to the higher version assembly:
'Assembly_YY, Version=65535.65535.65535.65535, Culture=neutral, PublicKeyToken=c878e80841e75d00'
in order to solve this.
Right now you are referencing
'Assembly_X' with identity 'Assembly_X, Version=12.3.0.0, Culture=neutral, PublicKeyToken=c878e80841e75d0
If this is a downloadable library, search for it in the nuget package manager and download it.
If it's a library written by you, obtain the latest version of the library and add it to your project.
Related
When building an instance of Sitefinity 9.2 using visual studio 2013 I get a DLL conflict error.
There was a conflict between "Telerik.Windows.Documents.Core, Version=2015.1.225.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7" and "Telerik.Windows.Documents.Core, Version=2016.2.421.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7". (TaskId:7)
The DLL that is causing the issue is their own DLL
References which depend on "Telerik.Windows.Documents.Core, Version=2016.2.421.40, Culture=neutral, PublicKeyToken=5803cfa389c90ce7" []. C:...\bin\Telerik.Web.UI.dll (TaskId:7)
Project file item includes which caused reference "C:...\bin\Telerik.Web.UI.dll". (TaskId:7)
The included DLL for Telerik.Windows.Documents.Core is the older version 2015.1.225.40 and not the newer 2016.2.421.40 version.
Is there a way to resolve this in the web.config (like a binding redirect) or some other method? Being that it is a vendor application should they provide the correct DLL version?
I would check your references on the SitefinityWebApp project. In some cases I found that you have to delete the reference and then re-add it back. Also, if you have other projects part of your solution you will need to check those projects for references to that assembly.
Also, something to look into, Sitefinity will allow you to use NuGet packages to manage the assemblies and project references in your solution. You can see more details about this at the following link...
http://docs.sitefinity.com/upgrade-a-project-that-has-nuget-packages
Hope this helps.
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!
I am building a DLL in C# that references another DLL. I don't want the DLL that I am building to care about which version of the referenced DLL is on the customer's computer at runtime (note: I do not ship the referenced DLL to them, only the one that I build). It turns out that they have a newer version of the referenced DLL on their machine and when they tried to execute the code in my DLL they got the following error:
Exception calling ".ctor" with "0" argument(s): "Could not loadfile or assembly ', Version=, Culture=neutral
In case it helps to know, the Specific Version property on the referenced DLL is set to False in my Visual Studio. How can I build my DLLs so that it won't complain about the version of the referenced DLL that the customer has deployed on their machine?
When you build an assembly the dll version of referenced assembly is written into your assembly. Generally, and without any configuration, it will have no troubles if you replace originally referenced assembly with the one of higher version, where only first 3 numbers matter. 1.1.1.x - x doesn't matter. And as long as "replacement assembly" contains API that your code may call. It seems that you have exactly that issue - a different constructor in the version you using that wasn't present in original assembly.
For making your assembly work with various versions of referenced dlls you can try to tweak app.config to set version range for this dll. Read about redirecting assembly version.
I have a client program written in C# where one of the projects in the solution handles a case which the machine has SQL 2005 installed.
I have added the relevant DLLs, but I get that warning:
CA0060 : The indirectly-referenced assembly 'Microsoft.SqlServer.ManagedDTS, Version=9.0.242.0, Culture=neutral, PublicKeyToken=89845dcd8080cc91' could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. This assembly was referenced by: d:\Any CPU\Bin\Debug\MyProgram.SSIS2005.dll.
According to properties of Microsoft.SqlServer.ManagedDTS it's version is 9.0.3042.0, I don't understand why it requires the version 9.0.242.0.
I don't know if it related, but the version of Microsoft.SQLServer.DTSRuntimeWrap is 9.0.242.0.
What have I tried?
Deleting and adding the reference
Changing manually the version required in the csproj file
I thought about getting all dlls with the same version, but didn't find such a source at the web.
Any Ideas? Thanks, KM
EDIT:
Another details,
My target framework is .Net 4.0
I have set the 'useLegacyV2RuntimeActivationPolicy’ to true
Try to add the reference from:
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS
And set the Local Copy for the reference in VS to true, hope this helps.
As far as I know SQL CLR is not currently compatible with .NET 4.0, you should try switching to 3.5 and see is that helps.
Check for the version of the system by going to:
C:\Windows\assembly\GAC_MSIL\Microsoft.SqlServer.ManagedDTS
If they are different then click on Add reference and follow the link to add the same.
Also in web.config, under the assemblies tag remove the one with the older version.
As #Mightymuke mentioned in the comments, Fuslogvw.exe shows which DLLs were loaded. One of my projects had a reference to DLL that referenced an old version of Microsoft.SqlServer.ManagedDTS.
I am using Umbraco (a .NET CMS), and it has a reference to a specific version of a DLL (see 1 Umbraco Reference below). This is fine until I try to hook into the .NET MailChimp API which references a different vesion of the same DLL (see 2 PerceptiveMCAPI below).
I can think of a couple of options for resolving this
a. Get either the Umbraco or PerceptiveMCAPI source and reference the same version of the DLL, really do not want to do this for compatibility reasons
b. Dump the 2 DLLs in the GAC, I want to avoid this as I see deployment issues arising if someone forgets (I know we should have an automated deployment but time is restricted)
I remember that there is a third option to specify what version of the DLL to use in the configuration. Is this possible and what is the code for it?
1 Umbraco Reference
// Assembly Reference CookComputing.XmlRpcV2
Version: 2.4.0.0
Name: CookComputing.XmlRpcV2, Version=2.4.0.0, Culture=neutral, PublicKeyToken=a7d6e17aa302004d
2 PerceptiveMCAPI
// Assembly PerceptiveMCAPI, Version 1.2.4.3
Location: C:\Work\AEGPL\AEGPL_Website\bin\PerceptiveMCAPI.dll
Name: PerceptiveMCAPI, Version=1.2.4.3, Culture=neutral, PublicKeyToken=null
Type: Library
This is exactly the reason the GAC exists. The only other workaround I can think of is to stuff these DLLs in subdirectories so the CLR cannot find them and implement AppDomain.AssemblyResolve. You now get to maintain that code for every new version update.