Ausdrücklich empfohlene Entwicklungsrichtlinien

In diesem Abschnitt werden Richtlinien beschrieben, die Sie beim Schreiben ihrer Cmdlets befolgen sollten. Sie sind in Richtlinien für das Entwerfen von Cmdlets und Richtlinien zum Schreiben des Cmdlet-Codes unterteilt. Möglicherweise stellen Sie fest, dass diese Richtlinien nicht für jedes Szenario gelten. Wenn sie jedoch angewendet werden und Sie diese Richtlinien nicht befolgen, haben Ihre Benutzer möglicherweise eine schlechte Erfahrung, wenn sie Ihre Cmdlets verwenden.

Entwurfsrichtlinien

Die folgenden Richtlinien sollten beim Entwerfen von Cmdlets befolgt werden, um eine konsistente Benutzererfahrung zwischen der Verwendung Ihrer Cmdlets und anderen Cmdlets sicherzustellen. Wenn Sie eine Designrichtlinie finden, die für Ihre Situation gilt, sollten Sie sich die Coderichtlinien für ähnliche Richtlinien ansehen.

Verwenden eines bestimmten Substantivs für einen Cmdlet-Namen (SD01)

Nomen, die bei der Benennung von Cmdlets verwendet werden, müssen sehr spezifisch sein, damit der Benutzer Ihre Cmdlets ermitteln kann. Versehe generische Substantive wie "Server" mit einer gekürzten Version des Produktnamens. Wenn beispielsweise ein Substantiv auf einen Server verweist, auf dem eine Instanz von Microsoft SQL Server ausgeführt wird, verwenden Sie ein Substantiv wie "SQLServer". Die Kombination aus bestimmten Substantiven und der kurzen Liste der genehmigten Verben ermöglicht es dem Benutzer, funktionen schnell zu erkennen und zu antizipieren und gleichzeitig die Duplizierung zwischen Cmdlet-Namen zu vermeiden.

Um die Benutzererfahrung zu verbessern, sollte das Substantiv, das Sie für einen Cmdlet-Namen auswählen, eine Singular sein. Verwenden Sie z. B. den Namen Get-Process anstelle von Get-Processes. Es empfiehlt sich, diese Regel für alle Cmdlet-Namen zu befolgen, auch wenn ein Cmdlet wahrscheinlich mehr als ein Element verwendet.

Verwenden Sie PascalCase für Cmdlet-Namen (SD02)

Verwenden Sie die Pascal-Schreibweise für Parameternamen. Mit anderen Worten: Den ersten Buchstaben des Verbs und den ersten Buchstaben aller im Substantiv verwendeten Begriffe großschreiben. Beispiel: "Clear-ItemProperty".

Parameterentwurfsrichtlinien (SD03)

Ein Cmdlet benötigt Parameter, die die Daten entgegennehmen, für die es ausgeführt werden muss, sowie Parameter, die Informationen angeben, die verwendet werden, um die Merkmale des Vorgangs zu bestimmen. Beispielsweise verfügt ein Cmdlet über einen Name Parameter, der Daten aus der Pipeline empfängt, und das Cmdlet verfügt möglicherweise über einen Force Parameter, um anzugeben, dass das Cmdlet gezwungen werden kann, seinen Vorgang auszuführen. Es gibt keine Beschränkung auf die Anzahl von Parametern, die ein Cmdlet definieren kann.

Verwenden von Standardparameternamen

Das Cmdlet sollte Standardparameternamen verwenden, damit der Benutzer schnell bestimmen kann, was ein bestimmter Parameter bedeutet. Wenn ein spezifischerer Name erforderlich ist, verwenden Sie einen Standardparameternamen, und geben Sie dann einen spezifischeren Namen als Alias an. Das Cmdlet verfügt beispielsweise Get-Service über einen Parameter mit einem generischen Namen (Name) und einem spezifischeren Alias (ServiceName). Beide Begriffe können verwendet werden, um den Parameter anzugeben.

