Instrumenting .NET Framework Applications with System.Management

  • Article

The goal of the System.Management.Instrumentation namespace is to minimize the work involved in enabling an application for management. The namespace also makes it easy to expose events and data and use relationships between management objects.

One of the major benefits of WMI is that it allows application developers to access information from diverse sources through a common architecture. The source of the information might be a piece of hardware, operating system, or software application. The information provided by the data source is known as instrumentation. The purpose of instrumentation is very similar to the purpose served by the instrument panel on your car's dashboard. Your car has gauges that let you monitor information about various components (such as the fuel gauge), and indicators that tell you to when various events occur (such as the open door alarm). All this instrumentation allows you to make decisions on how you drive and maintain your car. Computer components that provided instrumentation allow management software to diagnose and correct problems in an enterprise computing environment.

WMI is the instrumentation standard used by management applications such as Microsoft Operations Manager, Microsoft Application Center, and many third-party management tools. The Windows operating system is instrumented with WMI, but developers that want their own products to work with management tools must provide instrumentation in their own code. The System.Management.Instrumentation namespace allows managed code developers to surface information to WMI-enabled tools.

Exposing an application's objects for management should be intuitive for .NET Framework developers — the WMI schema is object-oriented and has many traits in common with the .NET Framework metadata — code classes map to schema classes, properties on code objects map to properties on WMI objects, and so on. Therefore, it is easy to instrument managed code applications to provide manageability. Developers familiar with writing managed code already have the skills to provide instrumentation through WMI. There is almost no learning curve, and in particular, there is no need to understand the WMI client API.

Application information for management is mostly exposed by making declarations — no extensive extra coding is required. The developer marks the objects as manageable by using the .NET Framework attribution capabilities and defines how they map into the System.Management.Instrumentation schema. The developer can also derive the class from a common System.Management.Instrumentation schema class, in which case the attribution and mapping is already done.

When the application has been instrumented, objects and events can be discovered, monitored, and configured through WMI and the management applications developed by the extensive WMI customer base (such as Computer Associates, Tivoli Systems, Inc., BMC Software, Hewlett-Packard, and so on). The managed-code events marked for management are automatically raised as WMI events.

Security support in System.Management is tightly linked to security in WMI. In WMI, client access to information is controlled via namespace-based security.

As a convenience during development, instrumentation data will be published to the root\default namespace, if not otherwise specified by the Instrumented attribute on the assembly. However, it is recommended that developers override this default and define a specific namespace for their application, so that it can be managed independently.

The recommended practice is:

  • Create a separate namespace for your particular assembly, group of assemblies or application, having similar security requirements. Use the company name and software product name in your namespace definition, in order to ensure uniqueness. For example, instrumentation from your application can be published into the "root\<your company name>\<your product name>" namespace. Potentially the namespace hierarchy can also contain version information (see more about versioning in the schema registration section).
  • Administrators can use WMI Control to specify security constraints for a specific namespace. To invoke WMI Control, right-click "My Computer", select "Manage" to start the "Computer Management" MMC console, then expand the "Services and Applications" node, select "WMI Control", right-click and select "Properties". Then click the "Security" tab to view or modify security settings for your application's namespace.

See Also

Managing Applications Using WMI | Classes and Mapping in CLI and WMI | Exposing Management Events | Exposing Management Data | Inheritance | Registering the Schema for an Instrumented Application