The following is a list of known limitations of the MBEL library. Some or all of these issues will be addressed in future versions/releases of MBEL.

     Though .NET modules are primarily written in MSIL, they may contain native machine code as well. Managed C++, for example, makes extensive use of this particular functionality. For simplicity and for processor-independence, MBEL does not contain APIs for manipulating native machine code. It can, however, still manipulate the remaining portions of a module containing native code. Much care is taken to ensure that the native code is undisturbed by the other manipulations, so that it can be re-emitted without concern for its correctness.

     Though the API for MBEL is designed to opaquely emit .NET modules through the Module class, it is not currently capable of emitting the same Module object more than once. Thus, if a given Module object is emitted back to disk, attempting to emit it again will give incorrect behavior. Of course, this can be circumvented by re-parsing the file to get a different yet equivalent Module object.

     Due to the internal structure of custom attributes in a .NET module, MBEL does not provide facilities for creating and adding new custom attributes on metadata. Though it would be possible for a user to create a new custom attribute class (i.e. a TypeDef that extends System.Attribute), that attribute could not then be applied to any structure within the module.

This is alpha software, please report all feedback, bugs, etc. to mbel@cs.arizona.edu