Один большой исполняемый файл или много маленьких DLL? - PullRequest
Новая
       20

Один большой исполняемый файл или много маленьких DLL?

19 голосов
/ 21 мая 2010

С годами мое приложение выросло с 1 МБ до 25 МБ, и я ожидаю, что оно увеличится до 40, 50 МБ. Я не использую DLL, но помещаю все в один большой исполняемый файл.

Наличие одного большого исполняемого файла имеет определенные преимущества:

  • Установка моего приложения у клиента действительно: скопируйте и запустите.
  • Обновления могут быть легко заархивированы и отправлены клиенту
  • Нет риска наличия конфликтующих DLL (если у клиента есть не версия X EXE-файла, а версия Y DLL)

Большим недостатком большого EXE-файла является то, что время компоновки возрастает экспоненциально.

Дополнительная проблема заключается в том, что часть кода (скажем, около 40%) используется совместно с другим приложением. Опять же, преимущества в том, что:

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

Но, опять же, это серьезно влияет на время компиляции (каждый снова компилирует общий код на своем ПК) и на время компоновки.

Вопрос Группировка DLL для использования в исполняемом файле упоминает о возможности смешивания DLL в одном исполняемом файле, но, похоже, для этого все равно требуется вручную связать все функции в вашем приложении (используя LoadLibrary, GetProcAddress,. ..).

Как вы относитесь к размерам исполняемых файлов, использованию DLL и лучшему «балансу» между простым развертыванием и простой / быстрой разработкой?

Ответы [ 4 ]

14 голосов
/ 21 мая 2010

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

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

4 голосов
/ 01 сентября 2010

Принцип: уменьшите количество ваших сборок .NET до строгого минимума . Наличие одной сборки - это идеальное число. Это, например, случай с Reflector или NHibernate, которые представляют собой очень мало сборок. Моя компания опубликовала бесплатных двух белых книг по теме Один большой исполняемый файл или много маленьких DLL :

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

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

2 голосов
/ 21 мая 2010

Более простой способ поддержки больших программ состоит в том, чтобы объединить их в более мелкие управляемые части. Программа может состоять из оболочки и модулей, которые добавляют функцию в оболочку. Большие программы, такие как Visual Studio, все используют одинаковые концепции. Попробуйте этот подход, чтобы сделать более удобные и надежные программы.

2 голосов
/ 21 мая 2010

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

Что касается времени соединения - у вас может быть одновременно «много DLL» и «один большой исполняемый файл». Для каждой библиотеки DLL есть конфигурация проекта, которая создает статическую библиотеку. Поэтому, когда вы отлаживаете что-то, вы компилируете конфигурацию «DLL» проекта, а когда вам нужно отправить, вы компилируете конфигурации «статической библиотеки» ваших проектов. Иногда вы будете вести себя по-разному в разных конфигурациях, но это необходимо учитывать для каждого инцидента.

...