While it is not a limitation, an instrumented application can only exist as a decoupled provider, out-of-process to WMI. For more information on decoupled providers in WMI, see "Incorporating a Provider in an Application" in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library.

WMI in .NET Framework has the following limitations:

• Managed code providers cannot define methods.

  Instrumented applications running on .NET Framework and providing data to WMI cannot use the System.Management or System.Management.Instrumentation class methods to define and implement methods. A provider can still execute the method of an original WMI provider. For example, a .NET Framework instrumented provider can still execute the StopService method for an instance of the preinstalled WMI class Win32_Service. For more information, see "Win32_Service"0 in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library.

• Instrumented applications cannot expose writeable properties on new classes that are not wrappers of underlying unmanaged WMI classes.

  A user of a class created by an instrumented application cannot change instance data and then write the data back using a Put operation.

• You cannot create qualifiers on instrumented classes.

  WMI qualifiers are similar in concept to managed code attributes, but there is no direct mapping between them. There are attributes in the System.Management.Instrumentation namespace, but these are not represented by qualifiers on the WMI class definition. Instead, managed code defines several attribute classes in System.Management.Instrumentation that allow developers to define the mapping in a declarative syntax. Some frequently-used attribute classes are InstrumentedAttribute and InstrumentationClassAttribute.

• You cannot define properties of instrumented objects as key properties.

• Although WMI supports embedded objects as well as references to other objects using WMI in .NET Framework, you can only use embedded objects when defining new classes.

• You cannot create an event consumer provider in managed code.

  For more information, see "Writing an Event Consumer Provider" in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library. Managed client applications, however, can still access existing unmanaged code and WMI consumer providers, such as the Standard Consumers. For more information, see "Monitoring and Responding to Events with Standard Consumers" in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library.

• WMI in .NET Framework does not support Refreshers.

  If you want to retrieve data from Win32_FormattedData_* classes, then you can use the System.Diagnostics.PerformanceCounter class instead of using refreshers with the Win32_FormattedData_* classes, or you can get the raw counter samples from the Win32_PerfRawData_* classes at the desired interval and calculate the result yourself using the last two samples. For more information on these Win32 classes, see "Win32_Classes" in the Windows Management Instrumentation documentation in the MSDN Library at http://msdn.microsoft.com/library.

• The System.Management.Instrumentation namespace does not support the inheritance of classes if the derived class is in a different namespace than the parent class.

• The WMI infrastructure and providers on native and managed (.NET) stack have not been verified for use in a cluster environment and hence are not supported in a cluster environment.

Concepts