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

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.

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.

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.

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)

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.

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>

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

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.

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.

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

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

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

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.

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.

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.

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.

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).

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.

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>

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.

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!

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.

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.