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

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

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

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

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

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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

Ответ 3

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

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

Ответ 4

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