Principles of Round-Tripping

The round-tripping of managed PE files includes two steps. The first step is to disassemble the PE file into an ILAsm source file and the managed and unmanaged resource files:

ildasm MyModule.dll /out:MyModule.il

You can forgo the /ADV option in this case. You usually don’t need advanced presentation options for round-tripping, since the output is intended for the ILAsm compiler.

The second step of round-tripping is to invoke the ILAsm compiler to produce a new PE file from the results of the disassembler’s activities:

ilasm /dll MyModule.il /out:MyModuleRT.dll /res:MyModule.res

The command-line options of the ILAsm compiler are listed in full in Appendix D. The most important of these options are the following:

The /OUT:<file_name> option specifies the name of the resulting PE file. The default name is the name of the first source file with the extension DLL or EXE.
The /DLL option creates a dynamic-link library module. The default is to create an executable (EXE) PE file. The file extension of the output file does not matter: if you specify /OUT:MyModule.dll and neglect to specify /DLL, the result is an executable PE file (EXE) named MyModule.dll. You can try to sell such a PE file to Barnum, but you won’t be able to do much more than that.
The /RES:<unmanaged_resource_file_name> option indicates that the compiler must incorporate the specified unmanaged resource file into the PE file. The managed resources are specified in the ILAsm source code and are picked up by the compiler automatically, whereas an unmanaged resource has no metadata representation and hence must be explicitly specified in a command-line option.
The /DEBUG option has two effects: a PDB file is created, and the [mscorlib]System.Diagnostics.DebuggableAttribute custom attribute is assigned to the Assembly or Module metadata record. See “Compiling in Debug Mode,” later in this chapter, for more details.
The /KEY:<private_key_file_name> or /KEY:@<private_key_source_ name> option generates the strong name signature of the PE file. Only the prime module of an assembly can carry a strong name signature. If you are round-tripping a strong name signed prime module and don’t have the private key—if, in other words, it’s someone else’s assembly—you can leave the module unsigned. In this case, you’ll be able to use it as a private assembly only. If you decide not to sign the module, you must delete or comment out the .publickey directive in the .assembly scope. Otherwise, you will produce a delayed-signed assembly—that is, an assembly that must be strong name signed at some moment after the compilation and before it can be used. (Alternatively, you can sign the prime module with your own private key and say that it was your own assembly all along. Do this only if you find true joy in litigation.)

A few items that might be present in a managed PE file don’t survive round-tripping. For example, any embedded native code is lost. The exceptions to this rule are the tiny pieces of native code that are automatically generated during the compilation: the common language runtime startup stub and the unmanaged export stubs. Strictly speaking, even these tiny pieces don’t really round-trip: they are generated anew rather than reproduced from the disassembly.

Another item that does not survive round-tripping is data-on-data, which is a data constant containing the address of another data constant. Fortunately, this kind of data is rather rare and not very useful, thanks to the strict limitations the runtime imposes on operations with unmanaged pointers. Among the compilers producing pure-IL modules, only the ILAsm compiler is capable of generating such data.

Local variable names survive round-tripping only if the PDB file accompanying the original PE file is available. The local variable names are part of the debug information rather than the metadata.