.NET Core - MSB3277: Found conflicts between different versions - c#

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.

Related

Conflicts with Nuget Package References

I have observed a strange behaviour of NuGet packages where the same version of NuGet packages (under different projects of a solution) refers different versions of dependent dlls.
Please see the images below:
Microsoft.Extensions.Caching.Abstractions Version 3.1.3
Same assembly , different version
Same assembly , different version
This is my nuget folder for Microsoft.Extensions.Caching.Abstractions:
Nuget folder for Microsoft.Extensions.Caching.Abstractions
But the logs shows that version 3.1.18 has been loaded, which is never used in any of the package references used in the solution. Am I missing something here?
`AppDomain: AssemblyLoad: Microsoft.Extensions.Caching.Abstractions, Version=3.1.18.0,
Culture=neutral, PublicKeyToken=adb9793829ddae60`
I have tried changing the Verbosity (Tools--> Options--> Projects and Solutions--> Build and Run) to "Diagnostics" and the build output showed the following conflict:
`Encountered conflict between 'Platform:Microsoft.Extensions.Caching.Abstractions.dll' and 'CopyLocal:C:\Users\91998\.nuget\packages\microsoft.extensions.caching.abstractions\3.1.3\lib\netcoreapp3.1\Microsoft.Extensions.Caching.Abstractions.dll'. Choosing 'CopyLocal:C:\Users\91998\.nuget\packages\microsoft.extensions.caching.abstractions\3.1.3\lib\netcoreapp3.1\Microsoft.Extensions.Caching.Abstractions.dll' because AssemblyVersion '3.1.3.0' is greater than '3.1.0.0'`
Please guide how to correct this so that there won’t be any conflicts between versions of the same assembly within the solution and the same assembly reference will be used in all the projects.

Why does my .NET Standard 2.0 (multi-targetting) project has a warning on one of the dependent assemblies?

