Один большой исполняемый файл или многие маленький DLL?
За эти годы мое приложение выросло с 1 МБ до 25 МБ, и я ожидаю, что это вырастет далее до 40, 50 МБ. Я не использую DLL, но помещаю все в этот большой исполняемый файл.
Наличие одного большого исполняемого файла имеет определенные преимущества:
- Устанавливание моего приложения в клиенте действительно: скопируйте и выполненный.
- Обновления могут быть легко заархивированы и отправлены клиенту
- Нет никакого риска наличия конфликтующего DLL (где у клиента нет версии X EXE, но версии Y DLL),
Большой недостаток большого EXE - то, что связывающиеся времена, кажется, растут экспоненциально.
Дополнительная проблема состоит в том, что часть кода (скажем, приблизительно 40%) совместно используется с другим приложением. Снова, преимущества состоят в том что:
- Нет никакого риска при наличии соединения неправильных версий DLL
- Каждый разработчик может внести изменения на общем коде, который ускоряет разработки.
Но снова, это оказывает серьезное влияние на время компиляции (все компилируют общий код снова его ПК), и соединения времен.
Вопрос, Группирующий DLL для использования в Исполняемом файле, упоминает возможность смешивания DLL в одном исполняемом файле, но похоже, что это все еще требует, чтобы Вы связали все функции вручную в Вашем приложении (использующий LoadLibrary, GetProcAddress...).
Каково Ваше мнение об исполняемых размерах, использовании DLL и лучший 'баланс' между простым развертыванием и легкой/быстрой разработкой?
3 ответа
Один исполняемый файл имеет огромное положительное влияние на ремонтопригодность. Легче отлаживать, развертывать (не говоря уже о размерах) и диагностировать в полевых условиях. Как вы отметили, он полностью обходит адские библиотеки DLL.
Самым простым решением вашей проблемы является наличие двух режимов компиляции: в одном создается один исполняемый файл для производства, а в другом создается множество маленьких DLL для разработки.
Один большой исполняемый файл определенно полезен - вы можете оптимизировать всю программу и уменьшить накладные расходы, а обслуживание намного проще.
Что касается времени компоновки - у вас может быть одновременно «много DLL» и «один большой исполняемый файл». Для каждой DLL есть конфигурация проекта, которая строит статическую библиотеку. Поэтому, когда вы отлаживаете что-то, вы компилируете конфигурацию «DLL» проекта, а когда вам нужно отправить, вы компилируете конфигурации «статической библиотеки» своих проектов. Иногда у вас будет разное поведение в разных конфигурациях, но это нужно будет решать для каждого инцидента.
Более простой способ поддерживать большие программы - объединять их в более мелкие управляемые части. Программа может состоять из оболочки и модулей, которые добавляют функции в оболочку. Все большие программы, такие как Visual Studio, outlook, используют одни и те же концепции. Попробуйте этот подход, чтобы сделать программы более удобными в обслуживании и надежными.