An introduction to Mono.Merge 12
There’s something I’ve been willing to do since I started Cecil. Imagine a tool that takes a set of assemblies, and merge them in a single one. That’s not too hard to do using Cecil, but I’ve never took the time to do it. Well, thanks to Alex Prudkiy, who also contributed a few patches to the linker, we now have a brand new monomerge tool.
Let’s take an easy example. This new monomerge tool have only one dependency beside of the core, Mono.Cecil. That means that if you want to send your tool to someone, you’ll have to ship a copy of Mono.Cecil.dll also. But why not shipping only one assembly?
Let’s merge the merger! As usual, I’m pretty disappointed I can’t show you some meaningful and colorful screen shots, but heh, that’s a command tool, let’s have a look at my console snapshot.
jbevain@avalon:/tmp/merge$ ls -l total 364 -rwxr-xr-x 1 jbevain jbevain 337920 2006-10-31 14:02 Mono.Cecil.dll -rwxr-xr-x 1 jbevain jbevain 24064 2006-10-31 14:06 monomerge.exe drwxr-xr-x 2 jbevain jbevain 4096 2006-10-31 14:15 output jbevain@avalon:/tmp/merge$ ~/devel/bin/mono monomerge.exe -out output/monomerge.exe monomerge.exe Mono.Cecil.dll jbevain@avalon:/tmp/merge$ cd output && ls -l total 348 -rw-r--r-- 1 jbevain jbevain 351744 2006-10-31 14:16 monomerge.exe jbevain@avalon:/tmp/merge/output$ ~/devel/bin/mono monomerge.exe Mono CIL Merge monomerge [options] -out result_file primary assemly [files...] --about About the Mono CIL Merge --version Print the version number of the Mono CIL Merge -out Specify the output file Sample: monomerge -out output.exe input.exe input_lib.dll jbevain@avalon:/tmp/merge/output$Here we are, we have now a single monomerge.exe assembly, which contains both the merger and Mono.Cecil. Pretty neat isnt’it? Hmm, I’m sure you already seen where I want to go with this. Imagine a tool chain like:
- use the Linker to reduce the size of a set of assemblies
- use the Merger to ship them in a single assembly
- use mkbundle to ship this single assembly plus the linker core in a single binary
That’s the less space wasting solution I know for Mono and embedded users. Pretty cool huh? Anyway, if you want to give it a try, the code now lives in the /cecil/merge module of the SVN
Thanks Алексей for this tool!
Trackbacks
Use the following link to trackback from your own site:
http://evain.net/blog/articles/trackback/278
I’ve been waiting for such a tool for a long time. ILMerge is a “competing” tool from Microsoft, but I find it a lacking in functionality and it’s great to have an open source alternative. Keep up the good work!
Yeah I know ILMerge, I’ve been using it long times ago. But beside being proprietary, and thus, not easily modifiable, I kind of remember that’s it’s using some pinvoke calls to Win32 or .net runtime assemblies, that makes it unusable on Mono.
Now, that you can merge everything… can you produce a mono program, that doesn’t need mono at all? Is corlib an il assembly? Can you merge it also? Can you make aot compile with the merged one? Main point -> can you produce standalone elf / exe binary from mono assembly?
Viraptor:
Well, you can use mkbundle to produce a single binary self containing Mono and your desired set of assemblies.
Viraptor: Yes corelib is an IL assembly, however it uses lots of internal-calls into the runtime, which means that you also have to embedd the runtime/Jit into the resulting EXE. So even if you get this to work it will result in Apps that are relatively large and the only advantage you get is not being dependent on a preinstalled mono. And the price you pay for that may be relatively large: If more than one .Net app is used you will need far more memory and disk space and even a little bit more CPU for initialization tasks.
The screen shots might be a little easier to read if you:
s/+ [0-9]+ jbevain jbevain ([0-9]) [ ] [^ ]+ /\1/g s/^jbevain@avalon:/tmp/merge/?(.*)$/\n<font color=yellow>\1<\/font>/g
>Re: “it will result in Apps that are relatively large”
Demo, demo, demo :) (ie. I’m quite curious to see the result of the whole workflow, but to lacy to test)
(btw. thanks for making me log into a machine to test the re-patterns, since it made me discover a local Hejlsberg talk this Friday)
I have read the source. It is is really simple thanks to cecil. I enjoy a lot to read all mono source for moment. Hope a day It will serve to help mono (I have ever done a winform gui for gendarme).
Hi, just a few comment from a little bit of testing:
For simple assemblies it seems to work well, however it seems to fail if:
1) The assembly contains pointers 2) The assembly contains any Marshalling Interop 3) Some other issues (like class not found in various forms)
You can easily reproduce this when trying to merge the mono class libraries into a file. For most of these assemblies it doesn’t work at all. From the stacktrace it also seems as if some problems might actually be in Cecil itself.
You have the author’s mail in the headers to submit bugreports.
Foxfire: This is the whole problem with this type of tools. They are never 100%. I used ilMerge in one of my projects and found later down the track that there was a problem with how it had merged them together. I didn’t really find out what the problem was, but the problem did not occur if I used the original separate assemblies.
Bla bla bla. Do you know any tool EVER sure at 100%. Beside your Hello World?
Using Mono.Merge, you can actually debug the problem and fix the tool yourself. Which you can not using ILMerge. But don’t blame us for your inability to found the cause of the problem.
Mono.Merge is really young, it’s not even released yet, don’t come and whine that’s not working. We know that.
There are bugs, Alex and I are going to fix them. When it will really be usable, we’ll release it. Period.
jb: I did not mean any disrespect or critisism of your work when I said that these tools are not guaranteed to be 100%. I find the work you’ve done with Cecil & the other tools to be quite fantastic & often much better than closed-source solutions. Assembly manipulation is not yet an exact science and I just wanted to highlight that for not-so-simple cases, there might be issues that sometimes might not be easy to identify.
Keep up the great work.