In addition to types with static members, many languages have the notion of data and methods that are not part of a type at all. These are referred to as global fields and methods.
The simplest way to understand global fields and methods in the CLI is to imagine that they are simply members of an invisible abstract public class. In fact, the CLI defines such a special class, named <Module>, that does not have a base type and does not implement any interfaces. (This class is a top-level class; i.e., it is not nested.) The only noticeable difference is in how definitions of this special class are treated when multiple modules are combined together, as is done by a class loader. This process is known as metadata merging.
For an ordinary type, if the metadata merges two definitions of the same type, it simply discards one definition on the assumption they are equivalent, and that any anomaly will be discovered when the type is used. For the special class that holds global members, however, members are unioned across all modules at merge time. If the same name appears to be defined for cross-module use in multiple modules then there is an error.
In detail:
-
If no member of the same kind (field or method), name, and signature exists, then add this member to the output class.
-
If there are duplicates and no more than one has an accessibility other than compilercontrolled, then add them all to the output class.
-
If there are duplicates and two or more have an accessibility other than compilercontrolled, an error has occurred.
[Note: Strictly speaking, the CLI does not support global statics, even though global fields and methods might be thought of as such. All global fields and methods in a module are owned by the manufactured class "<Module>". However, each module has its own "<Module>" class. There's no way to even refer, early-bound, to such a global field or method in another module. (You can, however, "reach" them, late-bound, via Reflection.) end note]