Does an ILSplit.exe exist, equivalent to ILMerge.exe, or how could this be made?

Question

Does a utility for splitting a single .NET assembly into a subset of the full assembly exist? I.e. the "functional inverse" of ILMerge.exe?

This tool, of course, would be difficult to produce if it had to track dependencies etc. between classes, functions and such.

However, what I am looking is for a case where I have a very big (hundreds of MB) mixed mode assembly with mostly static classes and static methods, basically just a function library. Although, with some DLLMain initialization and similar.

What I would like is to be able to specify a list of static methods upon specific static classes that I want to keep in the subset assembly. Technically, this should be possible as an assembly is just binary information with a standardized format.

So does this exist or how could this be made? Or why would this be impractical?

Marigolde

Looks like a bad idea. What about if you build a project P.exe that reference A.Dll, but the A's function has been moved to B.dll? You should refactor the DLL's at source code level, once for all, instead of tweaking thinks like this. – Gaylegayleen

Yes, of course, this is the recommended approach but for a number of reasons it would be more ideal to do this afterwards instead. Due to mixed mode nature I am guessing this will be extremely difficult to do. The size comes from linking in massive native libs. Your comment also implies I have access to source code. – Marigolde

Answer 1

No, very high odds that this tool doesn't exist. Albeit that the absence of the tool can never be disproved positively.

These IL rewriting tricks don't work on mixed-mode assemblies anyway, ILMerge doesn't support them either. Such assemblies don't just contain IL, they also have machine code and a relocation table. There is no simple way to pick machine code apart, mostly because it isn't just pure code but also contains data. Like jump tables for a switch-statement. Also the reason that programmers that write code in a native language don't bother with obfuscators. Decompiling machine code is a major time sink and always imperfect.

So, for one, it is likely that your assembly is large because it has a lot of native code. You will need to tackle this at the project level and split up this mongo project into smaller ones, distributing the source code between them. That's work. And not exactly always easy, linker errors are a common scourge when you do this. And you're likely to have to change code declarations so they can be exported. Only one way to do this, start at the beginning and split off a sub-section first so now you have a not-so-big assembly and a small one. Rinse and repeat. Do beware the cost, many assemblies make the cold start of a program slower.

Parke

To the second part of your answer: the OP implied that they don't have source code for the assembly. – Expectorate