Weitere Informationen zu Parameternamen und deren Datentypen finden Sie unter Cmdlet-Parametername und -Funktionalitätsrichtlinien.

Verwenden Sie einzelne Parameternamen

Vermeiden Sie die Verwendung von Pluralnamen für Parameter, deren Wert ein einzelnes Element ist. Dazu gehören Parameter, die Arrays oder Listen verwenden, da der Benutzer möglicherweise ein Array oder eine Liste mit nur einem Element bereitstellen kann.

Plural-Parameternamen sollten nur in fällen verwendet werden, in denen der Wert des Parameters immer ein Mehrfachelementwert ist. In diesen Fällen sollte das Cmdlet überprüfen, ob mehrere Elemente bereitgestellt werden, und das Cmdlet sollte dem Benutzer eine Warnung anzeigen, wenn mehrere Elemente nicht angegeben werden.

Verwenden Sie Pascal Case für Parameternamen

Verwenden Sie PascalCase für Parameternamen. Mit anderen Worten: Groß-/Kleinschreibung des ersten Buchstabens jedes Worts im Parameternamen, einschließlich des ersten Buchstabens des Namens. Zum Beispiel verwendet der Parametername ErrorAction die richtige Groß-/Kleinschreibung. Die folgenden Parameternamen verwenden eine falsche Groß-/Kleinschreibung:

• errorAction
• erroraction

Parameter, die eine Liste der Optionen verwenden

Es gibt zwei Möglichkeiten, einen Parameter zu erstellen, dessen Wert aus einer Reihe von Optionen ausgewählt werden kann.

• Definieren Sie einen Enumerationstyp (oder verwenden Sie einen vorhandenen Enumerationstyp), der die gültigen Werte angibt. Verwenden Sie dann den Enumerationstyp, um einen Parameter dieses Typs zu erstellen.

• Fügen Sie der Parameterdeklaration das ValidateSet-Attribut hinzu. Weitere Informationen zu diesem Attribut finden Sie unter ValidateSet-Attributdeklaration.

Verwenden von Standardtypen für Parameter

Um die Konsistenz mit anderen Cmdlets sicherzustellen, verwenden Sie standardtypen für Parameter, sofern möglich. Weitere Informationen zu den Typen, die für verschiedene Parameter verwendet werden sollen, finden Sie unter Standard Cmdlet Parameter Names and Types. Dieses Thema enthält Links zu mehreren Themen, die die Namen und .NET Framework-Typen für Gruppen von Standardparametern beschreiben, z. B. die "Aktivitätsparameter".

Verwenden von stark typisierten .NET-Framework-Typen

Parameter sollten als .NET Framework-Typen definiert werden, um eine bessere Parameterüberprüfung bereitzustellen. Beispielsweise sollten Parameter, die auf einen Wert aus einer Gruppe von Werten beschränkt sind, als Enumerationstyp definiert werden. Um einen URI-Wert (Uniform Resource Identifier) zu unterstützen, definieren Sie den Parameter als System.Uri-Typ . Vermeiden Sie grundlegende Zeichenfolgenparameter, außer für Freiformtexteigenschaften.

Verwenden von konsistenten Parametertypen

Wenn derselbe Parameter von mehreren Cmdlets verwendet wird, verwenden Sie immer denselben Parametertyp. Wenn der Process Parameter beispielsweise ein System.Int16-Typ für ein Cmdlet ist, machen Sie den Process Parameter für ein anderes Cmdlet nicht als System.Uint16-Typ .

Parameter, die "True" und "False" annehmen

Wenn Ihr Parameter nur true und false akzeptiert, definieren Sie den Parameter als Typ System.Management.Automation.SwitchParameter. Ein [switch] Parameter wird so behandelt, als true ob er in einem Befehl angegeben wird. Wenn der Parameter nicht in einem Befehl enthalten ist, berücksichtigt Windows PowerShell den Wert des Parameters als false. Definieren Sie keine booleschen Parameter.

