The project currently contains references to more than one version

Question

We recently upgraded to VS2012 and .NET 4.5. Since switching to 2012, I constantly get these errors when debugging:

Compiler Error Message: BC32206: The project currently contains references to more than one version of NPGUtilities, a direct reference to version 2012.4.4751.24389 and an indirect reference (through 'AdminWeb.targetweights.sgModels') to version 2012.4.4751.24391. Change the direct reference to use version 2012.4.4751.24391 (or higher) of NPGUtilities.

BC32206: The project currently contains references to more than one version of EnterpriseData, a direct reference to version 2012.4.4751.25227 and an indirect reference (through 'SponsorWeb.selectplan.AdministratorXDataset1') to version 2012.4.4751.25243. Change the direct reference to use version 2012.4.4751.25243 (or higher) of EnterpriseData.

Both of those are project references. I have tried removing and readding them but still no luck. Can anyone offer any advice on how to resolve this issue?

Brandie

Does vs2012 give you the same options as in vs2010 to set the project version of .net..? perhaps you could roll back to version 3.5, 4.0 recompile the project the change the settings to 4.5 you probably have some versions of the assembly in the GAC that are not 4.5 compatible that's my best guess.. The error message tells you what to do basically.. it's a matter of you having to reference the proper / correct version now.. you may have to make some .config setting changes as well to show old versions goes to new version – Yellowish

Have you tried searching for the string "2012.4.4751.24389" in the entire solution and replacing it with "2012.4.4751.24391" and do the same with the the other assembly? – Hasa

Answer 1

I was able to fix this issue by removing all of the files in my bin folder and then rebuilding the project. For me the issue was that cleaning the project was only deleting DLLs in the bin\Debug folder while old DLLs were remaining in the bin\Release folder.

Stood

Shouldn't clean do that? – Aery

You'd think but for me it didn't. – Stood

Clean is the biggest mystery since we found fire. – Aery

Clean only cleans the currently-selected build configuration. – Torrance

@Aery Clean indeed did the job. – Jaymejaymee

Answer 2

First the workaround: I disabled the Assembly version Autoincrement!

Notes that this problem occured only in Vs2013 with a copy of a solution running perfectly vs2010. Vs2013 Build, rebuild, clean solution, manual deletion of ./bin or ./obj or %TEMP% did not solve the problem. I also composed a new solution from scratch in Vs2013 to avoid corpses from vs2010: this new solution compiled only twice: the third time the error appeared again without any way... something in the machine stayed dirty.

Now the explication...

I had same problem on a solution with 86 project with the following outline: the '60.dll' is the wrong dll:

- 99.exe 
-- 80.dll
---- 70.dll
------- 60.dll
-- 81.dll
-- 82.dll
---- 60.dll

So the BC32206 error occurred with the reason.

The project '99.exe' currently contains references to more than one version of '60.dll, 
a direct reference to version 4.11.5618.23545 and an indirect reference (through '82.dll') to version 4.11.5618.23549. 
Change the direct reference to use version 4.11.5618.23549 (or higher) of '60.dll'

Note that the version differ only in revision from 23545 to 23549 (so only '4' unit): in some rebuild this difference was '1' unit; remebering that this number is the (seconds since midnight/2), I realized that for some reason the '60.dll' was compiled twice ... Nothing to do: i did not find any different copy of '60.dll' with the datetime corresponding to higher value request '23549'. So it is real that something is bugged in Vs2013.

So the last chance: I disabled Autoincrement and I pinned the Assembly version to X.Y.0.0: this is quite enough for my purpose because '60.dll' is a part of a comprehensive release and should never be deployed stand alone (I still use the fileVersion to browse the correct file)

Unmuzzle

Answer 3

My issue was with the Microsoft.SqlServer.SMO set of dlls. My resolution is completely different again to everyone elses. And note it was with Visual Studio 2017, v15.8.6. From what I can gather, there are multiple causes for this issue, and my solution was not about cleaning, or assembly auto numbering.

In workspace 1 everything built but in workspace 2 I had the above issue due to this: The Microsoft.SqlServer.SMO namespace has about 10 or so dlls all set to particular version. 8 of the dlls were correctly found, directly referenced and version specific. However 2 had a hint path but were not version specific, and also not found at the hint path. So it defaulted those two to ones found in the GAC of a more recent version. As soon as I copied in the missing two dll's into the hint path, and set them as version specific, it all worked.

And just to make sure, I did manually edit the project file to set each reference to the older version required, and also added the Assembly Binding Redirect in the app.config to the older version for good measure.

Opulence

Answer 4

As the error messages indicate, you have a version conflict with your libraries. Check the version on the references to ensure they match, or better yet, ensure that you are using the reference to the same file in your main and sub projects.

Imago

They all appear to be the same, everywhere that i've looked. I even removed the reference from all three projects in the solution and added it back. – Brandie

Grab a copy of each conflicting dll. Add it to the sub project, clean and build the sub project, and then add the same dll to the main project and compile. Repeat for each dll/subproject. If you use the same file reference from the main and sub projects the versions should match up. Currently, you have a newer version in the cache for you sub projects and it is causing the issue. – Imago

Answer 5

