about_Requires

Letzte Aktualisierung: Mai 2014

Betrifft: Windows PowerShell 4.0, Windows PowerShell 5.0

THEMA

about_Requires

KURZE BESCHREIBUNG

Verhindert, dass ein Skript ohne die erforderlichen Elemente ausgeführt wird.

LANGE BESCHREIBUNG

Die Anweisung #Requires verhindert die Ausführung eines Skripts, wenn die Voraussetzungen hinsichtlich der Windows PowerShell®-Version, der Module und Snap-ins sowie der Modul- und -Snap-in-Versionen nicht erfüllt sind. Ohne diese Voraussetzungen führt Windows PowerShell das Skript nicht aus.

Die Anweisung #Requires kann in jedem Skript verwendet werden. In Funktionen, Cmdlets und Snap-Ins kann sie hingegen nicht verwenden werden.

SYNTAX

          #Requires -Version <N>[.<n>] 
          #Requires –PSSnapin <PSSnapin-Name> [-Version <N>[.<n>]]
          #Requires -Modules { <Module-Name> | <Hashtable> } 
          #Requires –ShellId <ShellId>
          #Requires -RunAsAdministrator

REGELN FÜR DIE VERWENDUNG

  • – Die Anweisung #Requires muss an erster Stelle in einer Skriptzeile stehen.

  • – Ein Skript kann mehrere #Requires-Anweisungen enthalten.

  • – Jede Skriptzeile kann #Requires-Anweisungen enthalten.

PARAMETER

  -Version <N>[.<n>]

Gibt die vom Skript geforderte Mindestversion von Windows PowerShell an. Geben Sie eine Hauptversionsnummer und optional eine Nebenversionsnummer ein.

Beispiel:

        #Requires -Version 3.0
  -PSSnapin <PSSnapin-Name> [-Version <N>[.<n>]]

Gibt ein vom Skript gefordertes Windows PowerShell-Snap-in an. Geben Sie den Namen des Snap-ins und optional die Versionsnummer an.

Beispiel:

        #Requires –PSSnapin DiskSnapin -Version 1.2
  -Modules <Module-Name> | <Hashtable>

Gibt vom Skript geforderte Windows PowerShell-Module an. Geben Sie den Namen des Moduls und optional die Versionsnummer an. Der Parameter "Modules" wurde in Windows PowerShell 3.0 eingeführt.

Wenn die erforderlichen Module nicht in der aktuellen Sitzung verfügbar sind, werden sie von Windows PowerShell importiert. Können die Module nicht importiert werden, so gibt Windows PowerShell einen Terminierungsfehler aus.

Geben Sie für jedes Modul den Namen des Moduls (<Zeichenfolge>) oder eine Hashtabelle mit den folgenden Schlüsseln ein. Der Wert kann auch eine Kombination aus Zeichenfolgen und Hashtabellen sein.

  • -- ModuleName. Dieser Schlüssel ist erforderlich.

  • -- ModuleVersion. Dieser Schlüssel ist erforderlich.

  • -- GUID. Dieser Schlüssel ist optional.

Beispiel:

        #Requires -Modules PSWorkflow, @{ModuleName="PSScheduledJob";ModuleVersion=1.0.0.0}
  -ShellId

Gibt die vom Skript geforderte Shell an. Geben Sie die Shell-ID ein.

Beispiel:

        #Requires –ShellId MyLocalShell
  -RunAsAdministrator

Wenn Ihre #Requires-Anweisung diesen Switch-Parameter enthält, muss die Windows PowerShell-Sitzung, in der das Skript ausgeführt wird, mit höheren Benutzerrechten (Als Administrator ausführen) neu gestartet werden.

Beispiel:

        #Requires -RunAsAdministrator

BEISPIELE

Das folgende Skript enthält zwei #Requires-Anweisungen. Das Skript wird nur ausgeführt, wenn die Anforderungen in beiden Anweisungen erfüllt sind. Jede #Requires-Anweisung muss in ihrer Zeile an erster Stelle stehen:

          #Requires –Modules PSWorkflow
          #Requires –Version 3
          Param
         (
             [parameter(Mandatory=$true)]
             [String[]]
             $Path
         )
         ...

HINWEISE

In Windows PowerShell 3.0 werden die Windows PowerShell Core-Pakete in Sitzungen, die mit der Methode InitialSessionState.CreateDefault2 gestartet wurden (z. B. in über die Windows PowerShell-Konsole gestarteten Sitzungen), als Module dargestellt. Andernfalls werden sie als-Snap-ins angezeigt. Ausgenommen hiervon ist Microsoft.PowerShell.Core, das immer als Snap-in behandelt wird.

SIEHE AUCH

about_Automatic_Variables

about_Language_Keyword

about_PSSnapins

get-PSSnapin