Wenn Ihr Parameter zwischen drei Werten unterscheiden muss: $true, $false und "nicht angegeben", definieren Sie einen Parameter vom Typ Nullable<bool>. Der Bedarf an einem 3. "nicht angegebenen" Wert tritt in der Regel auf, wenn das Cmdlet eine boolesche Eigenschaft eines Objekts ändern kann. In diesem Fall bedeutet "nicht angegeben", den aktuellen Wert der Eigenschaft nicht zu ändern.

Unterstützung von Arrays für Parameter

Häufig müssen Benutzer denselben Vorgang für mehrere Argumente ausführen. Für diese Benutzer sollte ein Cmdlet ein Array als Parametereingabe akzeptieren, damit ein Benutzer die Argumente als Windows PowerShell-Variable an den Parameter übergeben kann. Beispielsweise verwendet das Cmdlet Get-Process ein Array für die Zeichenfolgen, die die Namen der abzurufenden Prozesse identifizieren.

Unterstützung für den PassThru-Parameter

Standardmäßig dienen viele Cmdlets, die das System ändern, z. B. das Cmdlet Stop-Process, als "Senken" für Objekte und geben kein Ergebnis zurück. Dieses Cmdlet sollte den PassThru Parameter implementieren, um zu erzwingen, dass das Cmdlet ein Objekt zurückgibt. Wenn der PassThru Parameter angegeben wird, gibt das Cmdlet ein Objekt mithilfe eines Aufrufs der System.Management.Automation.Cmdlet.WriteObject-Methode zurück. Beispielsweise beendet der folgende Befehl die Calc (CalculatorApp.exe) und übergibt den resultierenden Prozess an die Pipeline.

Stop-Process -Name CalculatorApp -PassThru

In den meisten Fällen sollten Add-, Set- und New-Cmdlets einen PassThru Parameter unterstützen.

Unterstützungsparametersätze

Ein Cmdlet soll einen einzelnen Zweck erreichen. Es gibt jedoch häufig mehr als eine Möglichkeit, den Vorgang oder das Vorgangsziel zu beschreiben. Beispielsweise kann ein Prozess durch seinen Namen, seinen Bezeichner oder durch ein Prozessobjekt identifiziert werden. Das Cmdlet sollte alle angemessenen Darstellungen seiner Ziele unterstützen. Normalerweise erfüllt das Cmdlet diese Anforderung, indem Sätze von Parametern (als Parametersätze bezeichnet) angegeben werden, die zusammen ausgeführt werden. Ein einzelner Parameter kann zu einer beliebigen Anzahl von Parametersätzen gehören. Weitere Informationen zu Parametersätzen finden Sie unter Cmdlet-Parametersätze.

Wenn Sie Parametersätze angeben, legen Sie nur einen Parameter im Set auf ValueFromPipeline fest. Weitere Informationen zum Deklarieren des Parameterattributs finden Sie unter ParameterAttribute-Deklaration.

Wenn Parametersätze verwendet werden, wird der Standardparametersatz durch das Cmdlet-Attribut definiert. Der Standardparametersatz sollte die Parameter enthalten, die wahrscheinlich in einer interaktiven Windows PowerShell-Sitzung verwendet werden. Weitere Informationen zum Deklarieren des Cmdlet-Attributs finden Sie unter CmdletAttribute-Deklaration.

Bereitstellen von Feedback für den Benutzer (SD04)

Verwenden Sie die Richtlinien in diesem Abschnitt, um dem Benutzer Feedback zu geben. Mit diesem Feedback kann der Benutzer wissen, was im System passiert, und bessere Administrative Entscheidungen treffen.

