Сбой MSbuild при использовании MS.Extns.DependencyInjection и MS.Extns.Logging в основном проекте, отличном от dotnet (.net fx 4.6.2), из-за конфликтов сборки

Question

Я создал проект asp.net web api 2 на основе .net fx, в котором я пытался использовать сборки MS Dependency и MS logging из компонентов Microsoft.Extensions.На самом деле он работает с проектами, основанными не на ядре Dotnet, обеспечивая внедрение зависимостей и каркас логирования с абстракциями.Локально, и когда мы используем Visual studio (версия 2017 в моем случае), она работает, развертывается при необходимости и успешно работает.

Когда мы используем MSBUILD, он не работает.У меня есть другой проект web api 2, который не использует DI и не регистрируется через MS.extns, и он успешно собирается.Я понятия не имею, чтобы разрешить конфликты, с которыми я сталкиваюсь.Когда я пытаюсь удалить конфликтующие сборки, он подходит к библиотекам абстракции Injection и logging, которые будут удалены.

Я также использую 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)

Пожалуйста, помогите мне, так как я хотел попробовать DI и Logging Framework, используя MS extns, и он отлично работает во время тестирования и запуска.Что касается msbuild, который я использую для настройки Continuous Integration с использованием Jenkins / Team city в качестве моего собственного экземпляра, мне нужен MSBUILD только для сборки / тестирования / развертывания.

Мне нужно знать, не будет ли работать этот DI и логирование от MS.Extns с ядром, отличным от dotnet, и что мне нужно переключиться, чтобы использовать другую структуру DI.потому что, я закончил мой API, протестирован локально, и все работает отлично.

желательно, я хочу использовать их с надлежащим советом о том, как избавиться от этого конфликта от MSBUILD.

Обновление 1: Все pkgs Nuget являются самыми последними и актуальными.Кроме того, конфликт с аннотациями вызывает все проекты, независимо от проекта, который предназначен для EF.Когда у меня есть возможность предоставить мне библиотеки, зачем msbuild нужно искать путь справочных сборок Microsoft на диске компьютера?

Обновление 2: конфликт возникает из-за Microsoft.Extensions.Logging- Microsoft.Extensions.Options сборки, которые ссылаются на System.ComponentModel.Annotations.Я думаю, что версия Nuget пытается загрузить 4.5.1, в то время как путь к сборкам Microsoft Common, кажется, имеет версию 4.6.x или выше, что по какой-то причине Msbuild ссылается и заканчивается конфликтом.

У меня есть решение в github, если стоит посмотреть, где проблема. Github ссылка Спасибо

Answer 1

Для чего это стоит, я перешел к использованию .net core 2.1 в качестве решения для использования моего веб-API.Я создал новое решение для веб-API в версии .net Core 2.1 и, таким образом, решил мою потребность.

Короткая история : .NET Core 2.x Web API-решение с расширениями каркаса ведения журнала и собственной платформой IOC делает все.

Короткая история: Несколько вещей, на которые стоит обратить внимание, когда я переходил с .net web api на .net Core API на базе ядра:

1. Размер сборки (размер сборки) был очень низким.возможно потому, что ядро ​​.net имеет свои основные сборки в виде сборок времени выполнения, и, следовательно, требуемые выходные сборки кода оказываются ниже.Это может быть идеальным вариантом, если вы хотите отправить или разместить в облаке, если у вас установлено ядро ​​.net.Много документации действительно говорит о различных опциях по этой теме, например, если вы этого не хотите, у вас есть соответствующие сборки, загруженные вместе со сборкой приложения.

2. построить и опубликовать проще: использовать команду dotnet с параметрами для пути вывода и типа конфигурации проще всего с самого начала.Опять же, у MS есть обширная документация о том, как мы можем расширить это (чтобы сделать его более сложным, настраиваемым или используя шаблоны MSBUILD), но для большинства нужд простое решение доступно на современных платформах.

3. Мы можем использовать любой другой IOC, но собственный IOC MS не просто прост в реализации, но связан с собственной реализацией ядра.Существуют и другие IOC, которые мы можем использовать для расширения с помощью MS-расширений, но опять же, чисто с моей точки зрения, речь идет о том, как мы можем сделать его более сложным (по мере необходимости), но более простыми решениями и полагаться на инфраструктуру других стандартов, если они совместимы.Чистые основные сборки, мы достаточно приличны, чтобы использовать свои собственные расширения для IOC.

4. Ведение журнала - поставляется с хорошо известными средами ведения журнала, теперь предоставленными расширениями для среды ведения журнала MS.Я предпочитаю Nlog и Serilog, но это открытый выбор в зависимости от того, что совместимо с MS Extensions для ведения журнала.

5. CORS - нужно обрабатывать немного по-другому и тщательно обрабатывать, если использовать его в разных приложениях / доменах или смешивать

Я открыт и рад услышать отзывы о своих позициях, но опять же, это мой личный практический опыт, которым я поделился в качестве указателей, я заметил уникальные отличия при переходе из .net WebAPI.(перенос / перезапись базы API-интерфейса)