I had the same 'apparent' issue which cost me a full day trying to resolve. I had checked my project dependencies thoroughly and all were pointing to the same version of the offending dll. I even nuked my local folder and brought everything back out from Subversion - still the same. I ran Process Explorer and searched for the dll only to find the old dll was being referenced by .NET Reflector. I had used .NET Reflector a couple of days prior to debug an older version in a different Visual Studio solution and .NET Relector was referencing the older dll in one of its folders. This might save someone some time.

Carob

Answer 6

I found that the issue was because I had unintentionally set the wrong start up folder. For instance I had PROJECT_A with a dependency on PROJECT_B and PROJECT_A should have been the start up project. However, I didn't realize that PROJECT_B was now the start up folder.

PROJECT_A was compiling with an old reference to the PROJECT_B dll and then PROJECT_B was subsequently creating a new version and copying that new version to the bin folder.

Correcting the start up folder corrected this for me.

Elwina

Answer 7

We had a similar issue that a clean didn't resolve. It turned out that a bin folder got included in the project by accident, so the referenced dll got checked in to version control. Undoing the include and removing the dll from the repo did the trick.

Brummett

Answer 8

I was able to clear the reported conflict by changing [assembly: AssemblyVersion("1.0.*")] to [assembly: AssemblyVersion("1.0.5814.0")] in the AssemblyInfo.cs file of the 'offending' project.

Based on the following observations, this seems to be an IDE issue:

• A different version is reported each time Visual Studio is started;
• For example, between revisions 1.0.5814.18599 and 1.0.5814.18600.
• Whereas the actual revision in all bin folders is ...17929.

Apparently, VS detects and 'caches' the conflict when it is started. Clean or Rebuilt offer no help.

Also, it seems as though only C# class libraries bring about this behavior.

Emmen

Answer 9

I experienced this error while remote debugging. The version of the referenced dll on the machine being debugged was functionally identical but with a different version number to the one referenced at compile time. The fix was to replace the version on the machine being debugged.

Pickering

Answer 10

I solved this problem for all script tasks in my SSIS package by editing the .DTSX file and replacing all instances of "Microsoft SQL Server\100\SDK\Assemblies" with "Microsoft SQL Server\120\SDK\Assemblies".

I did the 'replace', then refreshed in VS 2013, and all the errors went away.

Notice that the references were already referring version 12, but the "HintPath" was still referring to the "\100\" path. I'm assuming this was the source of the issue.

Here is an XML snippet from the .DTSX file before and after:

BEFORE:

<ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

AFTER:

 <ItemGroup>
    <Reference Include="Microsoft.SqlServer.ManagedDTS, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91">
      <SpecificVersion>False</SpecificVersion>
      <HintPath>..\..\..\..\..\..\..\..\Program Files (x86)\Microsoft SQL Server\120\SDK\Assemblies\Microsoft.SQLServer.ManagedDTS.dll</HintPath>
    </Reference>
    <Reference Include="System" />
    <Reference Include="System.Data" />
    <Reference Include="System.Windows.Forms" />
    <Reference Include="System.Xml" />
    <Reference Include="Microsoft.SqlServer.ScriptTask, Version=12.0.0.0, Culture=Neutral, PublicKeyToken=89845dcd8080cc91" />
  </ItemGroup>

Ornithopter

Answer 11

I simply went into "NuGet" and uninstalled all packages relating to the conflicting library. Then I carefully re-installed again making sure that each item had the same (the latest) version number. I was using "cEfSharp" modules but had installed a mixture of Version 57 and 51 by mistake.

Civic

Answer 12

I had a project that was using JSON.net v10 and a modern version of ASP Identity. JSON.net was using an older version of the http.formatting dlls - upgrading via Nuget to the latest release solved it for me.

Wiedmann

Answer 13

As others have mentionned, this error can be caused because of the auto-increment feature in the AssemblyInfo.file of the project.

We originally had the AssemblyVersion like

<Assembly: AssemblyVersion("4.6.1")>

that I changed to

<Assembly: AssemblyVersion("4.6.1.*")>

That was the mistake. I started having this issue. I thought I would only need to remove the .* but it still didn't work because the assembly without the .* had a lower version number than the auto-generated one.

So the for the fix, I had the assembly referenced in the namespaces section of my web.config file. I removed it and ran the project, got some runtime errors. Then I added back the namespace item and the error went away.

Give it a shot if you have your assembly in the namespace section of your web/app.config.

EDIT: One of my colleagues still had the issue after doing this trick. A better solution is to simply clear the temporary ASP .NET folder. (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files)

Disillusion

Answer 14

My story may be more of an edge case, but it's worth noting.

I'm developing for a platform that allows the development of 3rd party plugins, using a garden-variety SDK they provide.

The 3rd party plugins are compiled as DLLs and uploaded to the platform, and they're loaded using voodoo and random poultry sacrifices (read: not sure how they're dynamically loaded).

Simply put, my problem was that both the main program and my 3rd party DLL were referencing "fred.dll". But I was referencing version 1.1 of "fred.dll", instead of version 1.0 of "fred.dll" that the program had loaded. Referencing version 1.0 of "fred.dll" in my 3rd party component fixed my issue.

Algometer

Answer 15

in my case, clean and build worked fine

Rainer

Some additional information would probably be beneficial. – Indemnity

Answer 16

Try to delete all bin/debug/* stuffs

Neuropath