Лучшие практики ILMerge

Question

Вы пользуетесь ILMerge?Используете ли вы ILMerge для объединения нескольких сборок, чтобы упростить развертывание DLL-файлов?Были ли у вас проблемы с развертыванием / управлением версиями в рабочей среде после объединения сборок вместе?

Я ищу несколько советов относительно использования ILMerge для уменьшения трудностей при развертывании, если это вообще возможно.

Answer 1

Я использую ILMerge почти для всех своих различных приложений.Я интегрировал его прямо в процесс сборки релиза, так что в итоге я получаю по одному exe-файлу на приложение без дополнительных dll-файлов.

Вы не можете использовать какие-либо сборки C ++, содержащие машинный код.Вы также не можете использовать какие-либо сборки, содержащие XAML, для WPF (по крайней мере, у меня не было никакого успеха в этом).Во время выполнения он жалуется, что ресурсы не могут быть найдены.

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

Answer 2

Введение

В этом посте показано, как заменить все .exe + .dll files с помощью одного combined .exe.Он также сохраняет отладку .pdb файл не поврежден.

Для консольных приложений

Вот основные Post Build String для Visual Studio 2010 с пакетом обновления 1 используется .NET 4.0.Я создаю консольный файл .exe со всеми вложенными.dll-файлами, включенными в него.

"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards

Основные подсказки

• Результатом является файл "AssemblyName.all.exe" который объединяет все вложенные библиотеки DLL в один .exe.
• Обратите внимание на ILMerge\ справочник.Вам нужно либо скопировать утилиту ILMerge в каталог вашего решения (чтобы вы могли распространять исходный код, не беспокоясь о документировании установки ILMerge), либо изменить этот путь, чтобы указать, где находится ILMerge.exe .

Дополнительные подсказки

Если у вас возникли проблемы с тем, что он не работает, включите Output, и выберите Show output from: Build.Проверьте точную команду, которая на самом деле была сгенерирована Visual Studio, и проверьте, нет ли ошибок.

Пример Сценария сборки

Этот скрипт заменяет все .exe + .dll files с помощью одного combined .exe.Он также сохраняет файл debugging .pdb нетронутым.

Чтобы использовать, вставьте это в свой Post Build ступенька, под Build Events вкладка в проекте C # и убедитесь, что вы настроили путь в первой строке так, чтобы он указывал на ILMerge.exe:

rem Create a single .exe that combines the root .exe and all subassemblies.
"$(SolutionDir)ILMerge\ILMerge.exe" /out:"$(TargetDir)$(TargetName).all.exe" "$(TargetDir)$(TargetName).exe" "$(TargetDir)*.dll" /target:exe /targetplatform:v4,C:\Windows\Microsoft.NET\Framework64\v4.0.30319 /wildcards
rem Remove all subassemblies.
del *.dll
rem Remove all .pdb files (except the new, combined pdb we just created).
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).all.pdb.temp"
del *.pdb
ren "$(TargetDir)$(TargetName).all.pdb.temp" "$(TargetName).all.pdb"
rem Delete the original, non-combined .exe.
del "$(TargetDir)$(TargetName).exe"
rem Rename the combined .exe and .pdb to the original project name we started with.
ren "$(TargetDir)$(TargetName).all.pdb" "$(TargetName).pdb"
ren "$(TargetDir)$(TargetName).all.exe" "$(TargetName).exe"
exit 0

Answer 3

Мы используем ILMerge в блоках приложений Microsoft - вместо 12 отдельных DLL-файлов у нас есть один файл, который мы можем загружать в наши клиентские области, плюс структура файловой системы намного аккуратнее.

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

Answer 4

Я знаю, что это старый вопрос, но мы используем ILMerge не только для уменьшения количества зависимостей, но и для интернализации "внутренних" зависимостей (например, automapper, restsharp и т.д.), Которые используются утилитой.Это означает, что они полностью абстрагированы, и проекту, использующему объединенную утилиту, не нужно знать о них.Это снова уменьшает количество требуемых ссылок в проекте и позволяет ему использовать / обновлять свою собственную версию той же внешней библиотеки, если требуется.

