Was this page helpful?
Your feedback about this content is important. Let us know what you think.
Additional feedback?
1500 characters remaining
Export (0) Print
Expand All
Important This document may not represent best practices for current development, links to downloads and other resources may no longer be valid. Current recommended version can be found here.

Providing Management Information by Instrumenting Applications

.NET Framework 2.0

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, an operating system, or a 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 about how you drive and maintain your car. Computer components that provide 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 who 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 who are 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.

You can expose application information for management by making declarations — no extensive extra coding is required. The developer marks the objects as manageable by using the .NET Framework attribution classes 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. The InstrumentedAttribute and InstrumentationClassAttribute classes are the primary means of instrumenting your code.

After your application has been instrumented, other applications can discover, monitor, and configure objects and events 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 using namespace-based security. For more information, see Security for WMI in .NET Framework.

Namespace Recommendations

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

  • 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, 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. For more information, see "Locating the WMI Control" in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library.

See Also

Community Additions

ADD
Show:
© 2015 Microsoft