I have a project that is currently targetting NetStandard1.4.
I'm trying to make it multi-target-frameworks for:
net461
netstandard14
netstandard20
the rational is for a particular framework (an app targets), only pull down the minimum number of assemblies. So in the example above, ns14 has a min framework of 461, but an app that is targeting net461 pulls down some core stuff which people are saying adds extra noise, when those assemblies are not getting used.
When I try and target those 3 frameworks, I get some warning in the NetStandard2.0 version.
I try hovering the mouse over that assembly in Visual Studio but no tool-tip displays. Also, the errorlist or output (build) window has no explanation there.
Is there a way I can see what the warning is? Maybe even via CLI?
You are referencing System.Net.Http in .netStandard projects. This reference is already present in NetStandard.Library, so you don't need to add it. Most of the time, you should only reference projects or NuGet package.
On my computer, dotnet build does fail with the following warning:
C:\Program Files\dotnet\sdk\2.1.100-preview-007326\Microsoft.Common.CurrentVersion.targets(2051,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "System.Net.Http". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors.
If you don't want to add a reference to NetStandard.Library, the solution is to add reference only to the net461 version using the Condition attribute:
<PropertyGroup>
<TargetFrameworks>net461;netstandard1.4;netstandard2.0</TargetFrameworks>
</PropertyGroup>
<ItemGroup Condition="'$(TargetFramework)'=='net461'">
<Reference Include="System.Net.Http" />
</ItemGroup>

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.

Install-Package : Failed to add reference to 'System.Runtime'

I'm trying to install the Autofac nuget package in my project using the command
Install-Package -Prerelease Autofac
but it fails with the error
Install-Package : Failed to add reference to 'System.Runtime'. Please make sure that it is in the Global Assembly Cache.
I've tried re-installing .NET Framework 4.5.2 (which is the version my project targets) but got the message ".NET Framework 4.5.2 is already installed". However, searching C:\Windows\assembly\ for System.Runtime.dll doesn't find any exact matches (although there are a few instances of System.Runtime.ni.dll, which (seem to indicate) that they are really the same assembly...).
What can I do about this?
Update: apparently I was confused about the location of the GAC. Amy enlightened me, and searching in C:\Windows\Microsoft.NET\assembly instead I do find System.Runtime.dll. Why doesn't Visual Studio?
I had the same problem.
Found the solution here: https://github.com/aspnet/WebHooks/issues/18
To fix it, I added <Reference Include="System.Runtime"/> to the .csproj
file for the project, rebuilt it and it worked.
Please make sure that it is in the Global Assembly Cache.
That is an excessively unhelpful error message. It not only doesn't describe the real problem, it also leads you drastically astray to find a workaround. An assembly reference for a .NET Framework assembly must never come from the GAC. The kind of failure modes when it does can be exceedingly nasty to diagnose. Reference assemblies must come from the C:\Program Files (x86)\Reference Assemblies directory.
Looking at the .nuspec file for the Autofac nuget package you are trying to install, it supports two distinct targets. One is for DNXCore version 4.0.10-beta-22816. Hopefully you are not using it, that project is changing rapidly.
The other is .NET Portable, profile 259. Which allows your project to target .NET 4.5.x, Store, Phone80 and Phone81. What the blunt error message is telling you is that it has trouble finding that profile. Use Windows Explorer to have a look-see, the profile is stored in the C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETPortable\v4.5\Profile\Profile259 directory. It has the required System.Runtime.dll reference assembly.
Well, surely it awol, I can't guess at the underlying reason.
They did make subtle mistakes in the .nuspec file. Do consider a more stable release of Autofac, you probably don't want to be a beta tester. And don't target 4.5.2, there is no point to that. It doesn't add anything interesting and forcing your user to update his .NET install is not very reasonable.

Why am I getting 'Assembly '*.dll' must be strong signed in order to be marked as a prerequisite.'?

I'm trying to compile my excel addin using C# 4.0, and started to get this problem when building my project in Visual Studio. It's important to tell you that I haven't had this problem before. What could cause this to happen?
When I had this problem I fixed it by turning off the 'Enable ClickOnce security settings'.
Menu: Project | 'Project name' Properties... | Security tab | 'Enable ClickOnce security settings' check box.
My guess is that you're not working with strongly named assemblies. I've had this error when two projects reference slightly different versions of the same assembly and a more dependent project references these projects. The resolution in my case was to remove the key and version information from the assembly name in the .csproj files (it didn't matter anyway), and then do a clean build.
Changes between the different assembly versions were compatible with the parts of the solution referring to them. If this is not the case with you, you might have to do some more work to resolve the issue.
NuGet
With NuGet it's easy to get into this situation if:
You install a package to one project in your solution.
A new version of that package is deployed to the package source.
You install it to another project in the same solution.
This results in two projects in your solution referencing different versions of that package's assemblies. If one of them references the other and is a ClickOnce app, you'll see this problem.
To fix this, issue the update-package [package name] command at the Nuget Package Manager Console to bring everything up to a level playing field, at which point the problem goes away.
You should manage NuGet packages at the solution level rather than at the project level unless there is a compelling reason not to. Solution level package management avoids the potential of multiple versions of dependencies. When using the management UI, if the Consolidated tab shows 1 or more packages have multiple versions, consider consolidating them to one.
See this answer.
Go to the publish page and click on "Application Files". From there you should see a list of your DLL's. Ensure that the ones that are giving you trouble have their Publish Status marked as "Include" rather than "Prerequisite".
I've had this problem. It happened because i had many projects pointing to the same assembly but from different versions. I solve it selecting the same version to all projects in my solution.
If you have changed your assembly version or copied a different version of the managed library stated in the error you may also have previously compiled files referencing the wrong version. A 'Rebuild All' (or deleting you 'bin and 'obj' folders as mentioned in an earlier comment) should fix this case.
If you tried all the other answers in this question and you:
Have multiple projects in your solution
Have a project (Project A) that references another project (Project B), whose project references a NuGet package.
In Project A, you used Intellisense/ReSharper to bring in the reference to the NuGet package referenced in Project B (this can happen when a method in Project B returns a type provided by the NuGet package and that method is used in Project A)
updated the NuGet package via NuGet Package Manager (or CLI).
...you may have separate versions of the NuGet packages DLL in your projects' References, as the reference created by Intellisense/ReSharper will be a "normal" reference, and not a NuGet reference as expected, so the NuGet update process won't find or update it!
To fix this, remove the reference in Project A, then use NuGet to install it, and make sure the NuGet packages in all projects are the same version. (as explain in this answer)
Life Pro Tip:
This issue can come up whenever ReSharper/Intellisense suggests to add a reference to your project. It can be much more deeply convoluted than the example above, with multiple interweaving projects and dependencies making it hard to track down. If the reference being suggested by ReSharper/Intellisense is actually from a NuGet package, use NuGet to install it.
you need to sign the assembly with a key. Go in the project properties under the tab signing:
Adding my solution for this issue for anyone it might help.
I had a ClickOnce solution throwing this error. The app referenced a common "Libs" folder and contained a project reference to a Foo.dll. While none of the projects in the solution referenced the static copy of the Foo.dll in the "Libs" folder, some of the references in that folder did (ie: my solution had refs to Libs\Bar.dll which referenced Foo.dll.) Since the CO app pulled all the dependencies from Libs as well as their dependencies, both copies were going into the project. This was generating the error above.
I fixed the problem by moving my Libs\Foo.dll static version into a subfolder, Libs\Fix\Foo.dll. This change made the ClickOnce app use only the project version of the DLL and the error disappeared.
Deleting the DLL (where the error is occurred) and re-building the solution fixed my problem. Thanks
When this happened to me with the WindowsAPICodePack after I updated it, I just rebuilt the solution.
Build-->Rebuild Solution
I encountered this problem after migrating an Excel Addin from packages.config to PackageReference. Seems to be related to this issue.
The following works as a crude workaround if you're not using ClickOnce (it will omit all the dependency information from the .manifest file):
Unload project, edit .csproj
Find the section looking like this:
<!-- Include additional build rules for an Office application add-in. -->
<Import Project="$(VSToolsPath)\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets" Condition="'$(VSToolsPath)' != ''" />
Edit a renamed copy of the referenced .targets file (in my case, the file resolved to C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Microsoft\VisualStudio\v15.0\OfficeTools\Microsoft.VisualStudio.Tools.Office.targets and I made a copy Microsoft.VisualStudio.Tools.Office_FIX.targets in the same folder - didn't check if it works from a different folder).
Find the GenerateApplicationManifest element and change its attribute Dependencies="#(DependenciesForGam)" to Dependencies="".
Change the section found in 2. to reference your edited .targets file instead.
This will have to be repeated whenever the version of the .targets file shipped with VS is updated (or you won't get the updates), but I'm hoping it will be fixed soon...
There were too many projects in my solution to go through and individually update so I fixed this by:
Right-clicking my solution and selecting 'Manage NuGet Packages for Solution...'
Going to the Updates tab
Finding the affected package and selecting Update
Clicked OK and this brought all instances of the package up to date
Unloading and reloading the problem project solved it for me.
I went to publish, application files, found the dll throwing the error changed it to 'Include' from 'Include (Auto)'. I can now publish.
Is your assembly properly signed?
To check this, press Alt+Enter on your project (or right click, then Properties). Go to "Signing". Verify that the check box "Sign the assembly" is checked and the strong name key file is selected and "Delay sign only" is unchecked.
Now Here is a different approach to the problem:
Right click on the project and select the 'Unload Project' option. You will notice you project becomes unavailable.
Right click on the unavailable project and select the 'Edit' option.
Scroll down to the ' < ItemGroup > ' tag that contains all the resource tags.
Now go to the reference that has been displayed on the error list, you will notice it it uses a single tag (i.e. < Reference Include="assemble_name_here, Version=0.0.0.0, Culture=neutral" / >).
Change that to look as follows:
.
<Reference Include="assemble_name_here, Version=1.0.0.0, Culture=neutral, processorArchitecture=MSIL" >
< Private > True < / Private >
< HintPath > path_here\assemble_name_here.dll < / HintPath >
< / Reference >
Save your changes, Right click on the unavailable project again and click on the 'Reload Project' option, then build.
This is caused when you change the version of the .dll that is referenced. You need to delete all items, or the .dll in the target build folder.
I got the similar compiler error. Once I add the dependent project of the dll file to the solution, issue resolved.
If your main project using some library projects and have reference to them, you can cause this problem if your project reference to a assembly dll file instead to library project when you change something in your library project (ex: rename a class).
You can check all references to your main project by view in Object Browser window (menu View->Object Browser). A reference to a dll file always has a version number. Ex: TestLib [1.0.0.0]
Solution: delete the current reference of your main project to the library project and add reference to that library project again.
After trying most of the solutions here, I finally just added a reference to the project from the click once project, this changed it to Include (Auto) from Include and it finally worked.
What helped me was I went onto Package Manager Solution and looked at the installed package which was causing the issue. I saw that several projects were referencing the same package but different versions. I aligned them based on my needs and it worked.
I had this in a solution w/ 6 projects.
One of my projects was referring to the named assembly as a file reference. The others were all pointing to the project reference.
I usually get a different error in these cases.
My solution was to delete the named assembly anywhere it was referenced and add it back.
Once I worked through the project, ths problem disappeared.
Before doing this, I tried cleaning the solution as well as making sure none of the projects were signed.
hope it helps someone...
If its a mismatch of a dependencies dependencies, go to the NuGet package manager at the solution level and check the Update and Consolidate tabs, harmonise it all.
I recently hit this problem. In my case, I have NuGet packages on different assemblies. What I had was different versions of the same NuGet packages associated with my own assemblies.
My solution was to use the NuGet package manager upon the Solution, as opposed to the individual projects. This enables a "consolidation" option, where you can upgrade your NuGet packages across as many projects as you want - so they all reference the same version of the assembly.
When I did the consolidations, the build failure disappeared.
I also bump into kind of problem, all I just had to do is delete the .dll (can be found in reference) that causing the error and add it again.
Works like a charm.
Try with update-package -reinstall -ignoredependencies
Just go to Publish -> Application File -> And change the effected dll publish status from prerequisite to include!
This worked for me!
In my case, I upgraded the project to .net 4.7.2 but still built in old visual studio version (2015).
When i built the project in VS 2019, the build failure disappeared.

Categories

Resources