Answer 5

Мы используем ILMerge во многих проектах.Тот Самый Фабрика программного обеспечения для веб-сервисов, например, выдает на выходе что-то вроде 8 сборок.Мы объединяем все эти библиотеки DLL в одну библиотеку DLL, так что хосту службы придется ссылаться только на одну библиотеку DLL.

Это несколько облегчает жизнь, но и большого значения в этом нет.

Answer 6

У нас была такая же проблема с объединением зависимостей WPF ....ИЛМерге, похоже, этим не занимается.Costura.Однако Fody отлично сработал для нас, и на его запуск ушло около 5 минут...очень хороший опыт.

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

Он объединяет все библиотеки DLL с пометкой "Копировать локально" = true и создает объединенный файл .EXE (наряду со стандартным выводом), который хорошо сжат по размеру (намного меньше общего выходного размера).

Лицензия является MIT as, поэтому вы можете изменять / распространять ее по мере необходимости.

https://github.com/Fody/Costura/

Answer 7

Обратите внимание, что для программ с графическим интерфейсом Windows (например, WinForms) вы захотите использовать /target:winexe выключатель.
The /цель:exe переключатель создает объединенный консоль применение.

Answer 8

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

Answer 9

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

Мы рассматриваем возможность проделать то же самое со сборками библиотеки MS Enterprise.

Единственная реальная проблема, которую я вижу в связи с этим, - это управление версиями отдельных сборок из пакета.

Answer 10

Недавно у меня возникла проблема, когда у меня была объединенная сборка, в сборке у меня было несколько классов, которые вызывались через отражение в Umbraco opensource CMS.

Информация для выполнения вызова через отражение была взята из таблицы базы данных, которая содержала имя сборки и пространство имен класса, который реализовал интерфейс.Проблема заключалась в том, что вызов отражения завершался неудачно, когда dll была объединена, однако, если dll была отдельной, все работало нормально.Я думаю, проблема может быть похожа на ту, что возникла у longeasy?

Answer 11

Я только начинаю использовать ILMerge как часть моей сборки CI, чтобы объединить множество мелкозернистых контрактов WCF в единую библиотеку.Это работает очень хорошо, однако новая объединенная библиотека не может легко сосуществовать со своими библиотеками компонентов или другими библиотеками, которые зависят от этих библиотек компонентов.

Если в новом проекте вы ссылаетесь как на свою ILMerged lib, так и на устаревшую библиотеку, которая зависит от одного из входных данных, которые вы предоставили ILMerge, вы обнаружите, что вы не можете передать какой-либо тип из ILMerged lib какому-либо методу в устаревшей библиотеке, не выполнив какое-либо сопоставление типов (напримеравтоматическое или ручное отображение).Это происходит потому, что после того, как все скомпилировано, типы эффективно дополняются именем сборки.

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

Мой совет состоял бы в том, чтобы избегать включения в вашу объединенную сборку любой общедоступной библиотеки, которую предоставляет ваша объединенная сборка (напримерчерез возвращаемый тип, параметр метода / конструктора, поле, свойство, универсальный ...), если вы точно не знаете, что пользователь вашей объединенной сборки не зависит и никогда не будет зависеть от автономной версии той же библиотеки.

Answer 12

Мне кажется, что Лучшая практика ILMerge № 1 - это Не использовать ILMerge.Вместо этого используйте Интеллектуальная сборка.Одна из причин этого заключается в том, что # 2 Лучшая практика ILMerge - всегда запускать PEVerify после выполнения ILMerge, потому что ILMerge не гарантирует, что он правильно объединит сборки в допустимый исполняемый файл.

Другие недостатки ILMerge:

• при объединении он удаляет XML-комментарии (если бы меня это волновало, я бы использовал инструмент запутывания).
• он некорректно обрабатывает создание соответствующего файла .pdb

Другим инструментом, на который стоит обратить внимание, является Mono.Cecil и инструмент Mono.Linker [2].

[2]:http:// www.mono-project.com/Linker