Предотвращение или устранение загрязнения пространства имен в .Net Core

Question

Резюме

Для моего проекта CS capstone мы столкнулись с проблемой с именем класса, существующим в двух разных зависимостях. В частности, мы используем зависимость для использования MySQL с Entity Frame и одну для только что подключенного и выполнения запросов MySQL напрямую.

Фон

Не-EF принадлежит компоненту вне проекта, и эта база данных является одним из наших основных способов взаимодействия с базой данных. Клиент / наставник попросил внести любые необходимые дополнения или изменения в отдельную базу данных, к которой подключается EF.

Вопрос

Мой вопрос в основном о том, как исправить ошибку the type <class-name> exists in both..., но меня больше интересует коренная проблема загрязнения пространства имен в .Net Core и действия, которые мы можем предпринять. Я рассмотрел ошибку, и в первоначальных результатах описано исправление, которое применимо только к .Net, а не к .Net Core, и объяснение того, что .Net Core не поддерживает алиасинг.

Потенциальные исправления

• Отдельные проекты - Я спросил кого-то, кого я знаю, у которого больше опыта работы с .Net, и он предложил создать отдельные проекты. Хотя это, очевидно, сработало бы в плане избавления от ошибки сборки, я не знаю, как мы могли бы использовать ее в основном приложении ASP.Net. Я предполагаю, что или оба должны быть приложениями или превращением одного в библиотеку. Я также предполагаю, что если это отдельная библиотека, у нее будет та же проблема, что и сейчас.

• Удаление одной зависимости - В настоящее время я считаю, что менее чем идеальным решением является переписывание кода, основанного на EF, для использования прямой зависимости MySQL-соединения. В этой базе данных EF меньше кода, поэтому было бы проще переписать его и немного SQL.

• Псевдоним или полная ссылка - Я обнаружил, что результаты, применимые только к .Net, описывают с использованием псевдонима или ссылки на полный путь приличия в типе. Из того, что я прочитал, в настоящее время это не поддерживается в .Net Core. Если это так, как я могу это сделать?

using System;
using System.Collections.Generic;
using MySql.Data.MySqlClient;

namespace OVD.API.GuacamoleDatabaseConnectors
{
    public class GuacamoleDatabaseConnector : IDisposable
    {

        private MySqlConnection connection;
...

Ошибка относится к типу MySqlConnection и в полном объеме: GuacamoleDatabaseConnectors/GuacamoleDatabaseConnector.cs(81,16): error CS0433: The type 'MySqlConnection' exists in both 'MySql.Data, Version=8.0.15.0, Culture=neutral, PublicKeyToken=c5687fc88969c44d' and 'MySqlConnector, Version=0.49.2.0, Culture=neutral, PublicKeyToken=d33d3e53aa5f8c92' [/Users/markbeussink/Action/OVD/OVD.API/OVD.API.csproj]

Вот .cs.proj

<Project Sdk="Microsoft.NET.Sdk.Web">
  <PropertyGroup>
    <TargetFramework>netcoreapp2.2</TargetFramework>
    <AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Microsoft.AspNetCore.App"/>
    <PackageReference Include="Microsoft.AspNetCore.Razor.Design" Version="2.2.0" PrivateAssets="All"/>
    <PackageReference Include="Ldap.NETStandard" Version="1.0.3"/>
    <PackageReference Include="MySql.Data" Version="8.0.15"/>
    <PackageReference Include="Pomelo.EntityFrameworkCore.MySql" Version="2.2.0"/>
  </ItemGroup>
</Project>

Answer 1

Просто создайте новый проект "библиотека классов", и внутри этого проекта вы можете создать интерфейс, который дает вам доступ к методу из одного из ваших компонентов (вам нужно реализовать свой "компонент" и его метод внутри этого проекта),Что-то вроде в фасаде.Тогда в остальной части вашего решения вы будете использовать только что созданную ссылку на проект.Это решение позволяет вам определить собственное имя пространства имен

Answer 2

Это действительно плохая форма для двух отдельных проектов - иметь тип с одинаковым пространством имен и одинаковым именем по той причине, которую вы только что обнаружили.Это совсем не нормально и не ожидается, что вы столкнетесь с таким конфликтом, и вы, вероятно, никогда больше не столкнетесь с ним в своей карьере.

Похоже, этот проект:

https://www.nuget.org/packages/MySqlConnector/

решил заткнуть пространство имен более официального поставщика ADO.NET для MySQL:

https://www.nuget.org/packages/MySql.Data

, определив тип с именем: MySql.Data.MySqlClient.MySqlConnection вместо использованияMySqlConnector.MySqlClient.MySqlConnection или что-то подобное.

Лучший способ продвижения вперед - исключить один из них из ваших проектов и использовать только другой.Здесь очевидным выбором будет переключиться с

https://www.nuget.org/packages/Pomelo.EntityFrameworkCore.MySql/

на

https://www.nuget.org/packages/MySql.Data.EntityFrameworkCore/

Но у меня нет никакого мнения оотносительные достоинства этих библиотек.

Если вы не можете сделать это, C # предоставляет директиву компилятора , чтобы вы могли псевдоним одной из сборок с другим пространством имен.См. https://docs.microsoft.com/en-us/dotnet/csharp/language-reference/compiler-messages/cs0433

Это фактически добавит новый самый внешний уровень пространства имен к нарушающей сборке, поэтому other MySqlConnection будет известен (только в вашем коде) как SomeAlias.MySql.Data.MySqlClient.MySqlConnection.