Mit der Windows PowerShell-Laufzeit kann ein Benutzer angeben, wie die Ausgabe von jedem Aufruf der Write-Methode behandelt wird, indem eine Einstellungsvariable festgelegt wird. Der Benutzer kann mehrere Einstellungsvariablen festlegen, einschließlich einer Variablen, die bestimmt, ob das System Informationen und eine Variable anzeigen soll, die bestimmt, ob das System den Benutzer abfragen soll, bevor er weitere Maßnahmen ergreifen kann.

Unterstützen der Methoden WriteWarning, WriteVerbose und WriteDebug

Ein Cmdlet sollte die System.Management.Automation.Cmdlet.WriteWarning-Methode aufrufen, wenn das Cmdlet einen Vorgang ausführt, der möglicherweise ein unbeabsichtigtes Ergebnis hat. Beispielsweise sollte ein Cmdlet diese Methode aufrufen, wenn das Cmdlet eine schreibgeschützte Datei überschreiben soll.

Ein Cmdlet sollte die System.Management.Automation.Cmdlet.WriteVerbose-Methode aufrufen, wenn der Benutzer einige Details zu den Aktionen des Cmdlets benötigt. Beispielsweise sollte ein Cmdlet diese Informationen aufrufen, wenn der Autor des Cmdlets das Gefühl hat, dass es Szenarien gibt, die möglicherweise weitere Informationen zu den Aktionen des Cmdlets erfordern.

Das Cmdlet sollte die System.Management.Automation.Cmdlet.WriteDebug-Methode aufrufen, wenn ein Entwickler oder Produktsupporttechniker verstehen muss, was den Cmdlet-Vorgang beschädigt hat. Es ist nicht erforderlich, dass das Cmdlet die System.Management.Automation.Cmdlet.WriteDebug-Methode im selben Code aufruft, der die System.Management.Automation.Cmdlet.WriteVerbose-Methode aufruft, da der Debug Parameter beide Informationssätze darstellt.

Unterstützung von WriteProgress für Vorgänge, die eine lange Zeit in Anspruch nehmen

Cmdlet-Vorgänge, die lange dauern und nicht im Hintergrund ausgeführt werden können, sollten die Statusberichterstattung durch regelmäßige Aufrufe der System.Management.Automation.Cmdlet.WriteProgress-Methode unterstützen.

Verwenden Sie die Hostschnittstellen

Gelegentlich muss ein Cmdlet direkt mit dem Benutzer kommunizieren, anstatt die verschiedenen Write- oder Should-Methoden zu verwenden, die von der System.Management.Automation.Cmdlet-Klasse unterstützt werden. In diesem Fall sollte das Cmdlet von der System.Management.Automation.PSCmdlet-Klasse abgeleitet werden und die System.Management.Automation.PSCmdlet.Host* -Eigenschaft verwenden. Diese Eigenschaft unterstützt verschiedene Kommunikationstypen, einschließlich der Typen "PromptForChoice", "Prompt" und "WriteLine/ReadLine". Auf der spezifischsten Ebene bietet es auch Möglichkeiten zum Lesen und Schreiben einzelner Schlüssel und zum Behandeln von Puffern.

Es sei denn, ein Cmdlet ist speziell für die Erstellung einer grafischen Benutzeroberfläche (GUI) konzipiert, sollte der Host nicht mithilfe der System.Management.Automation.PSCmdlet.Host* -Eigenschaft umgangen werden. Ein Beispiel für ein Cmdlet, das zum Generieren einer GUI konzipiert ist, ist das Cmdlet Out-GridView.

Erstellen einer Cmdlet-Hilfedatei (SD05)

Erstellen Sie für jede Cmdletassembly eine Help.xml Datei, die Informationen zum Cmdlet enthält. Diese Informationen enthalten eine Beschreibung des Cmdlets, Beschreibungen der Parameter des Cmdlets, Beispiele für die Verwendung des Cmdlets und vieles mehr.

Coderichtlinien

