Как избежать C# распространения зависимости сборки? - PullRequest
0 голосов
/ 25 апреля 2020

Я создал решение C# (назовем его «ServiceProviderLib»), состоящее из нескольких библиотек классов с ссылками / зависимостями внутренней сборки решения. Решение имеет только одну библиотеку классов, которая предоставляет интерфейс publi c, предназначенный для использования в качестве api некоторыми другими приложениями.

A (publi c) --- зависит от ---> B --- зависит от ---> C.

Сейчас я занимаюсь разработкой приложения (назовем его «ServiceUserApp»), которое должно динамически связываться с API-интерфейсом «ServiceProviderLib».

Приложение --- зависит от ---> A.

Чтобы разрешить зависимость от «ServiceProviderLib», я использую обработчик для AppDomain.CurrentDomain.AssemblyResolve.

Я бы ожидал, что мне нужно разрешить только зависимость от A. Поскольку ServiceProviderLib должен разрешать свои внутренние зависимости для себя.

Но для приложения мне нужно разрешить все зависимости для A + B + C индивидуально.

Есть ли способ избежать этого?


Немного информации об истории вопроса: я знаю, что есть много плюсов и минусов в использовании статических / dynmai c ссылок / Разрешить библиотеки.

Если быть более точным, то, что я имею в виду под static / dynamici c:

stati c: в приложении я бы ссылался на библиотеку A и позволил бы свойству visual studio " Local Copy "со значением по умолчанию" true ". Это приведет к копированию DLL в каталоге сборки. В этом случае нет необходимости в ручном разрешении DLL.

dynamici c: в приложении я бы сослался на библиотеку A и установил бы для свойства Visual Studio "Local Copy" явно значение "false". В этом случае DLL не будет скопирована в каталог сборки ... и должна быть разрешена во время выполнения.

Я использовал оба варианта довольно долгое время и испытал, что динамическое связывание c приводит меньше проблем в моей специальной среде. Поэтому я решил придерживаться Dynami c.

1 Ответ

0 голосов
/ 25 апреля 2020

Если под «динамически связывать» вы имеете в виду, что вы загружаете сборки во время выполнения с помощью отражения, то вы автоматически не получаете тот же самый автоматический c загрузок зависимостей, который дает вам ссылка во время компиляции. (В CLR нет такой вещи, как динамическое / статическое c связывание.)

Если вы используете ссылки на время компиляции, то ваш код касается хотя бы одного типа из каждой сборки и будет нуждаться в прямой ссылке в определяющую сборку, чтобы решить их должным образом. Если вы удалите ссылки на B и C и скомпилируете, вы увидите точно, на какие типы B / C вы ссылаетесь и где.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...