Klassen und Zuordnung in CLI und WMI

Klassendefinitionen bilden den Kern der Programmierung in verwaltetem Code. WMI basiert ebenfalls auf demselben grundlegenden Prinzip der Klassendefinitionen. WMI verfügt jedoch über eine eigene Grammatik für die Beschreibung von Klassen (MOF) sowie eine API für die programmgesteuerte Definition von Klassen.

Das grundlegende Ziel der Instrumentation besteht darin, Informationen hervorzubringen, die für Tools nützlich sein könnten, die versuchen, eine Anwendung zu verwalten. Andere Instrumentationstechniken, z. B. das Verfolgen oder Protokollieren von Dateien, schränken Anwendungen so ein, dass ein Block nicht strukturierter Diagnosedaten (z. B. eine einfache Zeichenfolge) zur Verfügung steht. Dank der Instrumentierung mit WMI können sehr vielfältige, schemabasierte Informationen aufgerufen werden. Dazu definieren Anwendungen eine Gruppe von WMI-Klassen, die die Informationen beschreiben, die durch diese Instrumentation hervorgebracht werden. Diese Klassendefinitionen werden über WMI veröffentlicht. Mit Verwaltungstools kann auf die Klassendefinitionen zugegriffen werden. Die Klassendefinitionen müssten nach der Installation jederzeit verfügbar sein, nicht nur wenn die Anwendung ausgeführt wird. Während der Laufzeit stellt die Anwendung die Daten zur Verfügung, die von den WMI-Klassen beschrieben werden.

Das WMI-Modell der Klassendefinitionen, die jederzeit abrufbar sind, ähnelt dem CLI-Modell der verwalteten Klassen und Metadaten. Der System.Management.Instrumentation-Namespace nutzt die Ähnlichkeiten zwischen WMI-Klassen und CLI-Klassen, so dass WMI-Klassen definiert werden können, indem Klassendefinitionen in verwaltetem Code geschrieben werden. Demnach wissen Entwickler, die mit verwaltetem Code arbeiten, wie WMI-Klassen definiert werden, ohne zusätzliche Kenntnisse zu benötigen.

In der Regel können Klassen mit verwaltetem Code den entsprechenden WMI-Klassen zugeordnet werden. In einigen Fällen haben WMI-Klassen Eigenschaften, die mit verwalteten Klassen nicht beschrieben werden können. WMI-Primitive können beispielsweise null sein, während Werttypen des allgemeinen Typensystems nicht null sein können. Der System.Management.Instrumentation-Namespace lässt nicht zu, dass WMI-Klassen beschrieben werden, die Dinge darstellen, die im allgemeinen Typsystem nicht beschrieben werden können.

Die folgende Liste enthält einige Hinweise zu den grundlegenden Möglichkeiten der Zuordnung von verwalteten Klassen zu WMI-Klassen:

• Nur öffentlich verwaltete Klassen können WMI-Klassen zugeordnet werden, und nur öffentliche Member können der WMI-Klassendefinition zugeordnet werden.

• Bei primitiven Werttypen bietet sich die Zuordnung zu CIM-Typen von WMI an.

  Außerdem können die Verweistypen String, DateTime und TimeSpan den entsprechenden CIM-Typen von WMI zugeordnet werden.

• Arrays in verwaltetem Code können Arrays in WMI-Klassendefinitionen zugeordnet werden.

• Die CLI unterscheidet zwischen Werttypen und Verweistypen.

  In WMI wird diese Unterscheidung nicht gemacht, d. h., beide können einer WMI-Klassendefinition zugeordnet werden.

• WMI unterstützt eingebettete Objekte und Verweise auf andere Objekte.

  In der ersten Version von System.Management.Instrumentation werden nur eingebettete Objekte unterstützt. Verwaltete Klassen, die Werttypmember enthalten, werden logischerweise solchen WMI-Klassen zugeordnet, die ein eingebettetes Objekt enthalten. Verwaltete Klassen, die Verweistypmember enthalten, werden ebenfalls WMI-Klassen mit eingebetteten Objekten zugeordnet, in zukünftigen Versionen wird es jedoch wahrscheinlich möglich sein, anzugeben, dass Laufzeitverweise durch WMI-Verweise dargestellt werden sollen.

• Vererbungshierarchien von verwalteten Klassen werden durch Vererbungshierarchien in WMI dargestellt.

• In der ersten Version von System.Management.Instrumentation können WMI-Standardwerte nicht in verwaltetem Code dargestellt werden.

  Feldinitialisierungen in verwalteten Klassenfeldern werden WMI-Standardwerten nicht zugeordnet.

• WMI unterscheidet nicht zwischen Feldern und Eigenschaften.

  In einer Definition für eine verwaltete Klasse werden sowohl Felder als auch Eigenschaften WMI-Eigenschaften zugeordnet.

• Der Namespace einer Definition für eine verwaltete Klasse steht in keiner Beziehung zu dem Namespace der WMI-Klassendefinition.

  Das heißt, eine verwaltete Klasse kann im MyCompany.MyApplication-Namespace definiert werden, und die dazugehörige WMI-Instrumentationsklasse kann als WMI-Namespace root\MyCompany definiert werden.

• WMI unterstützt ein Konzept, das Attributen ähnelt und als Qualifizierer bezeichnet wird.

  In System.Management.Instrumentation besteht keine Zuordnung zwischen Attributen mit verwaltetem Code und WMI-Qualifizierern. Es gibt Attribute im System.Management.Instrumentation-Namespace, diese werden in der WMI-Klassendefinition jedoch nicht durch Qualifizierer dargestellt. Um die Zuordnung zwischen den beiden zu ermöglichen, definiert der System.Management.Instrumentation-Namespace mehrere Attributklassen, so dass Entwickler die Zuordnung in einer deklarativen Syntax definieren können, anstatt eine neue API zu verwenden. Hierbei kommt erneut eine Fähigkeit zum Einsatz, mit der Entwickler, die mit verwaltetem Code arbeiten, bereits vertraut sind. Wie bereits erwähnt, besteht die Instrumentation vorwiegend aus zwei Phasen: der Klassendefinition zur Entwurfszeit und der Datenbeschaffung zur Laufzeit. Die Verwendung von Attributen ist in der ersten Phase äußerst wichtig. Dadurch ist es möglich, dass die Metadaten der verwalteten Klassen das Instrumentationschema vollständig beschreiben. Die Metadaten werden anschließend zum Erstellen des WMI-Schemas verwendet, das für Verwaltungstools sichtbar ist.

Siehe auch

Instrumentieren von .NET Framework-Anwendungen mit System.Management | Offenlegen von Verwaltungsereignissen | Verfügbarmachen von Verwaltungsdaten | Vererbung | Registrieren des Schemas für eine instrumentierte Anwendung