[Mono-devel-list] merging two assemblies and related problems

Eyal Alaluf eyala at mainsoft.com
Fri May 20 07:30:34 EDT 2005


Hi, Vladimir.

There is one 5 you didn't try. It's called MBEL <http://www.cs.arizona.edu/mbel>
It's a Java based solution (of al things). It is capable of reading IL
assemblies manipulating them and writing them back. Causing it to merge two
assemblies requires definitely an effort but should be possible.
We use MBEL to generate a stub .Net DLL froma Java jar file and it quite decent
apart from the factv that it consumes tons of memory.

Eyal.

On Fri, 20 May 2005, Vladimir Vukicevic wrote:

> Date: Fri, 20 May 2005 02:36:34 -0700
> From: Vladimir Vukicevic <vladimirv at gmail.com>
> To: mono-devel-list at ximian.com
> Subject: [Mono-devel-list] merging two assemblies and related problems
>
> I've brought up this problem in the past, but i'm again trying to find
> a decent solution for this using mono.  The problem is pretty
> straightforward:  I have two assemblies, A.dll and B.dll.  A.dll is
> autogenerated using System.Reflection.Emit; B.dll is compiled from C#
> source.  A.dll needs to access a custom attribute class that's defined
> in B.dll.  So far, here are the approaches that I've tried, and the
> problems I've encountered:
>
> 1) Use ILMerge (http://research.microsoft.com/~mbarnett/ilmerge.aspx).
>  Works great; binary only, Windows only.
>
> 2) Use PERWAPI (http://www.plas.fit.qut.edu.au/perwapi/Default.aspx).
> It seems to work under .NET 1.1 on windows; under mono 1.1.7 I see
> strange bugs (usually an infinite loop as it's trying to write an
> assembly out on anything but the simplest assemblies).  It also balks
> on some mono-generated assemblies, usually finding non-zero values
> where it was expecting to just read zeros.
>
> 3) Use RAIL (http://rail.dei.uc.pt/).  A simple test of
> RAssemblyDef.LoadAssembly("foo.dll").SaveAssembly("bar.dll") results
> in:
> ** ERROR **: file reflection.c: line 835 (method_encode_clauses):
> assertion failed: (ex_info->handlers)
>
> 4) Use monodis on both A.dll and B.dll, massage the output a bit, and
> reassemble with ilasm -- basically remove the extern reference from
> A.dll to B.dll, remove the foreign assembly reference from the custom
> attribute usage in A.dll, and tack on most of B.dll's disassembly to
> the end.  The problem here is that A.dll uses the "calli" instruction,
> and monodis/ilasm can't round-trip the calli signatures... the output
> has: "IL_0008:  calli signature-0x11000001", signature-0x11000002, and
> so on.  ildasm appropriately balks.
>
> Is there a #5 that I'm missing that I haven't tried?  Out of the above
> problems, fixing monodis/ilasm to round-trip signatures would probably
> be the most straightforward, though that's the least elegant solution.
>  Fixing the assertion failure with RAIL may or may not be difficult; I
> haven't looked into what exactly is happening in much detail.  PERWAPI
> might be making too many assumptions about the PE files it operates
> on, and may be failing  due to .NET-only quirks.
>
> A final last-ditch effort may be to just use S.R.E to generate the
> classes/methods that B.dll provides directly into A.dll.  Maybe I
> could use Cecil to read B.dll and generate appropriate output using
> S.R.E.?
>
> Any ideas would be appreciated.
>
> Thanks,
>     - Vladimir
> _______________________________________________
> Mono-devel-list mailing list
> Mono-devel-list at lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-devel-list
>




More information about the Mono-devel-list mailing list