Develop Reference

How do I override a nuget package circular reference

I have 2 solutions.
Main
Which builds an assembly: Main.DomainTypes.dll (this will get packaged as a nuget package)
External
Which builds an assembly: External.EventTypes.dll (this is also packaged as nuget package)
External.EventTypes.dll references Main.DomainTypes.dll via it's nuget package.
Now, some code has been added to Main, that references External.EventTypes (which therefore also references Main.DomainTypes).
When I run Main, it throws a FileNotFound exception, because it is trying to load the version of DomainTypes referenced by External.EventTypes, instead of the version it has just built.
I'm guessing that Main tries to load the highest version number referenced, which is the version in the nuget, not the version it has just built, except the version on disk IS the one just built, not the one referenced.
E.g., the nuget version of Main.DomainTypes referenced by External.EventTypes is 1.0.123, but the version of Main.DomainTypes just built doesn't yet have a package number, so defaults to 1.0.0
How can I get Main to load the local version, and not the nuget version?
I realise I could remove the circular reference by (re)defining the DomainTypes in external, but I'd rather not.

Assembly from nuget has strong name but cause build error of 'strongly-named assembly is required'

I successfully installed 'LiveCharts.Wpf' & 'LiveCharts' packages from NuGet, I use them in my code but when I want to build the project I get this error:
Unknown build error, 'A strongly-named assembly is required. (Exception from HRESULT: 0x80131044)
Note that those packages have a strong name. You can see it in the attached image:
Thanks.

I had similar issue, after publishing and trying to build a newer version with VS2017. I switched, in the properties->publish -> application files, for the nuget settings to include. From:
To:

I still don't know what caused this problem, but I opened a new project and installed the packages with 'package manager console' and not from 'NuGet Package Manager' and it's work.

msbuild reference assemblies resolve order while building solution with multiple .csproj in visual studio

I have a solution with multiple projects and these projects have nuget packages installed which are different in version. Looks when solution is rebuild, the version of dll copied to output directory is not deterministic and often I end up with runtime "file not found" exception for obvious reason. I will try to over simply the problem with below example :
Let's say ProjectA is cossole application and refers version 1.0.0 of assembly xyz.
ProjectA also refers to ProjectB in same solution via project reference. Now let say ProjectB references version 2.0.0 of assembly xyz.
I would like to know when solution is rebuild, is it deterministic which version of xyz dll will be copied to output directory ? If no, is there a way to ensure this. I know in that case I need to update config with appropriate binding re direction policy.

I would like to know when solution is rebuild, is it deterministic which version of xyz dll will be copied to output directory?
Yes, the version 1.0.0 of xyz dll will be copied to output directory.
According to the document Dependency resolution with PackageReference:
When the package graph for an application contains different versions
of the same package, NuGet chooses the package that's closest to the
application in the graph and ignores all others. This behavior allows
an application to override any particular package version in the
dependency graph.
In you case, the version 1.0.0 of xyz.dll is nearer to the projectA in the graph, that version will be copied to the output directory.
Then I also created a test package xyz with version 1.0.0 and 2.0.0, add those two nuget package to the projectA and projectB, then ProjectA also refers to ProjectB, after build, the version 1.0.0 xyz.dll copied to the output directory:
Update:
Can you check and confirm on the behavior when dll version is
different in ProjectA and ProjectB \
To verify this question, I have created a project xyz, generated the version 1.0.0 xyz.dll and 2.0.0 xyz.dll, then refers 2.0.0 xyz.dll to the project B and 1.0.0 xyz.dll to the project A, build the solution, got the same result: 1.0.0 xyz.dll will be copied to the output directory:
As the above test results, 1.0.0 xyz.dll will be copied to the output directory. When you got the file not found error, please check if you are invoke the method in version 2.0.0 the xyz.dll.
Update2:
screen shot you showing says file version (but file version is not
same as assembly version)
That because I want to be able check the AssemblyVersion in the windows explorer more convenient, I change the AssemblyVersion and AssemblyFileVersion at the same time before gnenerating the different version dll:
Like:
1.0.0 xyz.dll:
[assembly: AssemblyVersion("1.0.0.0")]
[assembly: AssemblyFileVersion("1.0.0.0")]
2.0.0xyz.dll:
[assembly: AssemblyVersion("2.0.0.0")]
[assembly: AssemblyFileVersion("2.0.0.0")]
So we just need check the file version instead of assembly version in wondows explorer for more convenient.
Hope this helps.

.NET Core - MSB3277: Found conflicts between different versions

I am having difficulty getting rid of the build warning:
warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved
specifically in .NET core projects.
In a full .NET framework project I would add some binding redirects so I googled around that issue and found this answer suggesting adding the following to the .csproj file:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
I have done this but to no avail - I still get the build warnings. Anything else I can do?

I had a look at your project and the problem seems to be a conflict with the versions that Rssdp was built against and the assembly version that the referenced System.Net.Http version (4.3.0) provides as compile-time reference.
This can be fixed by updating System.Net.Http to 4.3.2.
<PackageReference Include="System.Net.Http" Version="4.3.2"/>

Run Update-Package via Package Manager Console, this will fix MSB3277, what it does it reinstall all the packages with highest version possible.
More info on official docs https://learn.microsoft.com/en-us/nuget/consume-packages/reinstalling-and-updating-packages

I had the same issue. Got several warnings on one of the projects. I updated all packages from the solution level and warnings went away.
I used the Visual Studios for Mac to update the package.
Right click the solution, then Update Nuget Packages.

Does any of you dependencies use <PrivateAssets>?
If project A has a private reference, and both the private reference and another reference requires some package X, but the private one requires a higher version of package X, then the assembly for project A will also require the higher version of package X.
However you end up with a situation where any other project, e.g. project B, that references project A will only see the lower version of package X as a dependency - hence select the lower version of the assembly of package X to be copied to the output directory. The good news is that this DLL-HELL is detected at build time, where it sees that assembly projectA.dll requires a different projectX.dll than the one already designated as primary, and thus it logs some very unhelpful output about packageX being required by itself, which makes no sense... and gives up the build.

There was a conflict between "mscorlib, Version=4.0.0.0" and "mscorlib, Version=2.0.5.0" [duplicate]

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.

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.

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!

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!

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.

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" />

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.

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

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.