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

[Vladimir Vukicevic]

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