由于程序集冲突，在非 dotnet 核心项目（.net fx 4.6.2）上使用 MS.Extns.DependencyInjection 和 MS.Extns.Logging 时 MSbuild 失败

Question

我创建了一个基于 .net fx 的 asp.net web api 2 项目，我尝试在该项目中使用来自 Microsoft.Extensions 组件的 MS 依赖注入和 MS 日志程序集。它实际上适用于基于非 dotnet 核心的项目，提供依赖注入和带有抽象的日志框架。在本地以及当我们使用 Visual Studio（在我的情况下为 2017 版）时，它可以工作、根据需要进行部署并成功运行。

当我们使用 MSBUILD 时，它会失败。我有另一个 web api 2 项目，它没有使用 DI 并通过 MS.extns 登录，它构建成功。我不知道解决我面临的冲突。当我尝试删除冲突的程序集时，它会逐步删除要删除的注入和日志记录抽象库。

我也在我的项目中使用 EF 6。冲突始于 System.ComponentModel.Annotations。我失败的构建日志错误行如下。

两者都是 web api 2（非 dotnet 核心） 1. 成功构建 = .net fx 4.6.2, EF 6, DI 使用 Unity。 （当时没有实现日志记录） 2. 构建项目失败 = .net fx 4.6.2, EF 6, DI 使用 MS.Extns.DI 并使用 MS.Extns.Logging 进行日志记录。

    CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\AK\Api\PMApi\packages\System.ComponentModel.Annotations.4.5.0\lib\net461\System.ComponentModel.Annotations.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.ComponentModel.Annotations.dll'. Remove one of the duplicate references. [C:\AK\Api\PMApi\PM.Data\PM.Data.csproj]
Done Building Project "C:\AK\Api\PMApi\PM.Data\PM.Data.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\PM.BL\PM.BL.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\PM.Api\PM.Api.csproj" (default targets) -- FAILED.
Done Building Project "C:\AK\Api\PMApi\ProjectManApi.sln" (default targets) -- FAILED.

Build FAILED.

"C:\AK\Api\PMApi\ProjectManApi.sln" (default target) (1) ->
"C:\AK\Api\PMApi\PM.Api\PM.Api.csproj" (default target) (2) ->
"C:\AK\Api\PMApi\PM.BL\PM.BL.csproj" (default target) (3) ->
"C:\AK\Api\PMApi\PM.Data\PM.Data.csproj" (default target) (4) ->
(CoreCompile target) -> 
  CSC : error CS1703: Multiple assemblies with equivalent identity have been imported: 'C:\AK\Api\PMApi\packages\System.ComponentModel.Annotations.4.5.0\lib\net461\System.ComponentModel.Annotations.dll' and 'C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.6.2\Facades\System.ComponentModel.Annotations.dll'. Remove one of the duplicate references. [C:\AK\Api\PMApi\PM.Data\PM.Data.csproj]

    0 Warning(s)
    1 Error(s)

请帮助我，因为我想尝试使用 MS extns 的 DI 和 Logging 框架，它在测试和运行时工作得很好。就我使用 Jenkins/Team city 作为我自己的实例来设置持续集成的 msbuild 而言，我只需要 MSBUILD 来构建/测试/部署。

我需要知道这个 DI 和来自 MS.Extns 的日志记录是否不适用于非 dotnet 核心，并且我必须切换到使用不同的 DI 框架。因为，我已经完成了我的 api，在本地进行了测试，一切正常。

最好是，我希望使用这些，并就如何从 MSBUILD 中摆脱这种冲突提出适当的建议。

更新 1： 所有 Nuget pkg 都是最新的和最新的。此外，注释上的冲突正在引发所有项目，而与 EF 的项目无关。当我有 nuget 给我库时，为什么 msbuild 还需要在机器驱动器中查找 Microsoft 引用程序集路径？

更新 2： 冲突来自 Microsoft.Extensions.Logging - Microsoft.Extensions.Options 程序集，它引用 System.ComponentModel.Annotations。我认为 Nuget 版本尝试下载 4.5.1，而 Microsoft Common 程序集路径似乎具有 4.6.x 或更高版本，由于某种原因，Msbuild 引用并最终发生冲突。

如果值得研究问题出在哪里，我在 github 中有我的解决方案。 Github link 谢谢

Answer 1

为了它的价值，我继续使用 .net core 2.1 作为我的 Web API 的解决方案。我在 .net Core 2.1 版本上创建了一个新的 web api 解决方案，从而解决了我的需求。

长话短说： .net Core 2.x Web API 解决方案，带有日志框架扩展和自己的 IOC 框架。

长篇大论： 在从 .net web api 迁移到基于 .net Core 的 Web API 时，根据我的个人经验，有几点需要注意：

1. 程序集大小（构建大小）太小了。可能是因为 .net 核心将其核心程序集作为运行时程序集，因此所需的代码输出程序集结果较低。如果您安装了 .net 核心运行时，这可能是您想要在云上发布或托管的理想选择。许多文档确实讨论了有关此主题的各种选项，例如，如果您不想要这个，则将相应的程序集与应用程序程序集一起加载。

2. 构建和发布更简单：使用带有输出路径和配置类型参数的dotnet 命令是最简单的开始。同样，MS 有关于我们如何扩展它的大量文档（使其更复杂、自定义驱动或使用 MSBUILD 模板），但对于大多数需要，简单的解决方案在当前平台上是负担得起的。

3. 我们可以使用任何其他 IOC，但 MS 自己的 IOC 不仅易于实现，而且与自己的核心实现绑定。我们可以使用其他 IOC 来扩展 MS 扩展，但同样，从我的角度来看，这取决于我们如何使其更复杂（根据需要）但更简单的解决方案并依赖其他标准基础设施，因为它们与 . net 核心程序集，我们足够体面，可以使用他们自己的 IOC 扩展。

4. Logging - 带有众所周知的日志框架，现在提供了对 .net core MS 日志框架的扩展。我更喜欢 Nlog 和 Serilog，但它是一个开放的选择，与 .net core MS Extensions for Logging 兼容。

5. CORS - 如果跨应用程序/域或混合使用，则必须以稍微不同的方式处理并精心设计。

我很乐意听到对我的观点的反馈，但同样，这些是我个人的亲身体验，我分享了这些经验，作为我从 .net Web API 迁移时注意到的独特差异的指针。 （迁移/重写api基础框架）