Сбой 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. Мои ошибки в журнале неудачных сборок приведены ниже.

оба веб-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.

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

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. Ведение журнала - поставляется с хорошо известными средами ведения журналов, теперь предоставленными расширениями для.net core MS logging Framework. Я предпочитаю Nlog и Serilog, но это открытый выбор в зависимости от того, что совместимо с MS Extensions для ведения журнала.

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

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