Il est un ancient blog post (2007), mais elle est toujours valable; en bref:
Tant que les nouvelles versions de PowerShell restent rétrocompatible, ils vont remplacer versions antérieures:
L'emplacement d'installation, qui se reflète dans $PSHOME
- $env:systemroot\System32\WindowsPowerShell\v1.0
- restera le même.
L'extension du nom de fichier - .ps1
- restera la même.
Les scripts créés pour une version antérieure continueront de s'exécuter.
Pour marquer un script comme exigeant la version <n>
à un minimum, utilisez #requires -version <n>
en haut du script (techniquement, il peut être placé partout dans le script, mais il est logique de logique de placer en haut).
À partir de cette écriture (PowerShell v5.1), la compatibilité ascendante a été maintenue depuis v1, donc à la fois l'emplacement d'installation et l'extension de nom de fichier sont demeurés les mêmes.
Pour obtenir la version de session PowerShell:
> [string] $PSVersionTable.PSVersion
5.1.14393.693 # PSv5.1 example
Plus généralement, Hashtable $PSVersionTable
, introduit en v2, contient plusieurs informations de version, (incomplètement) décrites dans Get-Help about_Automatic_Variables
:
Name Value
---- -----
PSVersion 5.1.14393.693 # The PowerShell version.
PSEdition Desktop # 'Desktop'=*Windows* PS; 'Core'=PS *Core*
PSCompatibleVersions {1.0, 2.0, 3.0, 4.0...} # array of compatible versions
BuildVersion 10.0.14393.693 # OS version? only if it came natively
CLRVersion 4.0.30319.42000 # The .NET CLR version
WSManStackVersion 3.0 # WS-Management (WinRM) version
PSRemotingProtocolVersion 2.3 # remoting-protocol version
SerializationVersion 1.1.0.1 # serialization-protocol version
Merci, j'espérais mieux raisonnement bien :) – poke
@poke en effet aussi je l'ai fait quand j'ai découvert cette décision. – JaredPar