Type “ServiceCollection” Both exist in “Microsoft.Extensions.DependencyInjection.Abstractions, Version=6.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60” and “Microsoft.Extensions.DependencyInjection, Version=5.0.0.1, Culture=neutral, PublicKeyToken=adb9793829ddae60”.
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.
uninstall 2 packages from all projects in solution and select one of them in the solution. if you found other required in depended solution try remove this dependece and replace by other
Funny (not really), the class ServiceCollection was moved from Microsoft.Extensions.DependencyInjection to Microsoft.Extensions.DependencyInjection.Abstractions in the version 6 :
Move ServiceCollection to abstractions (#52284)
Consequently the library Microsoft.Extensions.DependencyInjection isn't retrocompatible between the version 5 and the version 6.
In your case, you have a project that reference "Microsoft.Extensions.DependencyInjection.Abstractions" at the version 6, but also reference "Microsoft.Extensions.DependencyInjection" at the version 5, but as explained below this two versions aren't compatibles. You need to consolidate this two references.
If your project references directly the two references, just uninstall "Microsoft.Extensions.DependencyInjection.Abstractions" (as "Microsoft.Extensions.DependencyInjection" reference it).
But if this references are transitions, you can open the file "obj\project.assets.json" to try find where they come from. Then you can update some packages to consolidate its.
Related
I am trying to use the Open-XML-Powertools.
I have downloaded the current version from GitHub and I am copying a lot of code from the sample file
Open-Xml-PowerTools-vNext\OpenXmlPowerTools\WmlToHtmlConverter.cs
However, in application I am actually using the nuget package OpenXmlPowerTools Version 4.5.3.2, which is marked as the latest stable version.
Part of this code uses the method MetricsGetter.GetTextWidth:
var w = MetricsGetter.GetTextWidth(ff, fs, sz, runText);
However, this method is not present in the version of MetricsGetter in the nuget package.
Short term I can copy the source code of this function into my application, so will not be a big problem, but which version is up to date?
Is the code in GitHub newer than the code in the nuget package?
Or older?
Is there an alternative method which I should use with the nuget package?
Unfortunately, the NuGet package is very much outdated. Thus, the best approach is to:
fork (optionally) and clone EricWhiteDev's Open-Xml-PowerTools repository,
build the OpenXmlPowerTools.dll assembly from source,
put that assembly into a libs folder (or whatever you use), and
reference that assembly in your projects.
The previously official OfficeDev/Open-Xml-PowerTools repository has been archived.
I have pulled an in-house NuGet package's source into a new class library project of my solution, removed all references to the original package and referenced the class library. The solution builds just fine but when I run it I get the classic...
Could not load file or assembly 'Standards.Environment, Version=12.8.0.0, Culture=neutral, PublicKeyToken=e1f2345a678912bc' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
I've searched SO and tried the solution here: How to resolve “Could not load file or assembly... to no avail.
What I don't understand is that I get the above error even though the AssemblyInfo.cs of the Standards.Environment class project contains these lines:
[assembly: AssemblyFileVersion("12.8.0.0")]
[assembly: AssemblyVersion("12.8.0.0")]
Have I forgotten to do something when migrating the source code into my solution?
EDIT I have discovered that one of the other in-house NuGet packages is referencing the same package which I have removed (because I migrated its source into the solution.)
How can I force the other NuGet's DLL to accept the DLL of the class library as the dependency it is looking for?
The cause of the problem was that I had removed a NuGet package which contained the DLL which another NuGet package was looking for. When I migrated the original NuGet source into my solution it broke the references.
The solution was to switch back to using both NuGet packages and let them sit happily alongside each other OR import both.
Not particularly happy with this, but reverting back to a previous version of the solution and solving the real problem (an unrelated bug) was easier once I understood this.
I'm referencing System.Web.Http.dll, full path:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll
However, I'm getting a compile exception saying that it can't find ExceptionHandling in the System.Web.Http namespace.
The type or namespace name 'ExceptionHandling' does not exist in the namespace 'System.Web.Http' (are you missing an assembly reference?)
Looking in the file, it is indeed not there.
I have been updating NuGet packages, so I'm assuming it's been moved\replaced with something.
Where do I need to go now to get this namespace? The internet seems quite quiet on this.
OK, the solution was odd. Not sure how the project ended up in this state.
The fact that the reference was pointing to C:\Windows\Microsoft.NET\assembly\GAC_MSIL\System.Web.Http\v4.0_4.0.0.0__31bf3856ad364e35\System.Web.Http.dll showed that it wasn't using the assemblies provided by the package, which were in the packages folder.
I had to explicitly delete the references, then roll back the version of Microsoft.AspNet.WebApi.Core as VS wouldn't let me uninstall it as the project wouldn't compile (at least I assume that was why, never had that before though).
That re-added the assemblies with the correct paths, that being, paths to the packages folder.
I also stuck and your suggest solve my problem
my step is here
remove Reference System.Web.Http
remove Nuget Microsoft.AspNet.WebApi.Core
restart Visual Studio
try to install Nuget Microsoft.AspNet.WebApi.Core again
I received the following task
Remove the nuget packages from MyProject (check other webapps):
AspNetSprites-Core
AspNetSprites-WebFormsControl
Since I am not too fluent in .NET-specific technicalities, I have been searching for a while to find these. I have been using Visual Studio 2015 to search for these and found them under packages in the project's file tree. After removing them and removing the following line from web.config:
<add assembly="Microsoft.Web.Samples.ImageSprite" namespace="Microsoft.Web.Samples" tagPrefix="asp" />
I expected to successfully remove these from the project, but after I built the project the files reappeared under packages. What could be the cause of this behavior?
Since they are NuGet packages you should just be able to go to tools->NuGet Package Manager -> Manage NuGet packages for solution.
This will list all the installed packages for the project and you can uninstall them from here.
EDIT: Alternative solution from OP
That seems like a solution, but I already found out another one. I needed to remove the corresponding lines from packages.config
How do I solve it?
I see this type of conflicts in a number of assemblies...
1) C:\DEV\xyz\source\xyz.Web\Web.config.xslt
2> Consider app.config remapping of assembly "System.Web.Helpers, Culture=neutral, PublicKeyToken=31bf3856ad364e35" from Version "1.0.0.0" [c:\Program Files (x86)\Microsoft ASP.NET\ASP.NET Web Pages\v1.0\Assemblies\System.Web.Helpers.dll] to Version "3.0.0.0" [C:\DEV\xyz\source\packages\Microsoft.AspNet.WebPages.3.1.2\lib\net45\System.Web.Helpers.dll] to solve conflict and get rid of warning.
You should just be able to drop the reference to System.Web.Helpers.dll and then re-add it with the recommended version. You may have to browse for the newer version instead of just picking it from the MS libs.
Another, though more ham-fisted, option might be to create a new project/solution from scratch as MVC5 and move your files into it. But this is much more involved and accomplishes pretty much the same thing as the first suggestion.