Classes and Mapping in CLI and WMI

  • Article

The concept of class definitions is at the heart of programming in managed code. WMI is also based on the same basic principal of class definitions; however, WMI has its own grammar for describing classes (MOF), as well as an API for defining classes programmatically.

The basic goal of instrumentation is to surface information that might be useful for tools trying to manage an application. Other instrumentation technologies, such as tracing or log files, restrict applications to providing a raw block of unstructured diagnostic information (such as a simple string). Instrumentation with WMI allows very rich, schema-based information to be surfaced. To do this, applications define a set of WMI classes that describe the information that they will provide through instrumentation. These class definitions are published through WMI, and are accessible to management tools. The class definitions should be available at any time after the application is installed, and not just when the application is running. At run time, the application provides the actual data described by the WMI classes.

The WMI model of class definitions that are discoverable at any time is very similar to the CLI model of managed classes and metadata. The System.Management.Instrumentation namespace takes advantage of the similarities between WMI classes and CLI classes to allow developers to define WMI classes by writing class definitions in managed code. This means that a managed code developer already knows how to define WMI classes without learning anything new.

In general, the managed code classes map to WMI classes. In some cases, WMI classes have characteristics that are not describable in managed classes. For example, WMI primitives can be null, but Common Type System (CTS) value types cannot be null. The System.Management.Instrumentation namespace does not attempt to allow developers to describe WMI classes that represent things that are not describable in the CTS.

The following list describes some of the basic ways that managed classes map to WMI classes:

  • Only public managed classes can be mapped to WMI classes, and only the public members can be mapped to the WMI class definition.

  • Primitive value types map very nicely to WMI CIM types.

    In addition, the reference types String, DateTime, and TimeSpan map to the equivalent WMI CIM types.

  • Arrays in managed code map to arrays in WMI class definitions.

  • The CLI distinguishes between value types and reference types.

    WMI does not have this distinction, and both can be mapped to a WMI class definition.

  • WMI supports embedded objects as well as references to other objects.

    In the first version of System.Management.Instrumentation, only embedded objects are supported. For managed classes that contain value type members, it is logical that these are mapped to WMI classes that contain an embedded object. Managed classes that contain reference type members are also mapped to WMI classes with embedded objects, but future versions might allow the developer to specify that runtime references should be represented by WMI references.

  • Inheritance hierarchies of managed classes are represented by inheritance hierarchies in WMI.

  • In the first version of System.Management.Instrumentation, WMI default values cannot be represented in managed code.

    Field initializers on managed class fields are not mapped to WMI default values.

  • WMI does not distinguish between fields and properties.

    In a managed class definition, both fields and properties are mapped to WMI properties.

  • The namespace of a managed class definition has no relation to the namespace of the WMI class definition.

    In other words, a managed class might be defined in the MyCompany.MyApplication namespace, and the related WMI instrumentation class might be defined as the WMI namespace root\MyCompany.

  • WMI supports a concept similar to attributes, called qualifiers.

    In System.Management.Instrumentation, there is no mapping between managed code attributes and WMI qualifiers. There are attributes in the System.Management.Instrumentation namespace, but these are not represented by qualifiers on the WMI class definition. To allow mapping in between the two, the System.Management.Instrumentation namespace defines several attribute classes allowing developers to define the mapping in a declarative syntax, instead of through the use of a new API. This again leverages a skill that is already familiar to managed code developers. As mentioned, instrumentation consists primarily of two stages: class definition at design time, and data provision at runtime. The use of attributes is crucial to the first stage, and allows the managed class metadata to completely describe the instrumentation schema. The metadata is then used to create the WMI schema that is visible to management tools.

See Also

Instrumenting .NET Framework Applications Using System.Management | Exposing Management Events | Exposing Management Data | Inheritance | Registering the Schema for an Instrumented Application