Как интегрировать ILMerge в процесс сборки Visual Studio для объединения сборок?

Question

Я хочу объединить одну сборку .NET DLL и один проект библиотеки классов C#, на который ссылается проект приложения консоли VB.NET, в один исполняемый файл консоли командной строки.

Я могу сделать это с помощью ILMerge из командной строки, но я хочу интегрировать это объединение ссылочных сборок и проектов в проект Visual Studio. Из моего чтения я понимаю, что могу это сделать с помощью задачи MSBuild или Target и просто добавить его в файл проекта C#/VB.NET, но я не могу найти конкретного примера, поскольку MSBuild - большая тема. Более того, я нахожу ссылки, которые добавляют команду ILMerge к событию Post-build.

1. Как интегрировать ILMerge в Visual Studio проекта (C#/VB.NET), которые просто проекты MSBuild, чтобы объединить все ссылки сборки (копирование локальных = истина) в одну сборку?

2. Как это связано с возможным файлом ILMerge.Targets?

3. Лучше ли использовать событие Post-build?

Answer 1

В статье Смешение языков в одной сборке в Visual Studio бесшовно с ILMerge и MSBuild на http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx демонстрирует, как использовать ILMerge и MSBuild в Visual Studio Project.

Answer 2

Отметьте эту статью Джомо. Он имеет быстрый процесс, чтобы взломать ILMerge в систему MSBuild

• http://blogs.msdn.com/jomo_fisher/archive/2006/03/05/544144.aspx

Answer 3

Это отличный article, который покажет вам, как объединить ваши ссылки сборок в выходной сборки. Он показывает, как объединить сборки с помощью msbuild.

Answer 4

Один вопрос, который я нашел в статье: http://www.hanselman.com/blog/MixingLanguagesInASingleAssemblyInVisualStudioSeamlesslyWithILMergeAndMSBuild.aspx.

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

Чтобы исправить это - вместо:

<Target Name="_CopyFilesMarkedCopyLocal"/> 

Добавить эту запись в файл целей вместо (.NET 3.5) (только для фильтрации, не ILMerge CopyLocal файлы, и относиться к ним, как обычно)

<Target Name="AfterResolveReferences"> 
    <Message Text="Filtering out ilmerge assemblies from ReferenceCopyLocalPaths" Importance="High" /> 
    <ItemGroup> 
     <ReferenceCopyLocalPaths Remove="@(ReferenceCopyLocalPaths)" Condition="'%(ReferenceCopyLocalPaths.IlMerge)'=='true'" /> 
    </ItemGroup> 
</Target> 

Answer 5

некоторые больше информации, которая может быть полезной для некоторых людей реализации Scott Hanselman's solution.

Когда я впервые установил это, он пожаловался бы на невозможность разрешить ссылки на System.Core и т. Д. Это как-то связано с поддержкой .NET 4. Включение аргумента/lib, указывающее на каталог .NET 4 Framework, исправляет его (фактически просто включает $ (MSBuildBinPath)).

/lib:$(MSBuildBinPath)

Я тогда обнаружил, что ILMerge будет висеть при слиянии.Он использовал немного процессора и много оперативной памяти, но ничего не выводил. Я нашел исправление on stackoverflow of course.

/targetplatform:v4

Я также обнаружил, что некоторые из свойств MSBuild, используемых в статье блог Скотта опирались на выполнение MsBuild из каталога проекта, поэтому я переделан их немного.

Я переехал Мишени & ilmerge.exe в папку инструментов нашего исходного дерева, которое требуется еще один небольшой твик к дорожкам ...

я наконец кончался со следующим Exec элемента заменить один в оригинальной статье Скотта:

<Exec Command="&quot;$(MSBuildThisFileDirectory)Ilmerge.exe&quot; /lib:$(MSBuildBinPath) /targetplatform:v4 /out:@(MainAssembly) &quot;$(MSBuildProjectDirectory)\@(IntermediateAssembly)&quot; @(IlmergeAssemblies->'&quot;%(FullPath)&quot;', ' ')" /> 

UPDATE Я также нашел Logic Labs answer о сохранении CopyLocal поведения и только за исключением ilMerged сборки из Cop yLocal важно, если вы используете пакеты Nuget. В противном случае вам нужно указать аргумент/lib для каждого каталога пакетов ссылочных сборок, которые не объединяются.

Answer 6

Здесь альтернативное решение:

1) Установите ILMerge.MSBuild.Tasks пакет из NuGet

PM> Install-Package ILMerge.MSBuild.Tasks

2) Редактирование * .csproj файла проекта, который вы хотите объединить, добавив следующий код:

<!-- Code to merge the assemblies into one:setup.exe --> 
    <UsingTask TaskName="ILMerge.MSBuild.Tasks.ILMerge" AssemblyFile="$(SolutionDir)\packages\ILMerge.MSBuild.Tasks.1.0.0.3\tools\ILMerge.MSBuild.Tasks.dll" /> 
    <Target Name="AfterBuild"> 
    <ItemGroup> 
     <MergeAsm Include="$(OutputPath)$(TargetFileName)" /> 
     <MergeAsm Include="$(OutputPath)LIB1_To_MERGE.dll" /> 
     <MergeAsm Include="$(OutputPath)LIB2_To_MERGE.dll" /> 
    </ItemGroup> 
    <PropertyGroup> 
     <MergedAssembly>$(ProjectDir)$(OutDir)MERGED_ASSEMBLY_NAME.exe</MergedAssembly> 
    </PropertyGroup> 
    <Message Text="ILMerge @(MergeAsm) -&gt; $(MergedAssembly)" Importance="high" /> 
    <ILMerge InputAssemblies="@(MergeAsm)" OutputFile="$(MergedAssembly)" TargetKind="SameAsPrimaryAssembly" /> 
    </Target> 

3) Создайте свой проект, как обычно.

Answer 7

«MSBuild ILMerge task» (или MSBuild.ILMerge.Task) Комплект NuGet делает этот процесс довольно простым. По умолчанию он объединяет любые «копии локальных» ссылок в вашу основную сборку.

Примечание: Хотя пакеты имеют схожие названия, это один отличается от ILMerge.MSBuild.Tasks что Davide Icardi отметил в своем answer. Тот, который я предлагаю здесь, был впервые опубликован в августе 2014 года.

Answer 8

Мои 2 цента - я подобрал ответ Джейсона и сделал это для моего решения, где я хотел сгенерировать * .exe в папке bin/Debug со всеми *. DLL внутри одной и той же папки.

<Exec Command="&quot;$(SolutionDir)packages\ILMerge.2.13.0307\Ilmerge.exe&quot; /wildcards /out:&quot;$(SolutionDir)..\$(TargetFileName)&quot; &quot;$(TargetPath)&quot; $(OutDir)*.dll" /> 

Примечание: Это решение, очевидно, жестко закодировано в версию пакета ILMerge nuget. Пожалуйста, дайте мне знать, если у вас есть предложения по улучшению.