Search code examples
.net.net-assemblyilmerge

Issue when using ILMerge to merge .NET 3.5 & .NET 2.0 assemblies


When attempting to merge several assemblies in a VS Post Build I ran into the issue:

ILMerge version 2.13.307.0
Copyright (C) Microsoft Corporation 2004-2006. All rights reserved.
ILMerge /out:Assembly.dll AssemblyA.dll AssemblyB.dll /targetplatform:v2,C:\Windows\Microsoft.NET\Framework\v3.5 /log:log.txt 
Set platform to 'v2', using directory 'C:\Windows\Microsoft.NET\Framework\v3.5' for mscorlib.dll
An exception occurred during merging:
Unable to cast object of type 'System.Compiler.Class' to type 'System.Compiler.Struct'.
   at System.Compiler.SystemTypes.Initialize(Boolean doNotLockFile, Boolean getDebugInfo, PostAssemblyLoadProcessor postAssemblyLoad)
   at ILMerging.ILMerge.Merge()
   at ILMerging.ILMerge.Main(String[] args)

where AssemblyA is the current project output $(TargetFileName) and AssemblyB is a referenced assembly.

  1. AssemblyA => v3.5
  2. AssemblyB => v2.0

The weird thing is that when I change the command to use .NET 4 it works:

ILMerge /out:Assembly.dll AssemblyA.dll AssemblyB.dll /targetplatform:v4,C:\Windows\Microsoft.NET\Framework\v4.0.30319 /log:log.txt

Since I wish the merged assembly to be version 3.5 and not 4 how do I get the former command to work or how do I resolve this error?


Solution

  • using directory 'C:\Windows\Microsoft.NET\Framework\v3.5' for mscorlib.dll

    Have a look, that directory doesn't contain mscorlib.dll. There is not much there at all, the .NET Framework versions 3.0, 3.5 and 3.5SP1 do not include a new runtime version. The CLR, jitter and many of the base assemblies are still v2.0. The only difference in these later releases are added assemblies.

    So the required option is /targetplatform:v2,C:\Windows\Microsoft.NET\Framework\v2.0.50727

    Fwiw, do be very, very careful when you target .NET 4.x, the c:\windows\microsoft.net directory is no longer the home directory for reference assemblies. Now located in c:\program files (x86)\reference assemblies. Getting this wrong can cause exceedingly hard to diagnose runtime errors when the machine has .NET 4.5+ installed. And now it does matter which specific subdirectory you pick.