Мы только что начали использовать ILMerge в наших решениях, которые перераспределяются и используются в наших других проектах и пока неплохо. Все, кажется, работает хорошо. Мы даже запутали упакованный блок непосредственно.
Мы рассматриваем выполнение того же с блоками Библиотеки MS Enterprise.
единственная реальная проблема я вижу с ним, управление версиями отдельных блоков от пакета.
MSBuild - это, безусловно, вариант с наименьшим трением. Различные версии fx не так уж и важны во время сборки - если вы используете что-то важное из версии fx выше той, которая установлена, она не будет собираться. В последний раз, когда я был, мы создали огромную систему сборки с несколькими средами на основе NAnt, и она подключилась к MSBuild с помощью задач MSBuild от NAnt. MSBuild хорош сам по себе, если вы просто занимаетесь работой с MS, но у нас был ряд вещей, которые MSBuild изначально не поддерживал, отсюда и оболочка NAnt.
MSBuild - подходящий инструмент для этой работы. Просто сопоставьте свою версию фреймворка с версией фреймворка, поставляемого с используемой вами Visual Studio.
32-битные и 64-битные версии не должны иметь значения, я не думаю - я почти уверен, что и 32-битные, и 64-битные версии Csc.exe
могут перекрестно скомпилировать на другую платформу. Файл проекта MSBuild (XML-файл *. * Proj) должен содержать все, что нужно MSBuild для сборки вашего приложения.
Я согласен со всеми остальными. Чтобы упростить задачу, просто сделайте vsvars.bat
(пакетный файл, который является командной строкой Visual Studio) частью вашего сценария сборки, и тогда MSBuild будет работать.
Мы используем Nant для управления msbuild. Если вас беспокоят разные версии фреймворка, особенно пакеты обновлений, используйте FxCop, чтобы убедиться, что вы не допускаете появления неожиданных зависимостей. Подробности см. В этом ответе .