Module Linking Through Round-Tripping

Now let’s assume that instead of writing the amendment file in ILAsm, you wrote it in another high-level language, compiled it to a module, and then disassembled it. Can you do that? Yes, you can, and it means that round-tripping can be used for linking several modules together to form one. The original language used to write each module does not matter as long as all the modules are pure-IL. The modules must be pure-IL simply because any mixed-code module will fail to round-trip.

Brad Abrams, a program manager I work with, has written a small tool called “Lame Linker,” which performs managed module linking through round-tripping. You can have a look at this tool at GotDotNet, http://www.gotdotnet.com/userarea/keywordsrch.aspx?keyword=Lame%20Link. As Brad explains it, he calls his linker “lame” because it doesn’t have many of the features of a good linker. Lame or not, this linker is used rather extensively and has proven to be a useful tool.

The basic problem with linking multiple modules through round-tripping is that you inevitably run into duplicate declarations. When you write amendment files in ILAsm, you don’t need to make sure that these files compile per se; they must compile together with the disassembly of the original module. But each module you link has been compiled per se, and a significant part of its metadata overlaps with the metadata of other modules being linked.

Let’s review the potential effects of multiple declarations of different metadata items.

Multiple Assembly declarations (.assembly) should be avoided. The ILAsm compiler ignores repetitive Assembly declarations as long as the assembly name is the same, but if one of any subsequent declarations specifies a name that differs from that of the first declaration, the compiler diagnoses an error.

Multiple AssemblyRef declarations (.assembly extern) are harmless. The ILAsm compiler ignores them. The same is true for Module declarations (.module), ModuleRef declarations (.module extern), File declarations (.file), and ExportedType declarations (.class extern).

Duplicate ManifestResource declarations (.mresource) should be avoided. The ILAsm compiler will not emit a new ManifestResource record for each declaration encountered, but it will incorporate a copy of the respective managed resource for each .mresource declaration in the output PE file. The resulting PE file will perform as expected, but it will be bloated.

Duplicate member declarations (.field, .method, .event, .property) must be avoided because their presence leads to compilation failure. Duplicate member declarations can happen in two cases only: if you declare a type in one module and amend it in another, or if you declare global fields or methods. I can’t say how likely the first scenario is—somehow, the feasibility of declaring part of a type in one module and another part in another module, with the parts overlapping, escapes me. But the second scenario is very likely indeed: you usually don’t pay much attention to naming global fields and methods because they are an “internal affair” of the module. But when you link several modules together to form one, all global fields and methods from each module wind up as globals in the resulting module.

Multiple declarations of the module entry point (.entrypoint) must be avoided as well, for they also cause compilation failure.

If several of your original modules use mapped fields, you should watch for duplicate data declarations. ILDASM automatically generates the data labels—D_<data_RVA> for usual data and T_<data_RVA> for TLS data—when it disassembles each original module, so the data labels are almost guaranteed to overlap. Duplicate data labels cause compilation failure.

The Lame Linker I mentioned earlier eliminates multiple Assembly declarations, but nothing else.

The list of hazards to watch for in the process of linking through round-tripping looks endless, but in fact all these limitations are reasonable, and their analogs can be found in the traditional linking of object files. Actually, traditional linking is even less tolerant of duplicate definitions. And avoiding (or getting rid of) the dangerous duplications is not rocket science.

Module linking is necessary whenever you want to create a single-module assembly from a multimodule assembly. And it does not matter how you came into possession of the multimodule assembly in the first place. Perhaps you developed different modules using different languages. Or perhaps you split your application into subsystems to be developed independently. Or perhaps you split your application for independent development, and the developers of each subsystem chose their own development language.