gluck/il-repack

Open-source alternative to ILMerge

il-repack's Issues

Add Donate button

I used this tool to deliver conflicting dlls in production. Please add Donation button to make little thanks.

Combined XML documentation file grows with each build

I am finding that with each build, the combined XML documentation file for the assembly grows. I have a case where the file grew from 2MB to 500MB.

The symptoms of this are increasingly longer build times and eventually a Visual Studio 2010 crash with the exception (shown when the crash is debugged) of System.OutOfMemoryException at the method ExecutionContext.CreateCopy.

To resolve I deleted the obj and bin folder of the projects that are using ILRepack and I can then compile, but the XML documentation file size continues to grow.

Consider update ILRepack to 4.0 framework

Exception when merging Magnum and MassTransit into a new assembly

When I try to include Magnum and MassTransit assemblies into my assembly I get the following exception.
NewtonSoft.Json is already merged into MassTransit dll

WARN: - Add assembly defining Newtonsoft.Json.Linq.<1271d1a1-a7a9-4fba-9f7e-f97
49b89f214>JTokenType Newtonsoft.Json.<0751e934-e021-431a-a8a4-1dad609472ec>JsonR
eader::Peek() to the merge
System.InvalidOperationException: Sequence contains no matching element
at System.Linq.Enumerable.First[TSource](IEnumerable1 source, Func2 predica
te)
at ILRepacking.ReferenceFixator.Fix(TypeReference type, IGenericParameterProv
ider context) in E:\workspace\thirdparty\il-repack-x\il-repack\ILRepack\Referenc
eFixator.cs:line 93
at ILRepacking.ReferenceFixator.Fix(FieldReference field, IGenericParameterPr
ovider context) in E:\workspace\thirdparty\il-repack-x\il-repack\ILRepack\Refere
nceFixator.cs:line 54
at ILRepacking.ReferenceFixator.FixReferences(Instruction instr, IGenericPara
meterProvider context) in E:\workspace\thirdparty\il-repack-x\il-repack\ILRepack
\ReferenceFixator.cs:line 293
at ILRepacking.ReferenceFixator.FixReferences(MethodBody body, IGenericParame
terProvider context) in E:\workspace\thirdparty\il-repack-x\il-repack\ILRepack\R
eferenceFixator.cs:line 275
at ILRepacking.ReferenceFixator.FixReferences(MethodDefinition meth, IGeneric
ParameterProvider context) in E:\workspace\thirdparty\il-repack-x\il-repack\ILRe
pack\ReferenceFixator.cs:line 254
at ILRepacking.ReferenceFixator.FixReferences(TypeDefinition type) in E:\work
space\thirdparty\il-repack-x\il-repack\ILRepack\ReferenceFixator.cs:line 130
at ILRepacking.ReferenceFixator.FixReferences(TypeDefinition type) in E:\work
space\thirdparty\il-repack-x\il-repack\ILRepack\ReferenceFixator.cs:line 126
at ILRepacking.ILRepack.Repack() in E:\workspace\thirdparty\il-repack-x\il-re
pack\ILRepack\ILRepack.cs:line 731
at ILRepacking.ILRepack.Main(String[] args) in E:\workspace\thirdparty\il-rep
ack-x\il-repack\ILRepack\ILRepack.cs:line 195

CustomAttributes messed up

I'm trying to merge code with mscorlib.dll, and it can't be repacked. An argument exception is thrown. Here's a stack frame:

