149

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.

Improve this question
1
  • 2
    Crazy *.* version numbers. Rebuild everything, only way to be sure.
    – Hans Passant
    Commented Feb 10, 2012 at 1:30

26 Answers 26

Reset to default
94

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.

Improve this answer
1
  • 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
    Commented Feb 26, 2014 at 3:16
50

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.

Improve this answer
4
  • 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
    Commented Apr 21, 2016 at 16:06
  • 3
    Make sure to update NuGet packages at the solution level instead of the project level.
    – Jess
    Commented Feb 10, 2017 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
    Commented Mar 22, 2017 at 16:42
  • 1
    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
    Commented Oct 11, 2021 at 12:47
44

3 ideas for you to try:

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

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.

Improve this answer
14

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>
Improve this answer
1
  • Two years later and your suggestion worked like a charm. Viewing the references in the Object Browser sorted it.
    – ceebreenk
    Commented Oct 13, 2014 at 19:59
13

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.

Improve this answer
1
  • 1
    This was it! After searching around for so long, couldn't believe this was the fix. Thanks!
    – Pranav Jituri
    Commented May 1, 2023 at 2:00
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

Improve this answer
1
  • make sure and look at project file in error message and it will tell you which one is off par
    – JMIII
    Commented Jan 22, 2021 at 16:36
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.

Improve this answer
3

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.

Improve this answer
2

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

Improve this answer
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

Improve this answer
1
  • 1
    If you have had pasted the csproj tag, that would have been helpful.
    – Deepak paramesh
    Commented Jun 13, 2023 at 15:32
2

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

Improve this answer
1

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.

Improve this answer
1

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.

Improve this answer
1

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

Improve this answer
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
    – JamesG
    Commented Jan 4, 2023 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
    Commented Jan 9, 2023 at 9:17
0

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.

Improve this answer
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).

Improve this answer
0

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.

Improve this answer
0

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>

Improve this answer
0

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.

Improve this answer
0

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.

Improve this answer
0

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

Improve this answer
1
0

i give this error in my project

Assembly 'Microsoft.AspNetCore.OData' with identity 'Microsoft.AspNetCore.OData, Version=8.2.4.0, Culture=neutral, PublicKeyToken=31bf38 56ad364e35' uses 'Microsoft.AspNetCore.Mvc.Core, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' which has a higher version than referenc ed assembly 'Microsoft.AspNetCore.Mvc.Core' with identity 'Microsoft.AspNetCore.Mvc.Core, Version=2.2.5.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'

and i add below code into project file

<FrameworkReference Include="Microsoft.AspNetCore.App" /> or install Microsoft.AspNetCore.App from nuget

it work for me

Improve this answer
-1

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!

Improve this answer
-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.

Improve this answer
-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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.