mscorlib version conflict during build

P

8

52

On a new Win8.1 reinstall, with all of my code restored from backup, I'm suddenly now getting a Visual Studio warning when I build the main project of my solution:

Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.

I set the Output log level to Detailed and I found a few entries like this:

There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes". "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it had a higher version.

Trouble is, I'm not referencing mscorlib anywhere in the solution—old or new. I have a couple of apps on my machine that require .NET 3.5, but I can't see how that could be related.

One difference: the old Win8.1 install on which this warning did NOT occur was a standalone machine; this time I'm domain-joined. I don't know whether that makes a difference (I can't see how), but I thought I ought to mention it at least.

Parian answered 17/6, 2015 at 3:6 Comment(1)

I'm facing same issue. – Ingeingeberg 28/5, 2018 at 13:17

P

22

I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.

BUT

Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!

Parian answered 18/6, 2015 at 13:20 Comment(12)

Man--that's been bugging me forever. Thanks for the tip! – Scrambler 2/11, 2015 at 23:41

Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong! – Cornered 19/11, 2015 at 15:59

@user1069816: Yes, agreed. – Parian 12/12, 2015 at 3:46

this seemed to flood my solution with libraries. – Toreutics 29/9, 2016 at 18:51

@Demodave: Yes, this will reset all of your package references. It makes for a busy log file. – Parian 30/9, 2016 at 3:16

Hope this works, I did it before reading all the comments lol – Kite 1/12, 2016 at 5:52

No. But I forgot how to fix it. – Kite 7/12, 2016 at 9:24

@Worthy7: Not sure I follow you. "...how to to fix it"—do you mean running the command broke something or that the command didn't change anything and you're still getting the warning? – Parian 7/12, 2016 at 20:55

this is a dangerous solution. this could introduce a lot of unwanted changes. the answer below by Memet Olsen is a much saner and safer solution. – Adherence 17/5, 2017 at 18:45

@Adherence — I would tend to agree (see my reply to user1069816). I'm not sure whether the Consolidate feature was available to me at the time. Nevertheless, if this occurs again I'll try Memet's suggestion. If it works, I'll update the selected answer for this Q&A. Thanks. – Parian 17/5, 2017 at 19:31

Note that "update-package -reinstall" does not update any package reference - it just reinstalls the packages already referenced. This should not do any harm to your project. If you omit the "-reinstall" parameter, your project will be updated with the latest version of all nuget packages and that may be dangerous. – Mireillemireles 25/8, 2017 at 11:17

I can't do this on just about everything - too much stuff breaks. – Midshipman 16/2, 2020 at 14:39

M

30

Having different versions of a Nuget package on different projects may cause this problem as well. Make sure that all your packages have the same version:

(Within Visual Studio) Right click on the solution
Click on Manage Nuget packages for Solution
Click on the Consolidate tab
For every package in the Consolidate tab, update the package to the same version for every project.

Moton answered 11/1, 2017 at 9:6 Comment(3)

this is the right way to do it. worked great for us - clearly shows which packages have multiple versions and provides one-click method for resolving the specific issues - much more sane than a full-reinstall. – Adherence 17/5, 2017 at 18:49

@memetolsen: What if at "Consolidate" tab there is no packages to be updated? Any other recommendation? – Kabob 10/10, 2017 at 0:46

Consolidate does not find any packages even though the projects are sharing them (at least it does not work in VS2019) – Midshipman 16/2, 2020 at 14:38

P

22

I was able to fix this by issuing an update-package -reinstall command at the Package Manager Console.

BUT

Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong!

Parian answered 18/6, 2015 at 13:20 Comment(12)

Man--that's been bugging me forever. Thanks for the tip! – Scrambler 2/11, 2015 at 23:41

Be careful, updating all the packages in your solution could cause other problems, make sure you can roll back to a good version if it goes wrong! – Cornered 19/11, 2015 at 15:59

@user1069816: Yes, agreed. – Parian 12/12, 2015 at 3:46

this seemed to flood my solution with libraries. – Toreutics 29/9, 2016 at 18:51

@Demodave: Yes, this will reset all of your package references. It makes for a busy log file. – Parian 30/9, 2016 at 3:16

Hope this works, I did it before reading all the comments lol – Kite 1/12, 2016 at 5:52

No. But I forgot how to fix it. – Kite 7/12, 2016 at 9:24

@Worthy7: Not sure I follow you. "...how to to fix it"—do you mean running the command broke something or that the command didn't change anything and you're still getting the warning? – Parian 7/12, 2016 at 20:55

this is a dangerous solution. this could introduce a lot of unwanted changes. the answer below by Memet Olsen is a much saner and safer solution. – Adherence 17/5, 2017 at 18:45

@Adherence — I would tend to agree (see my reply to user1069816). I'm not sure whether the Consolidate feature was available to me at the time. Nevertheless, if this occurs again I'll try Memet's suggestion. If it works, I'll update the selected answer for this Q&A. Thanks. – Parian 17/5, 2017 at 19:31

Note that "update-package -reinstall" does not update any package reference - it just reinstalls the packages already referenced. This should not do any harm to your project. If you omit the "-reinstall" parameter, your project will be updated with the latest version of all nuget packages and that may be dangerous. – Mireillemireles 25/8, 2017 at 11:17

I can't do this on just about everything - too much stuff breaks. – Midshipman 16/2, 2020 at 14:39

B

12

I have been able to fix this issue by deleting my ".suo" file of my solution and then re-opening the solution. I then rebuild the solution and the issue is gone.

The ".suo" file is within the ".vs" folder which is what I usually delete.

Good luck!

Bicolor answered 19/7, 2016 at 17:48 Comment(2)

This sounds like a good trick, certainly less expensive and less risky than a full package reinstall. I'll try it next time that pops up (which is sure to happen sooner or later). – Parian 20/7, 2016 at 7:17

It was the only way that worked for me, when I updated one of the specific package I was having troubles (System.Net.Http), the mscorlib, System.Core and System was still showing conflicts in detailed mode of output. When I deleted the .suo, and opened again, the messages were gone. – Kotz 6/10, 2017 at 14:53

P

10

I solved this by setting my verbosity to Diagnostic as per this answer.

Once I did that and rebuilt my solution, the build log actually listed the specific packages that depend on the two different versions of mscorlib.

In my particular case, my project had references to version 2.0.20126.16343 of System.Net.Http. I opened up the NuGet Package Manager and updated this package to the latest version (4.3.4 at the time). The next time I built my solution, the warnings were gone.

Perfection answered 14/11, 2018 at 21:2 Comment(1)

I followed this advice and discovered this issue had nothing to do with the mscorlib! The root cause turned out to be a missing keystore file. – Obstinacy 28/8, 2019 at 4:17

H

7

Well my solution is a little bit simpler than all of the above. I simply added a reference to the two Assemblies throwing this error (System.Runtime.Serialization and mscorlib) and rebuilt the project. By doing this, I specified the 4.0.0.0 version and removed the ambiguity.

One of the two (mscorlib) couldn't be added via the GUI because of the "A reference to 'mscorlib' could not be added. This component is already automatically referenced by the build system." error.

I needed to open the .vbproj (.csproj) file and add a reference manually via:

<Reference Include="mscorlib" />

Hypoplasia answered 9/1, 2019 at 16:39 Comment(1)

Worked for me too! – Alfonsoalfonzo 16/1, 2019 at 20:48

C

2

I've tried all the following, but none has resolved the issue.

the command "update-package -reinstall".
Update and package via Consolidate tab.
Removing the ".suo" file.

However, My issue was a different case, I guess the new version of Xamarin.Forms package has used a different version of mscorlib. so I've downgraded it and it works fine.

I suggest you try all above solutions and also try to find which package is conflicting.

Coffee answered 21/10, 2017 at 17:27 Comment(0)

H

1

Following Memet Olsen's advice using VS2017 community...almost identical:

Right click Solution in Solution Explorer.
Select 'Manage Nuget Packages for Solution'
Check the packages. If any of them have a blue up-arrow rather than a green tick use the 'update' button

Hearken answered 22/6, 2017 at 19:17 Comment(0)

V

1

I also have tried all of the proposed solution to no avail.

In my project, this warning message was caused by a dll reference having a dependency on a different .net framework than the one that is targeted by my project.

In order to find out which dll reference was causing the warning, I simply used .net reflector to explore each dll reference to find out which one was referring a different .net framework (mscorlib).

In order to fix the issue, the reference dll has to be updated to a version which targets the same .net framework as the project using it, if such a version exist.

Hope this helps.

Vulvitis answered 10/10, 2018 at 20:53 Comment(2)

This behaviour is strange. If a library (.dll) is targeted on an earlier .NET Framework, it should run naturally on higher .NET Framework. Otherwise, .NET Framework is bad on compatibility. Why does this even be a warning? – Humid 7/5 at 7:17

If I remember correctly, this happened more often when a reference is added by a NuGet package. Sometimes, NuGet packages do not provide a DLL version that targets the same .net framework as the project that consumes the NuGet... – Vulvitis 8/5 at 12:22

Recommended topics

Hot tags