Die folgenden Richtlinien sollten beim Codieren von Cmdlets befolgt werden, um eine konsistente Benutzererfahrung zwischen der Verwendung Ihrer Cmdlets und anderen Cmdlets sicherzustellen. Wenn Sie eine Coderichtlinie finden, die für Ihre Situation gilt, sollten Sie sich die Entwurfsrichtlinien für ähnliche Richtlinien ansehen.

Codierungsparameter (SC01)

Definieren Sie einen Parameter, indem Sie eine öffentliche Eigenschaft der Cmdlet-Klasse deklarieren, die mit dem Parameter-Attribut versehen ist. Die Parameter müssen keine statischen Member der abgeleiteten .NET Framework-Klasse für das Cmdlet sein. Weitere Informationen zum Deklarieren des Parameter-Attributs finden Sie unter Parameter-Attributdeklaration.

Unterstützung von Windows PowerShell-Pfaden

Der Windows PowerShell-Pfad ist der Mechanismus zum Normalisieren des Zugriffs auf Namespaces. Wenn Sie einem Parameter im Cmdlet einen Windows PowerShell-Pfad zuweisen, kann der Benutzer ein benutzerdefiniertes Laufwerk definieren, das als Verknüpfung zu einem bestimmten Pfad fungiert. Wenn ein Benutzer ein solches Laufwerk bestimmt, können gespeicherte Daten wie Daten in der Registrierung auf konsistente Weise verwendet werden.

Wenn ihr Cmdlet es dem Benutzer ermöglicht, eine Datei oder Datenquelle anzugeben, sollte er einen Parameter vom Typ "System.String" definieren. Wenn mehr als ein Laufwerk unterstützt wird, sollte der Typ ein Array sein. Der Name des Parameters sollte Path mit dem Alias PSPath sein. Darüber hinaus sollte der Path Parameter Wildcardzeichen unterstützen. Wenn keine Unterstützung für Wildcardzeichen erforderlich ist, definieren Sie einen LiteralPath Parameter.

Wenn die Daten, die das Cmdlet liest oder schreibt, eine Datei sein muss, sollte das Cmdlet Windows PowerShell-Pfadeingabe akzeptieren, und das Cmdlet sollte die System.Management.Automation.SessionState.Path-Eigenschaft verwenden, um die Windows PowerShell-Pfade in Pfade zu übersetzen, die vom Dateisystem erkannt werden. Zu den spezifischen Mechanismen gehören die folgenden Methoden:

• System.Management.Automation.PSCmdlet.GetResolvedProviderPathFromPSPath
• System.Management.Automation.PSCmdlet.GetUnresolvedProviderPathFromPSPath
• System.Management.Automation.PathIntrinsics.GetResolvedProviderPathFromPSPath
• System.Management.Automation.PathIntrinsics.GetUnresolvedProviderPathFromPSPath

Wenn die Daten, die das Cmdlet liest oder schreibt, nur eine Reihe von Zeichenfolgen anstelle einer Datei sind, sollte das Cmdlet die Anbieterinhaltsinformationen (Content Member) zum Lesen und Schreiben verwenden. Diese Informationen werden aus der Eigenschaft System.Management.Automation.Provider.CmdletProvider.InvokeProvider abgerufen. Diese Mechanismen ermöglichen es anderen Datenspeichern, am Lesen und Schreiben von Daten teilzunehmen.

Unterstützen von Wildcardzeichen

Ein Cmdlet sollte nach Möglichkeit Wildcardzeichen unterstützen. Die Unterstützung für Platzhalterzeichen erfolgt an vielen Stellen in einem Cmdlet (insbesondere, wenn ein Parameter eine Zeichenfolge verwendet, um ein Objekt aus einer Gruppe von Objekten zu identifizieren). Beispielsweise definiert das Beispiel-Cmdlet Stop-Proc aus dem StopProc-Lernprogramm einen Name Parameter zum Behandeln von Zeichenfolgen, die Prozessnamen darstellen. Dieser Parameter unterstützt Wildcardzeichen, sodass der Benutzer die zu beendenden Prozesse problemlos angeben kann.

