This project is read-only.


Doesn't include dependency assemblies


I think the full dependency hierarchy should be included in the merged assembly by default rather than just the explicitly added references. That would more closely match the typical use case of producing a single .exe from all in-solution assemblies.

I made the following changes to MSBuild.ILMerge.Task.targets to make this task work for my solution:
<!-- all dependency assemblies-->
<CreateItem Include="@(ReferenceDependencyPaths)" Condition=" '%(CopyLocal)' == 'true' ">
    <Output TaskParameter="Include" ItemName="MergedDependencies"/>
  <!-- add the main assembly as the first one -->
Closed Dec 11, 2015 at 11:13 AM by archnae


archnae wrote Oct 28, 2014 at 8:00 PM

The transitive merge flag should be made configurable, really, together with other ILMerge flags.

I, being a hardcore control freak, want to know exactly and explicitly what goes into the final assembly. Otherwise some huge 3rd party UI library that is supposed to go to GAC can end up in the merged assembly simply because it is marked copy local in some referenced project twice removed. It is nice if you only want to build one .exe, but quite annoying if you build a complicated multi-featured .msi.

ddrinka wrote Oct 28, 2014 at 8:42 PM

I guess that makes sense, but then I would expect to just have a manual list of assemblies to merge in. It seemed like the intention of this package was to automate packaging everything in the bin/ directory into a self-reliant executable, and it took me quite a while to get started using the package because I would always end up with "Assembly not merged in correctly" errors. The .targets file also disabled the copying of dependency assemblies, transitive or otherwise, so figuring out which DLLs were missing required hacking the package to allow the assemblies to be copied so that I could track down what was missing. All in all, I would personally just make sure not to mark anything copy-local that shouldn't be, and also make sure to review the obj/*.ilmerge file before a release to make sure nothing was making it in that didn't belong. I think that ends up with a much more declarative solution than using, for instance, /closed.

archnae wrote Dec 28, 2014 at 4:49 PM

Changed .targets as per ddinka proposal and added "ILMergeTransitive" property to ILMerge.prop in release 1.0.3-rc2. Now default is to use transitive merge to make life easier for casual users.