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



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



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





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



  2. Как это связано с возможным Ильмергом?Файл целей?



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


733   8  

8 ответов:

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

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

Еще немного информации, которая может быть полезна некоторым людям, реализующим решение Скотта Хансельмана .

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

/lib:$(MSBuildBinPath)

Затем я обнаружил, что IlMerge будет висеть во время объединения. Он использует немного процессора и много оперативной памяти, но ничего не выдавал. Я нашел исправление на stackoverflow, конечно.

/targetplatform:v4

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

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

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

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

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

Вот альтернативное решение:

1) Установите ILMerge.программа MSBuild.Пакет задач от nuget

PM> Install-Package ILMerge.программа MSBuild.Задачи

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) Создайте свой проект как обычно.

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

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

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

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

<Target Name="_CopyFilesMarkedCopyLocal"/> 

Вместо этого добавьте эту запись в файл targets (только .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>

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

Ознакомьтесь с этой статьей Джомо. У него есть быстрый процесс, чтобы взломать ILMerge в системе msbuild

Мои 2 цента - я взял ответ @Jason и заставил его работать для моего решения, где я хотел сгенерировать *.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. Пожалуйста, дайте мне знать, если у вас есть какие-то предложения по улучшению.

Comments

    Ничего не найдено.