Встроенные ссылки в библиотеке
Нормально так...работает над переносом некоторых библиотек на .Объем стандартный пакет SDK. Что-то случилось, о чем я думал в течение многих лет, но никогда не был вынужден исправлять до сих пор. Я был разработчиком в C# примерно 15 лет, и это похоже на проблему, которую должен был бы решить новичок, поэтому мне немного неловко задавать этот вопрос. Но мой Googlefu до сих пор не выявил никаких решений, которые работали бы. Во всяком случае, вот мое удивление.
Библиотека A: содержит интерфейсы. Один из таких интерфейсов позволяет программисту обернуть соединение в электронную таблицу excel.
Библиотека B: содержит реализации этих интерфейсов. Хотя детали особого значения не имеют. Библиотека B, в частности, использует EPPLUS. Для получения более подробной информации я получаю библиотеки EPPLUS через Nuget.
Библиотека C: содержит код для правильной загрузки любой библиотеки реализации, указанной в файле конфигурации, и передачи этой реализации обратно исполняемому коду.
Исполняемый код: код, который фактически использует интерфейс для выполнения работы.
Конфигурационный файл: файл указывает, что исполняемый код должен использовать библиотеку B, чтобы сделать то, что ему нужно сделать.
Теперь... с точки зрения исполняемого кода... он не знает и не заботится о том, какая библиотека реализации загружается. Все, что он знает, это то, что он будет использовать интерфейс для выполнения своей работы. В этом случае исполняемый код вообще не должен иметь никакой ссылки на библиотеку B. библиотека B должна просто находиться где-то, где исполняемая загрузка может загрузить ее по назначению. Например, каталог времени выполнения, GAC или что-то в этом роде. Исполняемый код должен иметь только прямую ссылку на библиотеку а и библиотеку С.
Во время выполнения исполняемый код получает соответствующую реализацию с помощью загрузчика в библиотеке C и использует интерфейс для открытия книги excel по указанному пути. Его не волнует, как это делается, только то, что это так. Прямо сейчас мой исполняемый код - это просто модульный тест. Ему, конечно, не нужно ничего знать об ЭППЛУСЕ...
проблема:
Если исполняемый код не содержит прямой ссылки на EPPLUS, все это рухнет в тот момент, когда реализация библиотеки B попытается загрузить EEPLUS. Это означает, что если исполняемый файл не имеет ссылки Nuget или, по крайней мере, ссылки в его ссылочном узле в обозревателе решений, программа не будет работать, и вы получите '
System.IO.FileNotFoundException: 'Could not load file or assembly 'XXXX, Version=YYYY, Culture=neutral, PublicKeyToken=ZZZZ' or one of its dependencies. The system cannot find the file specified.'' исключение.
Теперь вы можете попытаться исправить это, используя событие AssemblyResolve в главном домене приложения. Впрочем, потому что обладаю Эпплусом.dll в вашем каталоге времени выполнения не означает, что у вас есть под рукой или вы можете загрузить десять или около того сборок, на которые полагается Epplus.
Поэтому, когда ваш AssemblyResolve даже срабатывает, вы можете загрузить Epplus. Но вы не загружаете его требования. В результате вы все равно получите исключение FileLoadException.
Теперь вы, конечно, можете встроить Эпплус.библиотека dll в библиотеке B и загрузите ее из потока ресурсов. Проблема с этим подходом заключается в том, что каждый раз, когда библиотека Epplus изменяется, вам нужно будет перекомпилировать свою библиотеку B, и вы все равно не получите все ссылки Epplus.
Нугет, конечно, обо всем позаботится... но это потребовало бы от вас отправки Вашего исполняемого кода с прямой ссылкой на Epplus, что разрушает всю концепцию разделения проблем. Хуже того, если у вас есть десять различных библиотек реализации, ваш исполняемый файл должен будет ссылаться на все из них, даже если пользователь никогда их не использует.
Что я уже пробовал:
Встраивание справочной библиотеки в библиотеку B и загрузка ее во время события AssemblyResolve.