введение

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

Для Консольных Приложений

вот основные Post Build String для Visual Studio 2010 SP1 с помощью .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 в один.исполняемый.
• уведомления . Вам нужно либо скопировать утилиту ILMerge в каталог решения (чтобы вы могли распространять источник, не беспокоясь о документировании установки ILMerge), либо изменить этот путь, чтобы указать, где ILMerge.exe находится.

расширенные подсказки

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

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

этот скрипт заменяет все .exe + .dll files в одном combined .exe. Он также сохраняет отладку .файл 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

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

после слияния файлов мне пришлось отредактировать список проектов visual studio, удалить 12 отдельных assmeblies и добавить один файл в качестве ссылки, иначе он будет жаловаться, что не может найти конкретную сборку. Im не слишком уверен, как это будет работать при развертывании post хотя, может стоит попробовать.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

имена также столкнутся, но вы можете исправить это с помощью псевдоним extern.

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

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

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

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

еще один инструмент, на который стоит обратить внимание, - Mono.Сесил и моно.Инструмент связывания [2].

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