Почему DLL, связанный с EXE

Question

?

У меня возникают проблемы с тем, что DLL копируется в папку с exe, ссылающейся на нее. Насколько я понимаю, причиной, по которой я должен сделать DLL, является использование кода многократного использования. Таким образом, если я создаю DLL, на которую ссылаются 25 приложений (тем самым используя «многоразовый код»), тогда, когда мне нужно добавить функциональность изменения в DLL (скажем, обновив что-то, что происходит за кулисами), мне нужно идти откройте и перекомпилируйте все 25 приложений, чтобы убедиться, что они получают новую функциональность.

Конкретный пример: у меня есть DLL, ответственная за создание печатных форм заказа на работу. Форма и вид формы рабочего заказа изменились, но ни одна из содержащейся информации не изменилась. В этом случае мне нужно только внести некоторые изменения в код создания базовой формы, но никаких изменений в реализации этого кода (используются те же самые методы и свойства). Я бы не подумал, что мне нужно будет перестроить DLL, а затем перестроить каждое приложение, которое ссылается на него, но, похоже, это так. Если я не перестраиваю, то приложения продолжают использовать старую версию DLL.

Есть ли способ обойти это? Я думаю об этом неправильно? Должен ли я делать что-то еще? Неужели я просто полностью не понимаю все это? Спасибо за любую помощь, которую вы можете предоставить.

Answer 1

Есть ли способ обойти это?

Да - install the library in the Global Assembly Cache (GAC). Таким образом, многие приложения могут использоваться.

Прочитано How the Runtime Locates Assemblies, чтобы лучше понять, как загружаются ссылки. Практическая причина для развертывания DLL-файлов с EXE заключается в том, чтобы разрешить «развертывание XCOPY». Кроме того, он позволяет создавать «выпадающие» библиотеки из NuGet и других источников, которые могут быть добавлены без их «установки». Расширения Bolt-on для приложений также намного проще, поскольку их можно просто скопировать, и приложение может динамически загружать надстройки без необходимости регистрировать что-либо.

Многое из этого происходит из-за боли в мире COM, где каждый Должен быть зарегистрирован DLL, и если у вас было несколько версий, которые не были совместимы, вы оказались в «DLL Hell». .NET смягчил эти правила, разрешив развертывание версий с исполняемым файлом, но все же предоставляя механизм (GAC), позволяющий совместно использовать общие сборки.

Вам также прочитать Simplifying Deployment and Solving DLL Hell with the .NET Framework для более фона на том, как .NET использует сборки для решения задач управления версиями

В вашем случае это может можно просто скопировать DLL для всех новых приложений, но определенные факторы, которые могут помешать его:

• Если сборка подписана
• Если приложение требует определенной версии сборки
• и т. Д.

Answer 2

DLLs служат несколько целей. Одна из теоретических целей - позволить нескольким процессам совместно использовать одну и ту же DLL. И на самом деле, если вы устанавливаете DLL в GAC, это может позволить .NET фактически загружать DLL один раз в память (т. Е. Несколько процессов, запущенных в одно и то же время, используя одну и ту же DLL, не заставляют каждого получать свои собственные копия DLL в памяти, как это было бы в случае с другими DLL).

Но другая цель - просто для повторного использования кода. В этом случае основная функция DLL должна служить в качестве распространяемого репозитория для некоторых заданных функциональных возможностей. Не важно, что несколько процессов могут использовать одну и ту же копию DLL. Вместо этого важно, чтобы несколько процессов имели удобный способ повторного использования функциональности в DLL.

Также обратите внимание, что изменения в DLL могут быть полезными или не могут быть полезными. Конечно, каждый всегда надеется, что более новая версия DLL будет лучше. Но изменения в коде всегда означают возможность добавления новых ошибок в код. Программа, которая была тщательно протестирована с заданной версией DLL, может быть или не быть надежной при использовании с более новой версией той же DLL.

Более новую версию DLL обычно предлагают в основном для добавления функций. Конечно, некоторые ошибки могут быть исправлены в процессе, но опять же, если программа была протестирована с более старой версией и в настоящее время работает, новые исправления ошибок, вероятно, не являются критическими. В то же время программа, написанная с более старой версией, вероятно, не будет иметь практического способа использования новых функций.

Дисковое пространство дешево, а память почти такая же дешевая. И предоставление каждой программе собственной копии обеспечивает непредвиденные изменения в новой версии DLL, мешающей программе, которая была протестирована только с более старой версией.

Наконец, обратите внимание, что даже с помощью GAC можно установить несколько версий DLL. Поэтому, если DLL удовлетворяет необходимым требованиям, возможно значительно уменьшить проблемы с версиями DLL.

Answer 3

Похоже, что у вас есть проблема автоматизации сборки (или отсутствие). Если у вас есть весь код в одном контейнере (TFS, GIT и т. Д.), То нет причин, по которым вы не можете добавить все проекты в одно решение для сборки и распределить код таким образом. Таким образом, вы просто заходите и перекомпилируете основное решение, и файлы попадают во все приложения.

Другой вариант - использовать общую папку bin и вывести все проекты в этот основной каталог и выполнить их оттуда. Это потребовало бы перекомпиляции библиотеки DLL, и другие приложения немедленно подберут это.

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

Все это не учитывает, как вы потребляете/развертываете свои приложения и сколько пользователей/окружений вы должны принимать во внимание.

Answer 4

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

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

Разбиение продукта на DLL также заставляет вас думать о заказе сборки при создании зависимостей между компонентами.

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

И если вы планируете сделать свой продукт расширяемым с сторонними плагинами, часто бывает полезно иметь одну DLL, которая определяет интерфейс между приложением и его плагинами. Это облегчает разработчикам плагинов знать, что есть/нет в поддерживаемом API. И те же методы могут быть полезны, даже если вы просто используете модель расширяемости для организации кода, разработанного большой командой (или набором команд) в той же компании.