Error CS1705: "which has a higher version than referenced assembly"

Question

I've been looking into this for a bit now and haven't gotten it resolved. I get the following error message:

Compiler Error Message: CS1705: Assembly 'My.Model, Version=1.1.4422.23773, Culture=neutral, 
PublicKeyToken=bfde95ba233094b2' uses 
'Common, Version=3.3.4273.24368, Culture=neutral, PublicKeyToken=bfde95ba233094b2' 
which has a higher version than referenced assembly
'Common, Version=3.3.4269.17112, Culture=neutral, PublicKeyToken=bfde95ba233094b2'

c:\WINDOWS\assembly\GAC_MSIL\Common\3.3.4269.17112__bfde95ba233094b2\Common.dll: 
(Location of symbol related to previous error)

The web server is running Server 2003. I went to c:\windows\assembly and did in fact notice that there were 3 versions of Common.dll listed. The highest version listed was 3.3.4269.17112

I copied the dll with version: 3.3.4273.24368 into the assembly directory. I then re-compiled and re-deployed my code (probably overkill but oh well). When I opened my browser in a new session and went to the site URL again I still got the same message.

I can use windows explorer and verify the higher-versioned Common.dll is now listed as well.

What more can I look into to resolve this issue? I don't want to change the reference in my assembly to point to the older version.

Crazy `*.*` version numbers. Rebuild everything, only way to be sure. — Hans Passant, Feb 10 '12 at 01:30

Nicolas Raoul · Answer 1 · 2019-07-18T08:48:15.607

90

I had this error because "Rebuild" was not really rebuilding.

Solution: Close Visual Studio, really go and delete the bin folder, then rebuild, it might work better.

Also, sometimes Visual Studio lies about references, so check the HintPathin your .csproj files.

edited Jul 18 '19 at 08:48

answered Feb 12 '13 at 06:35

Nicolas Raoul

58,567
58
222
373

3

This one saved my bacon. Running local was fine, but I published a change and things went wacky. Deleting the contents of the online bin folder forced things to get back in sync. Thanks! – pStan Feb 26 '14 at 03:16

score 49 · Answer 2 · edited Feb 10 '17 at 20:41

49

If you're using NuGet it is worth going to 'Manage NuGet Packages For Solution', finding the package which is causing issues and hitting update. It should then bring all of the packages up to the latest version and resolve the problem.

Worth a shot as it's a quick and easy.

edited Feb 10 '17 at 20:41

Jess

23,901
21
124
145

answered Mar 13 '14 at 15:45

CountZero

6,171
3
46
59

2

This solved it for me, thanks. My situation was slightly different though: It wasn't listed in updates so I had to go to installed and there was a window which showed the package version per project. I was upgrading some old modules to a new version of a cms so I had to go to the problem packages, select them and click install. Could have been because the cms had just changed over to use nuget but you saved me a lot of tedious `csproj` editing! – rtpHarry Apr 21 '16 at 16:06
3

Make sure to update NuGet packages at the solution level instead of the project level. – Jess Feb 10 '17 at 20:42
3

