ILMerge

What ILMerge Does and Why It Exists

ILMerge is a build-time utility for combining multiple managed .NET assemblies into a single output assembly. That makes deployment simpler when a solution is made up of many interdependent DLLs, but the merge changes assembly identity and metadata in ways that can affect runtime behaviour, binding, and compatibility.

Its core value is packaging, not security. Teams usually reach for it to reduce deployment complexity, bundle implementation code for distribution, or produce a single binary for an application or component. The trade-off is that the merged artifact is no longer a neutral container of the originals, it becomes a rewritten assembly with new loading characteristics.

How ILMerge Changes Metadata and Type Resolution

ILMerge does more than concatenate files. It rewrites references so types that were originally spread across assemblies can be resolved from the merged output, and it updates metadata that the .NET runtime uses for loading and type identity. That is why the tool can make a multi-assembly application look like a single deployable unit.

This rewrite step is also the reason ILMerge can be fragile. If code depends on assembly boundaries, explicit assembly names, resource lookup paths, or reflection-based discovery, the merged binary may behave differently from the original set of assemblies. In practice, the danger is not that the code disappears, but that the runtime sees it differently.

Common Compatibility and Runtime Side Effects

Because ILMerge changes assembly structure, it can interfere with strong naming, late-bound type discovery, reflection, and assembly loading logic. Code that expects a type to live in a specific assembly may fail after merging, even when the source code compiled cleanly before the merge.

These issues are especially common in plug-in architectures, component frameworks, and applications that load assemblies dynamically. If a library is inspected by name at runtime, or if external code expects a specific public identity, the merged output can break those assumptions even though the functionality still exists.

ILMerge is therefore best understood as a packaging transformation with behavioural consequences. It can be useful, but it is not a drop-in substitute for ordinary compilation or reference management.

When to Prefer Other Packaging or Deployment Approaches

ILMerge is most appropriate when the deployment goal is a single managed output and the codebase does not rely heavily on assembly identity. When the application uses reflection, plug-ins, or strict strong-name expectations, another packaging approach may be safer than forcing a merge.

For teams evaluating build and release options, a useful rule is to treat the merged assembly as a distinct artifact that needs its own test pass. SLSA is relevant here because the merge step changes how the final artifact is produced, so provenance and repeatability of the build output matter. If the output is difficult to reproduce or validate, the packaging convenience may not be worth the operational risk.

Likewise, deployment controls and runtime integrity checks should account for the fact that the merged file is the shipped unit. NIST SP 800-53 Rev 5 Security and Privacy Controls helps frame the need for controlled configuration, integrity, and change management around build artifacts. For teams that also need a broader baseline for secure software delivery, OWASP SAMM provides a useful maturity lens for release and packaging practices.

Risk and Threat Considerations

ILMerge itself is not a vulnerability, but it can hide or alter the assumptions that code and operators make about assembly boundaries. That creates risk when applications depend on those boundaries for reflection, type loading, or signing behaviour, because a merge can introduce subtle failures that only appear after deployment.

Failure mechanism: Rewriting metadata and assembly identity can break runtime resolution paths, weaken compatibility with strong names, or make type discovery behave differently from the original build.

Impact: Applications may fail at startup, load the wrong code path, or expose brittle behaviour that is difficult to diagnose after release.

Practitioner Guidance

What to watch for: Treat ILMerge output as a new executable contract, not a mechanical copy of the original assemblies. Validate any code paths that use reflection, dynamic loading, resource lookup, or public assembly identity before you rely on the merged artifact in production.

Practitioner takeaway: If merging changes how the application is loaded or discovered, the build pipeline should own that risk explicitly rather than assuming the merge is transparent.