Управляемые библиотеки как встроенные ресурсы

Question

Является ли хорошей практикой объединять все необходимые управляемые библиотеки в качестве встроенных ресурсов в проект библиотеки.NET, чтобы отправить только одну библиотеку DLL?

Предыстория: я создал API как.NET DLL (в C#), и он работает все нормально. Но библиотека имеет некоторые зависимости от других управляемых библиотек (около 15 библиотек), поэтому мне нужно их распространять.

Когда пользователи моего API создали приложение, они снова должны убедиться, что распространяют все эти библиотеки вместе с приложением. Для меня было бы лучше, если бы у них был только один dll для рассмотрения.

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

Answer 1

Есть много вопросов вокруг этого. Что произойдет, если вы ожидаете загрузки зависимой от платформы зависимости (например, x86 или x64), или это правда о приложении, потребляющем ваш API? Означает ли это, что вам также необходимо включить в свой пакет определенные сборки x86 и x64? Это быстро становится волосатым.

Вы должны рассмотреть возможность использования развертывания ClickOnce для этих типов сценариев. Затем все зависимости будут упакованы вместе.

Реально, это проблема для потребителя API, а не для производителя API. Ваш API может быть менее популярным, если у него много внешних зависимостей, но вам придется принимать там решения о том, что действительно важно для успеха вашего API.