Wenn die Unterstützung für Wildcardzeichen verfügbar ist, erzeugt ein Cmdlet-Vorgang in der Regel ein Array. Gelegentlich ist es nicht sinnvoll, ein Array zu unterstützen, da der Benutzer möglicherweise nur ein einzelnes Element gleichzeitig verwendet. Beispielsweise muss das Cmdlet Set-Location ein Array nicht unterstützen, da der Benutzer nur einen einzigen Speicherort festlegt. In diesem Fall unterstützt das Cmdlet weiterhin Wildcardzeichen, es erzwingt jedoch die Auflösung an einem einzelnen Ort.

Weitere Informationen zu Wildcardzeichenmustern finden Sie unter Unterstützen von Wildcardzeichen in Cmdlet-Parametern.

Definieren von Objekten

Dieser Abschnitt enthält Richtlinien zum Definieren von Objekten für Cmdlets und zum Erweitern vorhandener Objekte.

Standardmitglieder definieren

Definieren Sie Standardmitglieder, um einen Objekttyp in einer benutzerdefinierten Types.ps1xml-Datei zu erweitern. Verwenden Sie die Windows PowerShell Types.ps1xml-Datei als Vorlage. Standardmember werden durch einen Knoten mit dem Namen PSStandardMembers definiert. Diese Definitionen ermöglichen es anderen Cmdlets und der Windows PowerShell-Laufzeit, auf einheitliche Weise mit Ihrem Objekt zu arbeiten.

Definieren Sie Objektmitglieder, die als Parameter verwendet werden sollen

Wenn Sie ein Objekt für ein Cmdlet entwerfen, vergewissern Sie sich, dass dessen Member direkt den Parametern der Cmdlets zugeordnet werden, die es nutzen werden. Mit dieser Zuordnung kann das Objekt einfach an die Pipeline gesendet und von einem Cmdlet an ein anderes übergeben werden.

Vorhandene .NET Framework-Objekte, die von Cmdlets zurückgegeben werden, haben häufig einige wichtige oder praktische Member nicht, die von Skriptentwicklern oder Benutzern benötigt werden. Diese fehlenden Elemente können besonders wichtig für die Darstellung und das Erstellen der korrekten Namen der Member sein, damit das Objekt korrekt an die Pipeline übergeben werden kann. Erstellen Sie eine benutzerdefinierte Datei namens Types.ps1xml, um die erforderlichen Mitglieder zu dokumentieren. Wenn Sie diese Datei erstellen, empfehlen wir die folgende Benennungskonvention: <Your_Product_Name>. Types.ps1xml.

Sie können beispielsweise eine Mode Skripteigenschaft zum System.IO.FileInfo-Typ hinzufügen, um die Attribute einer Datei klarer anzuzeigen. Darüber hinaus können Sie dem Count eine Aliaseigenschaft hinzufügen, um die konsistente Verwendung dieses Eigenschaftsnamens (anstelle von Length) zu ermöglichen.

Implementieren der IComparable-Schnittstelle

Implementieren Sie eine System.IComparable-Schnittstelle für alle Ausgabeobjekte. Dadurch können die Ausgabeobjekte einfach an verschiedene Sortier- und Analyse-Cmdlets weitergeleitet werden.

Anzeigeinformationen aktualisieren

Wenn die Anzeige für ein Objekt nicht die erwarteten Ergebnisse bereitstellt, erstellen Sie einen benutzerdefinierten <YourProductName>. Format.ps1xml-Datei für dieses Objekt.

Unterstützung von gut definierten Pipeline-Eingaben (SC02)

Implementieren für die Mitte einer Pipeline