Mono.Cecil.SignatureWriter.WriteCustomAttributeEnumValue (enum_type={System.Int32}, value=3) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2370
Mono.Cecil.SignatureWriter.WriteCustomAttributeValue (type={System.Int32}, value=3) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2311
Mono.Cecil.SignatureWriter.WriteCustomAttributeEnumValue (enum_type={System.Runtime.ConstrainedExecution.Consistency}, value=3) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2372
Mono.Cecil.SignatureWriter.WriteCustomAttributeValue (type={System.Runtime.ConstrainedExecution.Consistency}, value=3) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2311
Mono.Cecil.SignatureWriter.WriteCustomAttributeElement (type={System.Runtime.ConstrainedExecution.Consistency}, argument={Mono.Cecil.CustomAttributeArgument}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2282
Mono.Cecil.SignatureWriter.WriteCustomAttributeFixedArgument (type={System.Runtime.ConstrainedExecution.Consistency}, argument={Mono.Cecil.CustomAttributeArgument}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2243
Mono.Cecil.SignatureWriter.WriteCustomAttributeConstructorArguments (attribute={Mono.Cecil.CustomAttribute}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:2233
Mono.Cecil.MetadataBuilder.GetCustomAttributeSignature (attribute={Mono.Cecil.CustomAttribute}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1925
Mono.Cecil.MetadataBuilder.AddCustomAttributes (owner={System.Void System.Object::.ctor()}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1712
Mono.Cecil.MetadataBuilder.AddMethod (method={System.Void System.Object::.ctor()}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1425
Mono.Cecil.MetadataBuilder.AddMethods (type={System.Object}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1403
Mono.Cecil.MetadataBuilder.AddType (type={System.Object}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1238
Mono.Cecil.MetadataBuilder.AddTypeDefs () in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1212
Mono.Cecil.MetadataBuilder.BuildTypes () in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:1068
Mono.Cecil.MetadataBuilder.BuildModule () in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:850
Mono.Cecil.MetadataBuilder.BuildMetadata () in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:823
Mono.Cecil.ModuleWriter.BuildMetadata (module={test}, metadata={Mono.Cecil.MetadataBuilder}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:128
Mono.Cecil.ModuleWriter.WriteModuleTo (module={test}, stream={System.IO.FileStream}, parameters={Mono.Cecil.WriterParameters}) in .../il-repack/cecil/Mono.Cecil/AssemblyWriter.cs:108
Mono.Cecil.ModuleDefinition.Write (stream={System.IO.FileStream}, parameters={Mono.Cecil.WriterParameters}) in .../il-repack/cecil/Mono.Cecil/ModuleDefinition.cs:963
Mono.Cecil.ModuleDefinition.Write (fileName="test.dll", parameters={Mono.Cecil.WriterParameters}) in .../il-repack/cecil/Mono.Cecil/ModuleDefinition.cs:952
Mono.Cecil.AssemblyDefinition.Write (fileName="test.dll", parameters={Mono.Cecil.WriterParameters}) in .../il-repack/cecil/Mono.Cecil/AssemblyDefinition.cs:175
ILRepacking.ILRepack.Repack () in .../il-repack/ILRepack/ILRepack.cs:753
ILRepacking.ILRepack.Main (args={string[3]}) in .../il-repack/ILRepack/ILRepack.cs:229

Using the Mono.Cecil library I'm able to modify this library, so I posted the bug here instead of to the Cecil issues.

It seems like the TypeReference.etype shouldn't be ElementType.None as that's causing it to go around the enum loop a second time instead of printing the value.

Ideas?

ResourceEntry

Hi,

I'm having problems compiling ILRepack and get an error on ResourceEntry being not known.

Any idea where this class originates from (intellisense does not give a clue and neither do google searches).

regards

Explicitly implemented property disappears in certain scenarios

There's a bug when merging a type that contains two explicitly implemented indexer properties that differ on the arguments.

These properties are named not just "Index" but "InterfaceFullName.Index". The code at ILRepack.IsIndexer() checks only for "Index" and not for strings ending with ".Index", which makes it think that one of them is a duplicated.

My fix is to change the code from:

        private static bool IsIndexer(PropertyDefinition prop)
        {
            if (prop.Name != "Item")
                return false;

to

        private static bool IsIndexer(PropertyDefinition prop)
        {
            if (prop.Name != "Item" && !prop.Name.EndsWith(".Item")) // cover explicitely implemented properties
                return false;

Retargetable References are added without the retargetable flag

If you merge in a Portable Class Library (it has references say to System.Xml and the reference is marked as Retargetable)

When the reference is copied across to the new dll/exe the flag is dropped.

Feature request: namespace mapping when merging assemblies

I have a scenario where it would be interesting to collapse/remap the namespace of types from assemblies being referenced and internalized when merging assemblies. For example:

• Assembly A references assembly B (which contains namespaces such as B.X, B.Y, etc.)
• Assembly B references assembly C (which contains namespaces such as C.Foo, C.Bar, etc .)
• Assembly A is being linked and merged with its dependencies.
• Would be interesting to be able to specify an implementation namespace for all types that will be linked in - eg. A.Implementation.

Doing so would cause all types in B.X, B.Y, C.Foo, C.Bar to go into the namespace A.Implementation with generated/obfuscated unique names. The unique-ness bit is so that type name conflicts don't arise from merging namespaces.

The motivation behind the scenario is to hide the implementation of A, and after merging/linking it is not apparent what its dependencies were.

Thoughts? Is this something that would be doable based on the assembly rewriting facilities provided by Cecil and how ILRepack works?

Error while attempting to import resource file Arg_ResourceFileUnsupportedVersion

Error while attempting to import resource file Arg_ResourceFileUnsupportedVersion
Arg_ResourceFileUnsupportedVersion - unlocalized
found in http://referencesource.microsoft.com/#mscorlib/system/resources/resourcereader.cs

log:

INFO: - Importing Microsoft.TeamFoundation.Proxy.ManageTfsListInternal.resources
System.ArgumentException: Arg_ResourceFileUnsupportedVersion
в ILRepacking.ResReader..ctor(Stream stream)
в ILRepacking.ILRepack.FixResxResource(EmbeddedResource er)
в ILRepacking.ILRepack.RepackResources()
в ILRepacking.ILRepack.Repack()
в ILRepacking.ILRepack.Main(String[] args)

Feature request: add strong name to the assembly

We are adding a reference to the ILRepack.Lib NuGet package in a project so that we can merge assemblies that are created on-the-fly. Both for security and performance reasons, all our assemblies are strong named (use of GAC for faster loading on shared ASP .Net assemblies...).

The problem is that a strong named assembly cannot have a reference to non-strong named assemblies. We successfully added a strong name to ILRepack using standard MS tools (see http://ryanfarley.com/blog/archive/2010/04/23/sign-a-.net-assembly-with-a-strong-name-without-recompiling.aspx as an example) but it would be easier if you could add a snk to the ILRepack.exe assembly you deliver.

I wanted to do it myself and push the change on GIT but a procedure is missing on how to retrieve the Mono dependencies...

Thanks!

Feature request: Add option to remove all internal/private types which arent used

For reference, it was the only (still open) feature request on Google Code:
http://code.google.com/p/il-repack/issues/detail?id=1

Add a Licence

Looking to use ilrepack in a little project but I can't find any licence information. Would it be possible to specify a licence for the project and include it in the root?

The dependency on gradle is painful

I have downloaded il-repack source code, but to start the build I need to download Java bits from Oracle, and then configure JAVA_HOME manually, and then wait for several minutes for Mr.Gradle to be downloaded.

Is all that necessary for a .NET based project where MSBuild is available on every machine?

Possible bug with internalizing assemblies?

Say you have 4 assemblies, where 3 are internalized and the last one is not. You reference the resulting dll in a new project. Say the main assembly is A, and the namespace of the assembly merged that was not interalized is B. Trying to reference namespace B in this project will not work, because it is not recognized in visual studio.

Interesting enough, if you view the object browser (or in ilspy for that matter) namespace B is clearly available in the merged assembly.

Also if you try to add assembly B as a solution project reference, visual studio complains that assembly B is available in both the merged assembly and the solution project reference.

Any ideas of what could be wrong?

/keyfile does not work when keyfile is readonly

TFS likes to make the files readonly until you checkout the files. Trying to use ILRepack with the /keyfile option will result in an exception.

System.UnauthorizedAccessException: Access to the path '' is denied.
at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath)
at System.IO.FileStream.Init(String path, FileMode mode, FileAccess access, Int32 rights, Boolean useRights, FileShare share, Int32 bufferSize, FileOptions options, SECURITY_ATTRIBUTES secAttrs, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, FileOptions options, String msgPath, Boolean bFromProxy)
at System.IO.FileStream..ctor(String path, FileMode mode)
at ILRepacking.ILRepack.Repack()
at ILRepacking.ILRepack.Main(String[] args)

Method call instruction gets fixed-up wrong

Try following program before and after repacking:

using System;
public class MainClass {
    public static void Main() {
        Console.WriteLine( new A().Get() );
    }
}
public class A {
    public string Get() { return Get<object>(); }
    public string Get<T>() { return typeof(T).FullName; }
}

After packing, the program blows the stack. This is because the call to Get<T>() in A:Get() has been changed to a call to Get().

Allow to embed dlls as resource

Sometimes it is not possible to merge a dll. In example when the dll is directly referenced from Xaml. There is a simple trick to get rid of that dll anyway.

Simon Cropp introduced the solution here. https://github.com/Fody/Costura and it would be great addition to make ilrepack a tool which fits all needs.

Basically it embeds the dll as resource and adds a handler to AppDomain.AssemblyLoad which redirects the loading to the resources.

Permission problem when using ILRepack on mono (as non-root)

Hi,

Trying to use ILRepack (v1.25.0) on linux/mono as non-root fails due to permission errors. It appears it creates the merged assembly (althought with 000 permissions), but lateron tries to re-open it, and (obviouslly) fails, as it is unable to open a file with 000 permissions.

A permission change is already present on current code, but it looks like it needs to be done earlier.

mono ../../../packages/ILRepack.1.25.0/tools/ILRepack.exe /ndebug /out:Sam ple.merged.dll /target:library /verbose Sample.dll Other.dll

System.UnauthorizedAccessException: Access to the path "/temp/Sample/Sample.merged.dll" is denied.
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share, Int32 bufferSize, Boolean anonymous, FileOptions options) [0x00000] in :0
at System.IO.FileStream..ctor (System.String path, FileMode mode, FileAccess access, FileShare share) [0x00000] in :0
at (wrapper remoting-invoke-with-check) System.IO.FileStream:.ctor (string,System.IO.FileMode,System.IO.FileAccess,System.IO.FileShare)
at Mono.Cecil.ModuleDefinition.GetFileStream (System.String fileName, FileMode mode, FileAccess access, FileShare share) [0x00000] in :0
at Mono.Cecil.ModuleDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00000] in :0
at Mono.Cecil.AssemblyDefinition.Write (System.String fileName, Mono.Cecil.WriterParameters parameters) [0x00000] in :0
at ILRepacking.ILRepack.Repack () [0x00000] in :0
at ILRepacking.ILRepack.Main (System.String[] args) [0x00000] in :0

ILRepack removes MarshalInfo from method return types

Hi,

I found that ILRepack removes MarshalInfo from method return types. Because of this, the code that uses attributes like [return: MarshalAs(UnmanagedType.BStr)] crashes at runtime.

Small compiling issue

Hi,

After using the pachted Mono.Cecil version ILRepack almost compiles on my machine.

A single line stil gives a namespace collision (line 1693 in ILRepack.cs):

Mono.Cecil.CallSite ncs = new CallSite(Import(call_site.ReturnType, parent)) {

should imo read:

Mono.Cecil.CallSite ncs = new Mono.Cecil.CallSite(Import(call_site.ReturnType, parent)) {

After this change it compiles just fine and I can finally start supporting it in ILMerge-Gui at codeplex.

regards
wvd_vegt

il-repack munges calli signatures

When using il-repack on an assembly with calli signatures, I am getting runtime errors when running the merged assembly.

Looking a bit deeper, it appears that il-repack is incorrectly modifying the calli signature, causing a stack imbalance and (possibly) a calling convention mismatch when the signature corresponds to an unmanaged callsite.

For instance, when running il-repack on https://github.com/opentk/opentk:

// Before il-repack
    .method public static hidebysig 
           default void ClearColor (float32 red, float32 green, float32 blue, float32 alpha)  cil managed 
    {
        // Method begins at RVA 0xdcd90
    // Code size 18 (0x12)
    .maxstack 8
    IL_0000:  ldarg.0 
    IL_0001:  ldarg.1 
    IL_0002:  ldarg.2 
    IL_0003:  ldarg.3 
    IL_0004:  ldsfld native int[] OpenTK.Graphics.OpenGL.GL::EntryPoints
    IL_0009:  ldc.i4.s 0x97
    IL_000b:  ldelem.i 
    IL_000c:  calli signature-0x110001a2 // <-- correct: void(float, float, float, float)
    IL_0011:  ret 
    } // end of method GL::ClearColor

// After il-repack
    .method public static hidebysig 
           default void ClearColor (float32 red, float32 green, float32 blue, float32 alpha)  cil managed 
    {
        // Method begins at RVA 0xf8e40
    // Code size 18 (0x12)
    .maxstack 8
    IL_0000:  ldarg.0 
    IL_0001:  ldarg.1 
    IL_0002:  ldarg.2 
    IL_0003:  ldarg.3 
    IL_0004:  ldsfld native int[] OpenTK.Graphics.OpenGL.GL::EntryPoints
    IL_0009:  ldc.i4.s 0x97
    IL_000b:  ldelem.i 
    IL_000c:  calli signature-0x1100023b // <-- wrong: void()
    IL_0011:  ret 
    } // end of method GL::ClearColor

Unfortunately, monodis fails to decode the signatures, but the issue is still visible. All calli signatures have changed from the correct signature to "signature-0x1100023b" after repacking. This is obviously wrong and will invariably lead to a runtime crash. In this case:

[ERROR] FATAL UNHANDLED EXCEPTION: System.InvalidProgramException:
Invalid IL code in OpenTK.Graphics.OpenGL.GL:ClearColor (single,single,single,single):
IL_0011: ret   

I will upload a test case that reproduces this issue shortly.

ILRepack removes type forwards from main assembly

I'm trying to merge assembly (Assembly) which has some type marked as forwarded to another assembly (X, this assembly is not merged) and some other assembly (NewAssembly).

Assembly + X => merged

All

.class extern MyClass
{
    .class extern NewAssembly
}

are gone in merged assembly

Merging assemblies with a reference to Autofac

I am trying to ILMerge a project containing Autofac.dll and that fails on that dependency.

The command I am using is: ILRepack.exe /out:Merged.exe ILRepackTest.exe Autofac.dll

Expected outcome

To have ILRepackTest.exe and Autofac.dll to be merged to Merged.exe

Observed output is the following exception:

Mono.Cecil.AssemblyResolutionException: Failed to resolve assembly: 'System.Core, Version=0.0.0.0, Culture=neutral, PublicKeyToken=null'
at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name, ReaderParameters parameters)
at Mono.Cecil.BaseAssemblyResolver.Resolve(AssemblyNameReference name)
at Mono.Cecil.DefaultAssemblyResolver.Resolve(AssemblyNameReference name)
at Mono.Cecil.MetadataResolver.Resolve(TypeReference type)
at Mono.Cecil.ModuleDefinition.Resolve(TypeReference type)
at Mono.Cecil.TypeReference.Resolve()
at ILRepacking.ReferenceFixator.FixReferences(Collection`1 attributes)
at ILRepacking.ReferenceFixator.FixReferences(MethodDefinition meth)
at ILRepacking.ReferenceFixator.FixReferences(TypeDefinition type)
at ILRepacking.ILRepack.Repack()
at ILRepacking.ILRepack.Main(String[] args)

Note

My understanding is this is because Autofac is created as a portable class library. See https://github.com/autofac/Autofac/wiki/Frequently-Asked-Questions

ArgumentOutOfRange exception when using on Paket

I tried to update to latest ILRepack from mono, but get ArgumentOutOfRange exception.

A repro sample is at fsprojects/Paket#555 - just run build MergePaketTool from command promt.

We used 1.21.2.0 (downloaded from somewhere on the internet) and that worked fine.

Exception: FnPtr

When used with ZeroPeKind.

System.NotSupportedException: FnPtr
   at Mono.Cecil.MetadataImporter.ImportTypeSpecification(TypeReference type, Im
portGenericContext context) in c:\Users\peters\Documents\GitHub\il-repack\cecil\
Mono.Cecil\Import.cs:line 596
   at Mono.Cecil.ModuleDefinition.Import(TypeReference type, IGenericParameterPr
ovider context) in c:\Users\peters\Documents\GitHub\il-repack\cecil\Mono.Cecil\M
oduleDefinition.cs:line 702
   at ILRepacking.ILRepack.Import(TypeReference reference, IGenericParameterProv
ider context) in c:\Users\peters\Documents\GitHub\il-repack\ILRepack\ILRepack.cs
:line 1519
   at ILRepacking.ILRepack.CloneTo(FieldDefinition field, TypeDefinition nt) in
c:\Users\peters\Documents\GitHub\il-repack\ILRepack\ILRepack.cs:line 1271
   at ILRepacking.ILRepack.Import(TypeDefinition type, Collection`1 col, Boolean
 internalize) in c:\Users\peters\Documents\GitHub\il-repack\ILRepack\ILRepack.cs
:line 1857
   at ILRepacking.ILRepack.RepackTypes() in c:\Users\peters\Documents\GitHub\il-
repack\ILRepack\ILRepack.cs:line 905
   at ILRepacking.ILRepack.Repack() in c:\Users\peters\Documents\GitHub\il-repac
k\ILRepack\ILRepack.cs:line 704
   at ILRepacking.ILRepack.Main(String[] args) in c:\Users\peters\Documents\GitH
ub\il-repack\ILRepack\ILRepack.cs:line 229

Extension Method Issue

Sorry for not using a list, but I couldn't seem to find a reference for one being around.

I was wondering if you could help me with an issue. I'm using ILRepack in a project called Mulder to merge everything into one executing assembly. I've hit a snag in one part of how the code works. I'm using reflection and the codedom to compile and load an assembly at runtime and when using the merged executing assembly, it throws a null ref exception on this call due to the compilation failing. Adding some debug info to print the compilation errors, it shows that it can't resolve the Chop extension method that I've created in the Rules file. Unmerged, everything works as expected. Is there something special I need to do, when merged or is the merged assembly messing up the extension method since the compiler automagically creates the necessary code for the extension method?

To test, I've been developing under Mono 2.10.9. Just clone the Mulder repo and run './sake.sh' that will get the dependencies via nuget and compile. To merge, just run './sake.sh merge' after it compiles. The output will be placed in the artifacts directory, "bin" will hold the merged executable and "output" will hold everything before the merge. Now that you have the binary, run Mulder using Mono to create a site with "mono Mulder.exe create site test". Change directory into the test directory and run "mono Mulder.exe compile" and you will see the issue.

Thanks for your help and let me know if you have you any questions.

Problem with app icon

When packaging an application with IL-Repack, I have a problem with the icon size.

My original app has a 256x256 icon, however, when IL-Repack it to make it a standalone binary, the app icon is in 32x32 low quality.

Any thoughts ?

Thank you very much in advance for your reply.

Best regards

Flo

Getting "WARN: Duplicate Win32 resource, ignoring from VarFileInfo" block

Using as an example AppDomainPoshRunner at this particular commit:
https://github.com/zippy1981/AppDomainPoshRunner/tree/b35075c4123613dc98ca3cda7cdfdbab24c0d3b0

As part of the postbuild of the main executable of that solution, ILRepack is getting executed, The actual command is:

"C:\Users\Justin\Documents\Visual Studio 2010\Projects\il-repack\ILRepack\bin\Debug\ILRepack.exe"  /verbose "/out:C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner\\PoshRunner\bin\Debug\poshrunner.exe" "C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner\JustAProgrammer.ADPR.Console\bin\Debug\poshrunner.exe" "C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner\JustAProgrammer.ADPR.Console\bin\Debug\JustAProgrammer.ADPR.dll" "C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner\JustAProgrammer.ADPR.Console\bin\Debug\log4net.dll" "C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner\JustAProgrammer.ADPR.Console\bin\Debug\GetOptNet.dll"

I get the following output:

Unexplainable WARN: Duplicate Win32 resource, ignoring
Unexplainable WARN: Duplicate Win32 resource, ignoring
Unexplainable WARN: Duplicate Win32 resource, ignoring

I traced the message down to ILRepack.MergeEntry() and discovered that all three entries seemed to be the file version resource. It would seem to me that the sensible thing to do in this case would be to ignore the file version resource block on all but the main assembly, or provide a switch to specify the assembly with the desired version info similar to /attr:

unable to fix reference already merged into reference assembly

I am attempting to merge MassTransit 2.8 and Magnum into my own assembly.
Magnum has Newtown.Json merged already into itself, MassTransit references a different version.

Using the latest IL-Repack from Nuget
I get this error

WARN: Method reference is used with definition return type / parameter. Indicates a likely invalid set of assemblies, consider one of the following
WARN: - Remove the assembly defining Newtonsoft.Json.Utilities.<22393bc1-1b24-4381-8b42-1e880f8e1d97>IWrappedDictionary from the merge
WARN: - Add assembly defining Newtonsoft.Json.Utilities.<22393bc1-1b24-4381-8b42-1e880f8e1d97>IWrappedDictionary Newtonsoft.Json.Serialization.JsonDictionaryContract::CreateWra
pper(System.Object) to the merge

A type load expection if i try and use the DLL (enumerate the types in it)

ModuleDefinition.Import: 'Argument is out of range'

When trying to ILMerge logary: causiq/logary@ed75dd0 I'm getting this stack trace:

  mono tools/ILRepack/tools/ILRepack.exe --keyfile:src/signing/LogaryPublic.snk --ver: --xmldocs --internalize --parallel --index --verbose --targetplatform:v4 --out:Logary.dll --lib:tools/IKVM/lib src/Logary/bin/Release/FSharp.Actor.dll src/Logary/bin/Release/FSharp.Core.dll src/Logary/bin/Release/Intelliplan.JsonNet.NodaTime.dll src/Logary/bin/Release/Intelliplan.JsonNet.dll src/Logary/bin/Release/Newtonsoft.Json.dll src/Logary/bin/Release/NodaTime.dll src/Logary/bin/Release/policy.2.3.FSharp.Core.dll
System.ArgumentOutOfRangeException: Argument is out of range.
  at Mono.Collections.Generic.Collection`1[Mono.Cecil.GenericParameter].get_Item (Int32 index) [0x00000] in <filename unknown>:0
  at Mono.Cecil.ImportGenericContext.MethodParameter (System.String method, Int32 position) [0x00000] in <filename unknown>:0
  at Mono.Cecil.MetadataImporter.ImportTypeSpecification (Mono.Cecil.TypeReference type, ImportGenericContext context) [0x00000] in <filename unknown>:0
  at Mono.Cecil.MetadataImporter.ImportType (Mono.Cecil.TypeReference type, ImportGenericContext context) [0x00000] in <filename unknown>:0
  at Mono.Cecil.MetadataImporter.ImportMethod (Mono.Cecil.MethodReference method, ImportGenericContext context) [0x00000] in <filename unknown>:0
  at Mono.Cecil.ModuleDefinition.Import (Mono.Cecil.MethodReference method, IGenericParameterProvider context) [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.Import (Mono.Cecil.MethodReference reference, IGenericParameterProvider context) [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.CloneTo (Mono.Cecil.Cil.MethodBody body, Mono.Cecil.MethodDefinition parent) [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.CloneTo (Mono.Cecil.MethodDefinition meth, Mono.Cecil.TypeDefinition type, Boolean typeJustCreated) [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.Import (Mono.Cecil.TypeDefinition type, Mono.Collections.Generic.Collection`1 col, Boolean internalize) [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.RepackTypes () [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.Repack () [0x00000] in <filename unknown>:0
  at ILRepacking.ILRepack.Main (System.String[] args) [0x00000] in <filename unknown>:0

Expected outcome: no stack trace, a merged sweet dll before my feet.

How to reproduce:

git clone https://github.com/logary/logary.git
pushd logary
git checkout 1ec1f78
bundle # you need ruby, rubygems and bundler gem installed to run this
bundle exec rake pack
popd

Add an /additionAttributes switch to ILRepack

It would be nice to be able to specify additional assembly attributes on the command line. This is what I am envisioning

ilrepack /verbose /out foo.exe "/additionalAttributes:[module: InternalsVisibleTo("JustAProgrammer.ADPR.Tests, PublicKey=00240000048000009400000006020000002400005253413100040000010001006153fcf06927c23cdbd48c26da4080aac5fb48d90723963027cebf7225ba6ebb6c4526f51a30686abd68c6a72aa3352cf2e226e7c3b2646c1c3476ce1e79de19d0f60669c7c4ca13ed99775458bb1da974c3a11303d5846e09e23e7cfe60bd858f8defd0871c9e661dcb447fe8f29349ce754d41364ff39ced2a4daf86aac0aa");XmlConfigurator(ConfigFile = "ADPR.log4net.config", Watch = true)"

Basically the string should get split by the semicolons, each substring gets wrapped in [assembly:{0}] and the resulting assembly attributes should get compiled into the generated assembly. I've never used Cecil, so I'm not sure if this is the exact methodology.

Automatic cleanup of InternalsVisibleTo attributes

When the merged assembly is signed (or delay signed) and includes an unsigned one, there may be InternalsVisibleTo attributes with no PublicKey.

Those will prevent the assembly to properly load, they need to be removed.

Allow merging of Silverlight assemblies

In order to merge Silverlight assemblies in ILMerge, I have to pass the platform folder, e.g.

/targetplatform:v4,"C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0"

ILRepack currently does not support the specification of a platform folder. If I try it, I get

System.ArgumentException: Invalid TargetPlatformVersion: "v4,;C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\Silverlight\v4.0".
at ILRepacking.ILRepack.ParseTargetPlatform()
at ILRepacking.ILRepack.Repack()
at ILRepacking.ILRepack.Main(String[] args)

StackOverflowException

Hi, I just created a project that'll process my files after being built, but when I try to use ILRepack, I get "The process ended with a StackOverflowException".

ILRepack packer = new ILRepack();
// (I also set the path to the v4 or v4.5 framework right here, but that's not important

packer.Internalize = true;
packer.ExcludeFile = input.InternalizeExcludeFile;
packer.InputAssemblies = input.ToMerge;
packer.OutputFile = outputFile;
packer.LogVerbose = true;

try
{
  packer.Repack();
}
catch (Exception e)
{
  return false;
}

Nothing is logged, and this code is pretty much exactly the same as with ILMerge, which does work fine. The process exiting is no doing of mine, so it might be within ILRepack or Mono.Cecil?
Is my code missing something, as it works fine when the console application is run - just doing it with code like this doesn't.

Replicate WebILMerge feature of aspnet_merge

If you use aspnet_compiler to precomile your aspx/ascx views, you end up with an assembly for each view.

You can then use aspnet_merge (http://www.microsoft.com/en-us/download/details.aspx?id=8279) to merge all these assemblies together.

I've tried using ILRepack for this instead (as its incredibly quicker) except I've hit a problem. It seems aspnet_compiler performs some heresy, and uses intptr references to locations within the assembly's module. If you reflect an example compiled view, there are lines like:

IntPtr moduleHandle = UnsafeNativeMethods.GetModuleHandle(t.Module.FullyQualifiedName);

and

base.WriteUTF8ResourceString(__w, 0, 0x100, true);

(see System.Web.StringResourceManager.ReadSafeStringResource(Type t) and System.Web.UI.TemplateControl.WriteUTF8ResourceString(HtmlTextWriter output, int offset, int size, bool fAsciiOnly);

Now, if you decompile aspnet_merge.exe there's a modified version of ILMerge, WebILMerge which runs over the above method calls and adjusts the operands.

It looks like a very simple alteration, but I'm on the very limit of my understanding here.

If you look inside aspnet_merge.exe at System.Web.Compilation.WebCompilationVisitor.VisitMethodCall(MethodCall call); you can see how its adjusting the offset operands based on the index of the assembly being processed.

There doesn't appear to be an awful lot to this, any help in getting started on this would be great :)

It would seem all the code for consideration (not much at all) is inside:
System.Web.Compilation.WebCompilationVisitor in aspnet_merge.exe

ILRepack library conflicts with Mono.Cecil.

ILRepack library itself contains a re-packed version of Cecil which is not even internalized. It causes conflicts with the Mono.Cecil package.

I propose not bundling any libraries with the ILRepack library. The developer can do that himself if he wants to.

After merging diffrenet platforms merged assemby has multiple references to .NET Fx libraries.

After merging NHibernate (build .NET 4) with ReLinq (.NET 2) and Antlr v3 (.NET 2) with target platform as .NET 4 ( /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0" ) NHibernate.dll has following dependencies

// mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Transactions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// Iesi.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
// System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

But ilmerge adjust references

// System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Data, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Xml, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Configuration, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a
// System.ServiceModel, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// System.Transactions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089
// Iesi.Collections, Version=4.0.0.0, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
// System.Xml.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089

In this case concrete folder in /targetframework option does not make any sense.

Runtime destabilization exception

I'm using ILRepack in a project that emits IL when converting an anonymous object to a Dictionary<string,object>. Running the merged assembly under Mono and OSX works fine, but under Windows and .NET gives a runtime destabilization exception. The code un-merged works fine under Windows and .NET. I then had a friend merge the assemblies using ILMerge and the app runs fine under Windows and .NET.

Stackoverflow problem

We're trying to put two assemblies into one assembly:

The following command has been used:
.\ilrepack.exe /union /ndebug /copyattrs /xmldocs /closed /targetplatform:"
v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5" /out:C:\Temp\OutPutPath\Compile\b
in\X.Web.Z_Temp.dll /delaysign /keyfile:"C:\Temp\OutPutPath\TempKey.snk" C:\Temp\OutPutPath\Compile\bin\X.Web.Z.dll C:\Temp\OutPutPath\Compile\bin\X.Web.ZMarkup.dll /log:C:\Temp\OutPutPath\MyLog.txt

This is what we get:
INFO: Adding assembly for merge: C:\Temp\OutPutPath\Compile\bin\X.Web.ZStudio.dll
INFO: Adding assembly for merge: C:\Temp\OutPutPath\Compile\bin\X.Web.ZMarkup.dll
INFO: Processing references
INFO: Processing types
INFO: Merging

Process is terminated due to StackOverflowException.

Can't build with gradle

➜  il-repack git:(master) /usr/local/bin/gradle

FAILURE: Build failed with an exception.

* Where:
Build file '/Users/dev/haf/il-repack/build.gradle' line: 29

* What went wrong:
A problem occurred evaluating root project 'il-repack'.
> Could not find method msbuild() for arguments [build_8jltip6poe9pr7lrk8vheqo2$_run_closure1@18dd7404] on root project 'il-repack'.

* Try:
Run with --stacktrace option to get the stack trace. Run with --info or --debug option to get more log output.

BUILD FAILED

Total time: 4.153 secs

Doesnt build

Hi,

I'm trying to investigate a bug where it exits with no output and without doing anything, but i cant get the master branch to build. Should it?

getting: Error 1 'Mono.Cecil.ModuleDefinition' does not contain a definition for 'ImportWin32Resources'

Feature: Delete merged files after successfull build

*.xml
*.pdb
*.config

If the respective flags are set, that is.

Change NuGet package to a tools package

The current NuGet package has ILRepack.exe in the \lib folder. This means that ILRepack is has to be installed into a project and it gets referenced as a runtime dependency of that project.

The typical use case for ILRepack is in a build script, i.e. a build time dependency only, so it should not be added as a reference in any project.

ILRepack should be installed as a tools package, with ILRepack.exe residing under a \tools folder in the NuGet package. This way, project files will be left unchanged after installing the package but the executable will be present for use in the build script as required.

Feature suggestion: Provide a comma-separated list of assemblies to be internalized

See peters/ILRepack.MSBuild.Task#2

Starting ILPack compiled on mono throws exception

Unhandled Exception:
System.TypeLoadException: Could not load type 'ILRepacking.ILRepack' from assembly 'ILRepack, Version=1.25.0.0, Culture=neutral, PublicKeyToken=null'.

Steps to repro:

1. Download the code
2. Build the code
3. Run ILRepack.exe with mono

Expanding on /internalize functionality

This isn't an issue, per se, but I couldn't find a better place to put it.

I'm working on a project that involves merging several individual assemblies into a single DLL.
I ran into two problems:

1. Internalization was pretty braindead: Internalize all types not in the primary assembly.

   This created a problem because I had some things like this:

   MainAssembly:
       public class Foo : Bar
       {
           public Baz baz;
       }
   
   OtherAssembly:
       public class Bar {}
       public class Baz {}
   

   The internalization of Bar and Baz created a mess with Foo.

2. For various reasons, there were some public methods on Foo weren't appropriate to expose externally, but had to be public when everything was split across multiple assemblies due to various limitations.

   I needed a way to change those methods to 'internal' when they no longer needed to be used.

I created a fork for ILRepack here: https://github.com/Stevie-O/il-repack/commits/smartmerge

and added the following features:

• Extended the /internalize exclude file syntax to support the following:

  • Inverted rules (if a type matches the regex, it will be internalized, even if it is in the "main" assembly)

  • Internalization of individual class members

    With a properly constructed line, individual members (properties, fields, methods, events) of a type may be changed to internal.

• Automatically exclude types from internalization if they are exposed by another, non-internalized type somehow:
  • An exposed type exposes its base classes.
  • A public field exposes the field's type.
  • A public property exposes the property's type
  • A public method exposes the return type and all parameters' types.
  • A public event exposes the delegate type for the event's handlers.

If someone looks at the code and thinks it's decent enough, I'll create a pull request.

Cannot merge for .NET 4.0 on a machine with .NET 4.5

The problem is described in detail at http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx

I've tried to use the /targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0" switch with ILRepack but I get

System.ArgumentException: Invalid TargetPlatformVersion: "v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0".
at ILRepacking.ILRepack.ParseTargetPlatform()
at ILRepacking.ILRepack.Repack()
at ILRepacking.ILRepack.Main(String[] args)

Unfortunately, until this is fixed, I don't think I'll be able to use ILRepack to merge .NET 4.0 assemblies. At least, not on any machine with .NET 4.5 installed, which happens to now be all my machines :-(.

/out should either be more forgiving or complain

It seems /out foo.dll silently fails while /out:foo.dll works fine. Examples:

Working

C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner>k.1.19\tools\ILRepack.exe /verbose /out:PoshRunner\bin\Debug\poshrunner.exe JustAProgrammer.ADPR.Console\bin\debug\poshrunner.exe JustAProgrammer.ADPR.Console\bin\debug\JustAProgrammer.ADPR.dll JustAProgrammer.ADPR.Console\bin\debug\log4net.dll
WARN: Duplicate Win32 resource, ignoring
WARN: Duplicate Win32 resource, ignoring

Silent Failure (no file produced)

C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner>k.1.19\tools\ILRepack.exe /verbose /out PoshRunner\bin\Debug\poshrunner.exe JustAProgrammer.ADPR.Console\bin\debug\poshrunner.exe JustAProgrammer.ADPR.Console\bin\debug\JustAProgrammer.ADPR.dll JustAProgrammer.ADPR.Console\bin\debug\log4net.dll


C:\Users\Justin\Documents\Visual Studio 2010\Projects\AppDomainPoshRunner>

To be cconsistant with msbuild /p and /t the lack of a colon should cause an error.

Cecil bug something to do with anonymous types

It looks like cecil import.cs was updated relatively recently in this project. I am now getting an invalid operation exception related to anonymous types. Please see my posting with stack trace and state information here: jbevain/cecil#124

You might want to revert back some code until the issue is fixed.