This certainly should be the accepted answer by all means, I did not read this but tried in my solution unintentionally, which worked like a charm. – Amitya Narayan Mar 22 '17 at 16:42
Yes, if you are allowed to update. But this is not always the answer. I am in a project where updating would cause issues (can't use durable functions with latest .NET because configuration abstractions from Microsoft breaks there) - so I had a situation where I needed to **downgrade** until Microsoft gets configuration abstractions fixed! Downgrade EF core from 5.x to 3.x! And then it is not just one click because VS projects "remember" that you were on a newer version and spits out errors! – Matt Oct 11 '21 at 12:47

score 44 · Accepted Answer · edited Apr 09 '18 at 17:09

44

3 ideas for you to try:

Make sure that all your dlls are compiled against the same version of Common.
Check that you have project references in your solution instead of file references.
Use binding redirections in your web.config. (Originally linked version at wayback machine)

edited Apr 09 '18 at 17:09

nitzel

1,565
14
14

answered Feb 09 '12 at 22:59

Jakub Konecki

45,581
7
87
126

Still available at [wayback machine](https://web.archive.org/web/20120215231700/http://msdn.microsoft.com/en-us/library/433ysdt1(v=vs.80).aspx) and [microsoft](https://learn.microsoft.com/en-us/dotnet/framework/deployment/configuring-assembly-binding-redirection) – nitzel Apr 09 '18 at 15:04

score 34 · Answer 4 · answered May 22 '13 at 04:31

34

My problem was that I had 2 projects referencing 2 different copies of the same dll which had different versions. I fixed it by removing them both and making sure they were referencing the same dll file.

answered May 22 '13 at 04:31

Andrew Ngo

752
8
16

score 14 · Answer 5 · answered Oct 09 '13 at 18:10

One possible cause is that the second assembly is installed in GAC while the first assembly, with a higher version number, is added to the References of the project. To verify this, double click the assembly in the project references, and check if there is another assembly with the same name in the Object Browser.

If that is the case, use the gacutil.exe utility to uninstall the second assembly from the GAC. For example, if these are 64-bit assemblies:

C:\Program Files\Microsoft SDKs\Windows\v6.0A\Bin\x64\gacutil.exe -u <assembly_name>

Two years later and your suggestion worked like a charm. Viewing the references in the Object Browser sorted it. — ceebreenk, Oct 13 '14 at 19:59

score 7 · Answer 6 · answered Oct 28 '21 at 10:43

Something similar happened to me on Visual Studio 2019 after updating some Entity Framework NuGet Packages. Perhaps someone might stumble upon this problem related to Entity Framework or some other NuGet Package.

In my case, a project dependency was referring to a higher version of a Nuget Package than the dependent project (that contains the reference).

For some reason, on the .csproj file, the PackageReference entry for Microsoft.EntityFrameworkCore.Tools included the tag PrivateAssets. That means, looking at the documentation:

These assets will be consumed but won't flow to the parent project

The desired behavior in my case is for the parent project to include the dependent project and also its dependencies, because this reduces the duplication of NuGet Packages between related projects.

Therefore, changing the .csproj file of the child project from:

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11">
  <PrivateAssets>all</PrivateAssets>
  <IncludeAssets>runtime; build; native; contentfiles; analyzers; buildtransitive</IncludeAssets>
</PackageReference>

To:

<PackageReference Include="Microsoft.EntityFrameworkCore.Tools" Version="5.0.11" />

And rebuilding, solved the issue.

This was it! After searching around for so long, couldn't believe this was the fix. Thanks! — Pranav Jituri, May 01 '23 at 02:00

score 4 · Answer 7 · answered Nov 07 '19 at 11:53

4

The issue is seen if the nuget packages vary in multiple projects within the solution.

You can fix this by updating nuget packages to a common version with all of the PROJECTS in the SOLUTION

answered Nov 07 '19 at 11:53

Krishna Prasad S

141
2
17

make sure and look at project file in error message and it will tell you which one is off par – JMIII Jan 22 '21 at 16:36

score 3 · Answer 8 · edited May 01 '13 at 16:44

3

Go to Reference and add a new reference of your dll file which is causing the problem and make sure that all your dlls are compiled against the same version. It works for me I hope it works for you also.

edited May 01 '13 at 16:44

Nate-Wilkins

5,364
4
46
61

answered Mar 19 '13 at 04:46

Rahul

5,603
6
34
57

score 3 · Answer 9 · answered Jul 29 '13 at 18:49

My team just ran into this problem within our build environment. The issue was due to a difference in the <HintPath> element of the .csproj file.

Our common assembly had a correct relative path to the directory containing our reference assemblies. The dependent assembly had a path from a former directory structure. The solution successfully compiled on dev machines as the GAC resolved the dependent's reference to the correct version installed in C:\Program Files. The build environment had a legacy install of the assembly (even though it should have had none) that it fell back to and thus the error. Updating the <HintPath> in a text editor corrected the problem.

score 2 · Answer 10 · answered Feb 04 '19 at 08:08

2

I had same error. I fixed the error after installing Microsoft.AspNetCore.ALL into test project.

answered Feb 04 '19 at 08:08

Haktan Enes Biçer

612
1
10
13

score 2 · Answer 11 · answered Feb 14 '20 at 08:22

2

In my scenario, I edited the .csproj file for my dotnetCore app. I noticed that the TargetFramework tag had a value of netcoreapp2.1 and the RuntimeFrameworkVersion tag a value of 2.0.0. So I changed the RuntimeFrameworkVersion to 2.1.0, saved, restarted VS and rebuilt and then it resolved the errors.

Hope this will help you ...

Good Luck,

Sugeshan

answered Feb 14 '20 at 08:22

Sugeshan Govindsamy

61
1
4

If you have had pasted the csproj tag, that would have been helpful. – Deepak paramesh Jun 13 '23 at 15:32

score 2 · Answer 12 · answered Mar 10 '21 at 08:39

2

I deleted bin and obj folders manually, rebuilt, and it worked

answered Mar 10 '21 at 08:39

Lior Balmas

36
5

score 1 · Answer 13 · answered Apr 02 '14 at 10:31

Had a similar problem. My issue was that I had several projects within the same solution that each were referencing a specific version of a DLL but different versions. The solution was to set 'Specific Version' to false in the all of the properties of all of the references.

score 1 · Answer 14 · answered May 18 '15 at 11:28

I know this was asked quite a while ago, after trying out some of the above steps. What helped me were the following steps and this article.

I located the reference and changed the PublicKeyToken from the one being referenced to the older one.

I hope this helps too.

score 1 · Answer 15 · answered Jan 02 '23 at 09:50

1

download the latest .NET SDK from : https://dotnet.microsoft.com/en-us/download/visual-studio-sdks?cid=getdotnetsdk

answered Jan 02 '23 at 09:50

Tamer Ghoneim

11
2

While this link may answer the question, it is better to include the essential parts of the answer here and provide the link for reference. Link-only answers can become invalid if the linked page changes. - [From Review](/review/late-answers/33540407) – JamesG Jan 04 '23 at 14:18
the solution is to update the .NET SDK , as the version of the library is targeting a new version from the SDK than the developer uses, so the solution is updating the SDK to the latest. – Tamer Ghoneim Jan 09 '23 at 09:17

score 0 · Answer 16 · answered Feb 02 '17 at 11:56

Handmade dll's collection folder
If you solution has a garbage folder for dll-files from different libraries
lib, source, libs, etc.
You can get this trouble if you'll open your solution (for a firs time) in Visual Studio. And your dll's collecting folder is missed for somehow or a concrete dll-file is missed.

Visual Studio will try silently to substitute dll's reference for something on its own. If VS will succeed then a new reference will be persistent for your local solution. Not for other clones/checkouts.

I.e. your <HintPath> will be ignored and you project file (.csproj) will not be changed.
As an example of me

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
  <SpecificVersion>False</SpecificVersion>
  <HintPath>..\..\..\lib\DocumentFormat.OpenXml.dll</HintPath>
</Reference>

The DocumentFormat.OpenXml will be referenced from C:\Program Files (x86)\Open XML SDK\V2.5\lib not from a solution\..\lib folder.

fast Workaround

check and restore you dll's collecting folder
from Solution Explorer do Unload Project, then Reload Project.

right Workaround is to migrate to NuGet package manager.

score 0 · Answer 17 · answered Aug 28 '17 at 12:23

0

for SharePoint, make sure that under your root folder you don't have a "bin" folder with your DLL's, if so just delete it. (and change "Copy Local" to false in VS).

answered Aug 28 '17 at 12:23

bresleveloper

5,940
3
33
47

score 0 · Answer 18 · answered Jun 13 '18 at 03:04

The references in a website project are stored in its web.config file. Update the reference there to fix the error.

I spent some time looking at all the references in my solution before realizing that I had forgotten about the references in the web.config file.

score 0 · Answer 19 · answered Jul 27 '18 at 01:41

I had the same issue with UnitTestingProject, where in the MainProject I was using "System.Web.Mvc, Version=3.0.0.0" and in UnitTestingProject I was using "System.Web.Mvc, Version=3.0.0.1"

Change the following in the <Reference Include="System.Web.Mvc, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL"> <HintPath>..\packages\Microsoft.AspNet.Mvc.3.0.50813.1\lib\net40\System.Web.Mvc.dll</HintPath> </Reference>

score 0 · Answer 20 · answered Nov 19 '19 at 16:16

I got this after adding Episerver Find to our site and installing the corresponding NuGet package for Episerver Find.

The fix was easy: update all Episerver related add-ons as well (even if they seem unrelated: CMS, CMS.TinyMCE, CMS.UI, etc.)

After updating all possible Episerver add-ons and recompiling, the error went away.

score 0 · Answer 21 · answered Jul 08 '22 at 08:58

For Me one of custom nuget package used in project was using the higher version of Newtonsoft.Json and project was using the lower version of Newtonsoft.Json. Updating project Newtonsoft.Json nugetPackage >= Newtonsoft.Json nugetPackage used in custom package used.

score 0 · Answer 22 · answered Nov 04 '22 at 14:47

0

In my case, this was because I thought one of the projects had all the Nuget's updated, but one of them not

answered Nov 04 '22 at 14:47

Andrés Fernández Guerrero

31
3

This does not provide an answer to the question. Once you have sufficient [reputation](https://stackoverflow.com/help/whats-reputation) you will be able to [comment on any post](https://stackoverflow.com/help/privileges/comment); instead, [provide answers that don't require clarification from the asker](https://meta.stackexchange.com/questions/214173/why-do-i-need-50-reputation-to-comment-what-can-i-do-instead). - [From Review](/review/late-answers/33106275) – Rohit Gupta Nov 10 '22 at 10:38

score -1 · Answer 23 · edited Apr 13 '18 at 08:24

In your project find references System.Web.Mvc check the version.

After that right click references -> assemblies and search system.web.mvc and setup it.

The problem causes the different versions of these assemblies.

Edit : Than select manage NuGet packages and install the updates (if you have multiple projects install updates to them also.)

Important update is Microsoft.AspNet.Mvc and Microsoft.Net.Compilers don't forget it!

score -1 · Answer 24 · answered May 19 '18 at 05:42

-1

In our team we were working on different computers with git. Someone updated a dll and I didn't had it. I just updated my dependencies references and the problem solved.

answered May 19 '18 at 05:42

Masoud Darvishian

3,754
4
33
41

score -4 · Answer 25 · edited Aug 22 '16 at 19:07

-4

I had a similar problem, I had created a DLL, i.e., A.dll, which referenced other DLL, i.e., B.dll.

I created an application C.exe and referenced DLLs A.dll and B.dll.

Solution - On removing the reference of B.dll from c.exe I was able to fix the issue.

Hope this helps.

edited Aug 22 '16 at 19:07

elixenide

44,308
16
74
100

answered Sep 12 '13 at 18:39

Yahya

45
1

Error CS1705: "which has a higher version than referenced assembly"

25 Answers25

Linked