Implementieren Sie ein Cmdlet, wobei davon ausgegangen wird, dass es von der Mitte einer Pipeline aufgerufen wird (d. a. andere Cmdlets erzeugen seine Eingabe oder verbrauchen seine Ausgabe). Angenommen, das Get-Process Cmdlet wird nur als erstes Cmdlet in einer Pipeline verwendet, da es Daten generiert. Da dieses Cmdlet jedoch für die Mitte einer Pipeline konzipiert ist, können mit diesem Cmdlet frühere Cmdlets oder Daten in der Pipeline die abzurufenden Prozesse angeben.

Unterstützung von Eingaben aus der Pipeline

Schließen Sie in jedem Parametersatz für ein Cmdlet mindestens einen Parameter ein, der Eingaben aus der Pipeline unterstützt. Die Unterstützung für Pipelineeingaben ermöglicht es dem Benutzer, Daten oder Objekte abzurufen, sie an den richtigen Parametersatz zu senden und die Ergebnisse direkt an ein Cmdlet zu übergeben.

Ein Parameter akzeptiert Eingaben aus der Pipeline, wenn das Parameter-Attribut das ValueFromPipeline Schlüsselwort, das ValueFromPipelineByPropertyName Schlüsselwort-Attribut oder beide Schlüsselwörter in der Deklaration enthält. Wenn keiner der Parameter in einem Parametersatz die ValueFromPipeline oder ValueFromPipelineByPropertyName Schlüsselwörter unterstützt, kann das Cmdlet nicht sinnvoll nach einem anderen Cmdlet ausgeführt werden, da es alle Pipelineeingaben ignoriert.

Unterstützung der ProcessRecord-Methode

Damit alle Datensätze aus dem vorherigen Cmdlet in der Pipeline akzeptiert werden können, muss das Cmdlet die Methode System.Management.Automation.Cmdlet.ProcessRecord implementieren. Windows PowerShell ruft diese Methode mehrmals auf, einmal für jeden Datensatz, der an Ihr Cmdlet gesendet wird.

Schreiben einzelner Datensätze in die Pipeline (SC03)

Wenn ein Cmdlet Objekte zurückgibt, sollte das Cmdlet die Objekte sofort schreiben, sobald sie generiert werden. Das Cmdlet sollte sie nicht aufbewahren, um sie in ein gemeinsames Array zu puffern. Die Cmdlets, die die Objekte als Eingabe empfangen, können dann die Ausgabeobjekte ohne Verzögerung verarbeiten und/oder anzeigen. Ein Cmdlet, das Ausgabeobjekte einzeln generiert, sollte die System.Management.Automation.Cmdlet.WriteObject-Methode aufrufen. Ein Cmdlet, das Ausgabeobjekte in Batches generiert (z. B. weil eine zugrunde liegende API ein Array von Ausgabeobjekten zurückgibt), sollte die Methode System.Management.Automation.Cmdlet.WriteObject aufrufen, wobei der zweite Parameter auf true gesetzt wird.

Erstellen von Cmdlets Case-Insensitive und Case-Preserving (SC04)

Standardmäßig wird bei Windows PowerShell selbst die Groß-/Kleinschreibung nicht beachtet. Da es sich jedoch um viele bereits vorhandene Systeme handelt, behält Windows PowerShell den Fall für eine einfache Bedienung und Kompatibilität bei. Anders ausgedrückt: Wenn ein Zeichen in Großbuchstaben angegeben wird, behält Windows PowerShell es in Großbuchstaben. Damit Systeme gut funktionieren, muss ein Cmdlet dieser Konvention entsprechen. Wenn möglich, sollte es unabhängig von der Groß- und Kleinschreibung arbeiten. Sie sollte jedoch den ursprünglichen Fall für Cmdlets beibehalten, die später in einem Befehl oder in der Pipeline auftreten.

Siehe auch

Erforderliche Entwicklungsrichtlinien

Richtlinien für beratungsbezogene Entwicklung

Schreiben eines Windows PowerShell-Cmdlets