WMI Provider Extensions in .NET Framework v3.5
Windows Management Instrumentation (WMI) is the management infrastructure for Windows-based systems. Windows Vista ships with 100+ WMI providers to enable the management of various operating system components. Applications instrumented with WMI can be managed using tools like Microsoft Operations Manager (MOM), HP OpenView, Windows Script Host (WSH) and PowerShell. The WMI infrastructure provides a repository in which providers can install their management information. Consumers can query & analyze this management information and then using the providers can manage applications by reading/writing configuration settings and calling methods on managed entities. For more on WMI, please start on
the "About" page.
In the .NET Framework v2.0 (in the System.Management.dll) the System.Management namespace provides the functionality for developing WMI consumer applications while the System.Management.Instrumentation namespace provides the classes to write WMI providers. The provider API in .NET Framework v2.0 had some limitations e.g. a managed WMI provider couldn't have writeable properties, and couldn't expose methods. To overcome these limitations and improve the overall provider development experience, .NET Framework v3.5 introduced extensions to the WMI Provider API. The new API/extensions can be found in the System.Management.Instrumentation namespace across two assemblies: System.Core.dll and System.Management.Insrumentation.dll. These new extensions enable a familiar attribute based programming model for writing custom WMI providers and exposes all of the features of the native COM based API to managed code. The new API allows you to create both
coupled and decoupled WMI providers. Coupled providers are implemented as a dll which must be signed and installed in the GAC. The WMI service itself hosts coupled providers. Decoupled providers are hosted by your own application which must be up and running to enable consumers to access your management information.
So to turn a C# or VB class into a management class you apply the ManagementEntity attribute to the class itself. Methods in your class are exposed to WMI using the ManagementTask attribute while ManagementConfiguration and ManagementProbe attributes are used to expose read/write and read-only properties respectively. The hosting model of your provider (coupled or decoupled) is specified using the WmiConfiguration attribute. As always, these attributes are
fully described in the documentation.
Once you have described your management classes and hosting model using the aforementioned attributes, you then create a custom installer class by deriving from the new DefaultManagementInstaller class. This installer class will be invoked when you run InstallUtil.exe against your assembly and will extract the management information from your management classes, creates a MOF (Managed Object Format) script, compiles it and persist it in WMI repository. This installation process is same regardless of the hosting model (coupled or decoupled) of your provider. After the installation, your WMI provider will be available to any WMI consumer application.
WMI is a great technology and by creating a WMI provider your applications can be managed by any management software and custom scripts in a standardized way. For examples of managed WMI providers visit the
MSDN "How To" samples.
Zulfiqar Ahmed
Application Development Consultant (ADC)Read Zulfiqar's blog
