Question [V2] Usage d'attribut sur un paramètre de fonction

[edit]
Cette approche ne fonctionne pas voir les derniers posts
[/edit]
Les fonctions avancées proposent les attributs [Alias()],[Parameter()] et [cmdletBing()],
mais on peut utiliser d’autres attributs dotnet sur une variable, les attributs Parameter étant dédiés à la gestion d’une variable en tant que paramètre et à la validation de sa valeur.

L’attribut credential
On peut par exemple utiliser l’attribut system.management.automation.credential comme indiqué sur ce blog .
Ainsi la liaison du paramètre se fera à l’aide d’une fenêtre graphique permettant la saisie du nom de compte et du mot de passe. Ne confondez pas le type de la variable qui est PSCredential et le nom de l’attribut qui est credential.

On peut donc déclarer une contrainte sur un paramétre sans utiliser l’attribut [Parameter()] :
[code:1]
function Test ([System.Management.Automation.ValidateRangeAttribute(1,10)]$Nb)
{
function Nested($i)
{ write-host (\"-\"* 40) ;(Get-Variable i).Attributes}
(Get-Variable Nb).Attributes
if ( !(test-path Variable:«»PSCmdlet))
{ write-host \"La variable PSCmdlet n’est pas déclarée.\"}
Nested $nb
}
Test 15
Test 5
[/code:1]
On peut également ajouter plusieurs attributs :
[code:1]
function Test (
[System.ComponentModel.DescriptionAttribute(\"Fonction Test\"«»)]
[System.Management.Automation.ValidateRangeAttribute(1,10)] $Nb
)
[/code:1]
Codé ainsi, la fonction n’est pas considérée comme une fonction avancée :
[code:1]
(gcm test).CmdletBinding
#False
[/code:1]
De plus sachez que la contrainte n’est pas propagée, ici $I est une nouvelle variable, il faut utiliser [Ref], voir le tutoriel sur les variables contraintes .

Créer un nouvel attribut
Il est possible de créer un attribut en C#, ces attributs sont ajoutés à la liste des attributs de la variable. L’attribut suivant permet de déclarer le champ Options d’un paramètre :
[code:1]
$code = @\"
// Attributs pour les variables PowerShell
using System;
using System.Management.Automation;

namespace PowerShell.Attributes
{
[AttributeUsage(AttributeTargets.Property | AttributeTargets.Field, Inherited = false, AllowMultiple = false)]
public sealed class VariableOptionAttribute : Attribute
{
private readonly ScopedItemOptions _options;
private const string messageErreur = \"Les valeurs {0} et {1} sont exclusives.\";

public VariableOptionAttribute(ScopedItemOptions options)
{
int value=(int)options;
//On s'assure que les valeurs sont cohérentes.
//AllScope(8) xor Private(4)
if ((value & 12) == 12)
{ throw new System.ArgumentException(string.Format(messageErreur,\"AllScope\",\"Private\"«»)); }
// Constant(2) xor ReadOnly(1) (None=0)
if ((value & 3)== 3)
{throw new System.ArgumentException(string.Format(messageErreur,\"Constant\",\"ReadOnly\"«»)); }
_options= options;
}

public System.Management.Automation.ScopedItemOptions Options
{
get { return _options; }
}
}
}
\"@
[/code:1]
Compile et crée l’attribut à l’aide du cmdlet Add-Type :
[code:1]
Add-Type -TypeDefinition $code
[/code:1]
Ensuite il nous faut rechercher la présence d’un tel attribut et modifier la propriété Options de la variable concernée :
[code:1]
function global:«»Set-VariableOptions{
Param(
[Parameter(
Mandatory = $true,
Position=0,
ValueFromPipeline = $true,
HelpMessage=\"Variable à modifier.\"«»)]
[System.management.Automation.PSVariable] $Variable)

$Variable.Attributes|
Foreach {
$Current=$_
Switch (($Current.Gettype().Fullname)) {
\"PowerShell.Attributes.VariableOptionAttribute\" {
write-debug $_
$Variable.Options=$Current.Options }
default {write-debug \"default\"}
}#switch
}#foreach
}#Set-VariableOptions
[/code:1]
La fonction suivante nous montre que la présence de notre attribut est pris en compte, mais celui-ci n’est pas géré par PowerShell, on doit donc dans les premières lignes de la fonction appeler Set-VariableOptions :
[code:1]
function Test{
Param([PowerShell.Attributes.VariableOption (\"Allscope,ReadOnly\"«»)]$Nb)

#Pour l'erreur d'affectation $nb=10
trap {Write-host \"$($_.exception.message)\" -fore red ;continue}

\"Nb\"|Get-Variable|Set-VariableOptions
Write-host \"Avant modification `$nb= $nb\"
$nb=10
Write-host \"Après tentative de modification `$nb= $nb\"
}
Test 5
[/code:1]
Il n’est pas possible d’utiliser l’argument de validation Validatescript pour exécuter le code de Set-VariableOptions, car la variable n’est pas encore déclarée lorsque Validatescript est appelé, on ne reçoit que la valeur du paramètre et pas le nom de la variable associé à ce paramètre.
On peut aussi utiliser d’autres attributs, tels que ProviderConstraintAttribute présent dans le projet PSCX. Il restera à modifier la fonction Set-VariableOptions pour prendre en compte chaque nouvel attribut que votre code utilisera.

Je vous proposerais prochainement un tutoriel sur les fonctions avancées sous PS v2.<br><br>Message édité par: Laurent Dardenne, à: 12/01/10 18:17

Une évolution du code de gestion des attributs (le code CSharp de l'attribut ne change pas) :
[code:1]
function global:Initialize-VariableAttributes{
&lt;#
.SYNOPSIS
Initialise le code associé aux attributs dotnet d'une variable.
Les attributs gérés par PowerShell, tels [Alias],[AllowNul()],etc ne sont pas concernés.

.DESCRIPTION
Une fonction peut utiliser un attribut dotnet sur un paramètre, celui-ci
est pris en compte, mais le code associé n'est pas exécuté par PowerShell.

Cette fonction parcourt la liste des attributs d'une variable afin d'exécuter le code
que vous lui avez associé. Elle valide également les attributs AttributeUsageAttribute
pouvant être placés sur les classes d'attribut que vous utilisez.

L'appel de cette fonction doit être placé au début de vos codes, si et seulement si
ils utilisent des attributs dotnet sur leurs paramètres.

Si vous utilisez uniquement les attributs gérés par PowerShell, l'usage de cette fonction
n'est pas nécessaire.

.PARAMETER Variable
Variable concernée par cette initialisation.

.PARAMETER CodeAttributes
Hashtable contenant le code associé à chaque type d'attribut que vous utilisez dans les
déclarations de vos scripts et fonctions.
Étant donné que la liste des attributs pouvant être utilisés est inconnue, il vous appartient
de créer cette hashtable.

Chaque entrée de cette hashtable doit avoir une clé de type [String], elle référence
le nom du type de l'attribut, et une valeur de type [ScriptBlock], elle contient le code
associé au nom de type de l'attribut.

Une exception de validation est déclenchée si cette hashtable ne respecte pas cet usage,
ou si Le Scriptblock associé est $null.
Une exception est déclenchée si le Scriptblock associé est vide.

La variable contenant ces informations peut être de portée globale ou locale.

Lorsque vous utilisez un nouvel attribut vous devez pensez à ajouter une entrée correspondante
dans cette hastable.

.EXAMPLE
$CodeAttributesTable =@{
#Nom du type de l'attribut #Code associé à exécuter.
\&quot;PowerShell.Attributes.VariableOptionAttribute\&quot;={$Variable.Options=$Current.Options}
}

function Test([PowerShell.Attributes.VariableOption(\&quot;Allscope,ReadOnly\&quot;«»)]$Nb)
{
#Appel obligatoire
$PSBoundParameters.GetEnumerator()|
Foreach {$_.Key}|
Get-Variable|
Initialize-VariableAttributes -CodeAttributes $CodeAttributesTable
$nb=10
}

Description

---

On déclare d'abord une hashtable contenant le code associé à chaque attribut dotnet,
la variable $Current est utilisée en interne dans cette fonction et représente
l'attribut en cours de manipulation.

Puis on déclare une fonction Test, dont le paramètre $NB posséde l'attribut
VariableOption.
La première ligne de la fonction Test exécute, via la hashtable $CodeAttributesTable,
le code associé à l'attribut VariableOption placé sur le paramètre $Nb.

Une fois ce code exécuté, la propriété Options de la variable $NB contiendra les valeurs
précisées dans l'attribut, à savoir ici, Allscope et ReadOnly.

Enfin, les options étant configurées, l'affectation ultérieure d'une valeur sur la variable $Nb
déclenchera une exception.

.EXAMPLE
function Test (
[PowerShell.Attributes.VariableOption(\&quot;ReadOnly\&quot;«»)]
[PowerShell.Attributes.VariableOption(\&quot;Allscope\&quot;«»)]$Nb){

#Appel obligatoire
$PSBoundParameters.GetEnumerator()|
Foreach {$_.Key}|
Get-Variable|
Initialize-VariableAttributes -CodeAttributes $CodeAttributesTable }

Description

---

Cet exemple provoquera l'exception \&quot;L'attribut $AttributParameter est dupliqué.\&quot;, car
l'attribut AttributeUsage,placé sur la classe VariableOption, spécifie AllowMultiple=false.
Retirez les déclarations dupliquées pour corriger l'erreur.

.INPUTS
Attend un objet de type [System.management.Automation.PSVariable]

.OUTPUTS
Aucun. Initialize-VariableAttributes ne génère pas de sortie.

.FUNCTIONALITY
Language

.COMPONENT
PowerShell

.ROLE
SoftwareDeveloper
.LINK
projets.developpez.com/wiki/add-lib

#&gt;

Param(
[Parameter(Mandatory = $true,Position=0,
ValueFromPipeline = $true,
HelpMessage=\&quot;Variable à modifier.\&quot;«»)]
[ValidateNotNull()]
[System.management.Automation.PSVariable] $Variable,

[Parameter(Mandatory = $true,Position=1,
HelpMessage=\&quot;Contient le code associé à chaque type d'attribut.\&quot;«»)]
[ValidateNotNullOrEmpty()]
[ValidateScript({
$true #On s'assure de renvoyer $true s'il n'y a pas d'erreur
$_.GetEnumerator()|
Where {!(($_.Value -ne $null) -And
($_.Key.GetType() -eq [string]) -And
($_.Value.GetType() -eq [ScriptBlock]))}|
Foreach {Throw \&quot;L'entrée $($_.Key) doit avoir un clé de type [String] et une valeur de type [ScriptBlock].\&quot;}
})]
[Alias(\&quot;Code\&quot;«»)]
[System.Collections.Hashtable] $CodeAttributes
)
Process {
Write-Debug \&quot;Initialize $($variable.Name).`r`n Nombre d'attributs à traiter $($Variable.Attributes.Count)\&quot;
#La liste contient 1 seul attribut on quitte
#Un paramétre simple contient au moins un attribut ParameterAttribute
#S'il est seulement contraint sur le type, il contient également ArgumentTypeConverterAttribute.
#Ce dernier cas n'est pas géré explicitement.
if ($Variable.Attributes.Count -eq 1) {Return}

#Valide les attributs des classes Attributs
$Variable.Attributes|
#Recherche ceux précisés plus d'une fois
Group TypeId|
Where {$_.Count -gt 1}|
Foreach {
$AttributParameter=$_.Group[0]
Write-Debug $AttributParameter
#Récupére les attributs du premier attribut du groupe
#On peut placer un attribut sur une classe Attribute
$AttributParameter.TypeId.GetCustomAttributes($true)|
#Récupére seulement l'attribut AttributeUsage
#On peut placer plusieurs attributs de différents types.
Where {($_.GetType() -eq [System.AttributeUsageAttribute])}|
Foreach {
#Enfin, vérifie que l'attribut autorise un usage multiple.
If ($_.AllowMultiple -eq $False)
{
#Erreur identique à celle du compilateur C#: CS0579
Throw (\&quot;L'attribut $AttributParameter est dupliqué.`r`n\&quot;+
\&quot;Il n'est pas possible de spécifier plusieurs fois le même attribut, \&quot;+
\&quot;sauf si l'attribut spécifie AllowMultiple=true dans AttributeUsage.\&quot;«»)
}
}
#todo propriété AttributeTargets ?
}

#Exécute le code associé à chaque Attribut
# de la variable.
#L'insertion des attributs dans la liste des attributs d'une variable,
#se fait dans l'ordre inverse de celui de leur déclaration.
$Variable.Attributes|
Foreach {
$Current=$_
$CurrentTypeName=$_.Gettype().Fullname
$CodeAttributes.GetEnumerator()|
Foreach {
if ($CurrentTypeName -eq $_.Key)
{
Write-Debug \&quot;Find : $CurrentTypeName\&quot;
#Exécute, dans la portée locale, le code
#associé au type de l'attribut courant
if ($_.Value.ToString() -eq [String]::Empty)
{ Throw \&quot;Le scriptblock associé au type d'attribut $($_.Key) est vide.\&quot;}
.($_.Value)
}#if
}#foreach CodeAttributes
}#foreach Variable.Attributes
}#bloc Process
}#Initialize-VariableAttributes
[/code:1]
J'ai ajouté qq contrôles, notamment le fait qu'un attribut peut être à usage unique et une variable contenant le code des attributs. Ceci n'oblige plus à modifier la fonction en cas d'utilisation d'un nouvel attribut.
Un exemple, on déclare le code des attributs dans une hashtable:
[code:1]
$global:CodeAttributesTable=@{
#Nom du type de l'attribut
\&quot;PowerShell.Attributes.VariableOptionAttribute\&quot;={
#Code associé à éxécuter.
#$Variable et $Current sont utilisées en interne par Initialize-VariableAttributes
write-debug \&quot;Execute code VariableOption\&quot;;$Variable.Options=$Current.Options}
}#$CodeAttributesTable
[/code:1]
Ensuite la fonction de test utilise la variable automatique $PSBoundParameters pour valider les attributs de chaque variable liée :
[code:1]function Test([PowerShell.Attributes.VariableOption(\&quot;Allscope,ReadOnly\&quot;«»)]$Nb)
{
#Pour l'erreur d'affectation $nb=10
trap {Write-host \&quot;$($_.exception.message)\&quot; -fore red ;continue}

#Appel obligatoire
$PSBoundParameters.GetEnumerator()|
Foreach {$_.Key}|
Get-Variable|
Initialize-VariableAttributes -CodeAttributes $CodeAttributesTable

#\&quot;Nb\&quot;|Get-Variable|% {$_.Options}
Write-host \&quot;Avant modification `$nb= $nb\&quot;
$nb=10
Write-host \&quot;Après tentative de modification `$nb= $nb\&quot;
}
Test 5
[/code:1]
Pour plus de détails voir l'aide intégré.
Cela un bonne aperçu de ce qu'il est possible de faire nativement avec la version 2, au travers des fonction avancées.

Le prochain exemple utilisera les attributs de PSCX v1.2.0, [Pscx.AcceptsWildcardsAttribute()] et [Pscx.ProviderConstraintAttribute()].


Si vous avez des questions, qui sait, n'hésitez pas...

Un autre exemple à l'aide d'attributs provenant de Pscx 1.2.0.0, qui doit donc être chargé, à moins de recopier le code source et d'utiliser Add-Type...

Cette fois-ci on place deux contraintes sur le paramètre $Path :
-[Pscx.ProviderConstraint] le contraint à référencer un pspath sur le provider FileSystem, on ne peut donc pas lui passer le chemin suivant \&quot;HKLM:\SOFTWARE\&quot;.
A l'origine on peut indiquer plusieurs noms de provider et précisé l'argument ConstraintPolicy, mais sous PS il faudrait modifier cette attribut manuellement car Pscx ne propose pas de constructeur autorisant les 2 arguments.
-[Pscx.AcceptsWildcards] le contraint à ne pas contenir de joker (globbing) dans son nom.
On peut récupérer les fichiers correspondant au path indiqué ainsi :
[code:1]
#Le path référence des jokers : ?, *, [a], [abc], [a-c], Test*[a][0-9],...
Resolve-Path $Path -ErrorAction SilentlyContinue
#renvoi un tableau de fichiers
[/code:1]
Le code de test :
[code:1]
function Test([Pscx.ProviderConstraint([Microsoft.PowerShell.Commands.FileSystemProvider])]
[Pscx.AcceptsWildcards($False)]
[Parameter(Mandatory = $true,Position=0,
ValueFromPipeline = $true,
HelpMessage=\&quot;Nom de chemin.\&quot;«»)]$Path)
{
process {
#Appel obligatoire
$PSBoundParameters.GetEnumerator()|
Foreach {$_.Key}|
Get-Variable|
Initialize-VariableAttributes -CodeAttributes $CodeAttributesTable
Write-host $Path
}
}
[/code:1]
Vous pouvez tester différents cas en modifiant l'argument des attributs.

Ensuite on crée le code de validation des attributs en complétant la hashtable précédente :
[code:1]
#Utilise Pscx 1.2.0.0 et Add-lib v1.2
#Pour Addlib remplacer le fichier PackageScripts.ps1 par la révision suivante :
# projets.developpez.com/repositories/entr...eScripts.ps1?rev=137
$global:CodeAttributesTable=@{
\&quot;PowerShell.Attributes.VariableOptionAttribute\&quot;={
write-debug \&quot;Execute code VariableOption\&quot;
$Variable.Options=$Current.Options
}

\&quot;Pscx.AcceptsWildcardsAttribute\&quot;={
write-debug \&quot;Execute code AcceptsWildcards\&quot;
If ( ($Current.Value -eq $false) -and ([Management.Automation.WildcardPattern]::ContainsWildcardCharacters($Variable.Value)))
{ Throw \&quot;Le globbing (?,*,[]) n'est pas supporté pour le paramètre $($Variable.Name).\&quot; }
}

\&quot;Pscx.ProviderConstraintAttribute\&quot;={
write-debug \&quot;Execute code ProviderConstraint\&quot;
#Recherche dans les providers celui qui implémente le type précisé par l'attribut
$ProviderInfo=Get-PSProvider|Where {$_.ImplementingType -eq $Current.ProviderTypes[0]}
#Un provider peut ne pas être chargé.
if ($ProviderInfo -eq $null)
{Throw \&quot;Le provider $($Current.ProviderTypes[0]) est inconnu dans la liste des providers actifs.\&quot;}
Write-Debug $ProviderInfo.Name
If ( !(Test-PSProviderPath $Variable.Value $ProviderInfo.Name))
{ Throw \&quot;Le paramètre $($Variable.Name) ne peut référencer que le provider $($Result.Name).\&quot; }
}
}#$CodeAttributesTable
[/code:1]
Le code de l'attribut ProviderConstraint nécessite de rechercher le nom du provider via la classe passée en argument, FileSystemProvider.
Ce qui est également réalisé dans la fonction Test-PSProviderPath qui renvoi $true si le chemin $Path référence le provider $ProviderInfo.Name.
Ce code utilise des fonctions du projet Add-lib v1.2.

Quelques appels :
[code:1]
cd Env:
\&quot;C:\Windows\notepad.exe\&quot;,
\&quot;C:\Windows\*.exe\&quot;,
\&quot;Truc:\Windows\*.exe\&quot;,
\&quot;..\*.exe\&quot;,
\&quot;ORCL:\*.exe\&quot;|Test
[/code:1]

Quels est l'intérêt d'une telle pratique ? Pour moi, elle permet de centraliser des traitements de validation de paramètres récurents.
Le code des fonctions/scripts et plus lisible, on se concentre sur le traitement.
Peut être que la version 3 de PowerShell gérera les attributs dotnet...

On peut aussi utiliser uniquement l'attribut de validation de PowerShell, [ValidateScript()]
[code:1]
#Réutilisation des régles de validation personnelles.
function FnctValidation()
{$_ -lt 4}

Function Test{
Param (
[ValidateScript({FnctValidation})]
#[ValidateScript({&amp;C:\temp\TestValidation.ps1})]
#[ValidateScript({$_ -lt 4})]
[int] $Count)
$count
}
Test 5
[/code:1]
Peut être plus simple.
On peut placer les fonctions de validation dans un module et l'importer via le profile ou au cas par cas.

Comme disait un rappeur, Agathe-ThePower
<br><br>Message édité par: Laurent Dardenne, à: 12/01/10 17:11

Après qq tests supplémentaires, l'usage d'attribut dotnet, autre que ceux de PowerShell, ne fonctionne pas avec le pipeline (j'ai corrigé l'exemple précédent).

Il y a deux problèmes, le premier est du à un bug dans la gestion des fonctions avancées:
[code:1]function do-something {
#[CmdletBinding()]
Param (
[Parameter()]
[system.management.automation.credential()]$cred,
[Parameter(Mandatory=$True,ValueFromPipeline = $true)]
$ComputerName)

process {
$cred}
}
Trace-Command -name ParameterBinding {\&quot;localhost\&quot;|do-something} –File Trace.log
#https://connect.microsoft.com/PowerShell/feedback/ViewFeedback.aspx?FeedbackID=509985
[/code:1]
Ici le code de l'attribut est exécuté 5 fois au lieu d'une, on peut le voir dans le fichier Trace.log

Le second est que l'appel, de la fonction Initialize-VariableAttributes dans un bloc process, exécute la validation de tous les paramètres et pas seulement ceux qui sont liés via le pipeline. Si le premier appel positionne la variable en lecture seule, les autres appel provoqueront une exception.
Pour les attributs de validation de PowerShell, ceux-ci ne sont exécutés que si le contenu de la variable est modifié lors du binding (liaison de paramètres).

Et enfin le plus gênant la liste des attributs du paramètre est \&quot;vidé\&quot; après le premier appel du bloc process. Les régles de validation portées par les attributs de validation de PowerShell reste tout de même active :
[code:1]
function Test([ValidateNotNull()]
[Pscx.ProviderConstraint([Microsoft.PowerShell.Commands.FileSystemProvider])]
[Pscx.AcceptsWildcards($False)]
[Parameter(Mandatory = $true,Position=0,
ValueFromPipeline = $true,
HelpMessage=\&quot;Nom de chemin.\&quot;«»)]$Path)
{
process {
Write-host $Path
\&quot;Path\&quot;|
Get-Variable|
Initialize-VariableAttributes -CodeAttributes $CodeAttributesTable
}
}

\&quot;C:\Windows\notepad.exe\&quot;,
\&quot;C:\Windows\*.exe\&quot;,
$null |Test
[/code:1]
En passant j'ai relu les release notes de la RC,il y est dit, entre autres, ceci :

-Reserved language keywords: USING, CLASS, DEFINE, and VAR
-Reserved parameter names: –SelectProperty and –SelectObject

Les 2 paramètres sont bien réservés et provoque une erreur si on les utilise.
Les mots clé existent bien dans la liste des tokens du langage, merci Reflector, et annonce à priori des évolutions du langage.

Dommage, j'aimais bien l'idée de ne pas coder en langage compilé
Bon, il reste l'attribut ValidateScript qui suit le même principe, mais cela implique de convertir le code C# de certains attributs, tel Credential.

Un coup dans l'eau

Il est possible d'utiliser des fonctions de validation placées dans un module :
[code:1]$VMException=\&quot;System.Management.Automation.ValidationMetadataException\&quot;

$ErrorMsg= \&quot;Le globbing (?,*,[]) n'est pas supporté ({0}).\&quot;

Function Test-AcceptsWildcards($InputObject,[switch] $No){
#régle de validation d'argument :
# Un path peut ne pas accepter le globbing.

If ( $No -and `
([Management.Automation.WildcardPattern]::ContainsWildcardCharacters($InputObject)))
{ throw (new-object $VMException ($ErrorMsg -F $InputObject)) }
$true # La valeur est valide
}[/code:1]
Le problème est qu’un module défini un état de session différent de la session courante de PowerShell, ce qui fait que la variable $_, pour ce cas, ne peut être utilisée, car elle ne référence pas la valeur de l'argument passée au code de l'attribut ValidateScript.

On doit déclarer un paramètre dans la fonction de validation et le passer en ligne de commande dans la déclaration de l’attribut :
[code:1]
#charge le module à partir du chemin courant
Import-Module .\ValidationsArgument.psm1 -force

function Test( [ValidateScript( {Test-AcceptsWildcards $_ -No} )]
[Parameter(ValueFromPipeline = $true)] $Path)
{
$Path
}
\&quot;C:\*.exe\&quot;|Test[/code:1]
Ainsi cela fonctionne, on obtient donc l’erreur suivante :

Test : Impossible de valider l'argument sur le paramètre « Path ». \&quot;Le globbing (?,*,[]) n'est pas supporté (C:\*.exe).

Correction de :
Laurent Dardenne écrit:

On doit déclarer un paramètre dans la fonction de validation et le passer en ligne de commande dans la déclaration de l’attribut :

Il est possible de référencer les variables de l'appelant en procédant ainsi :
Le paramètre additionnel n'est pas nécessaire,
on doit déclarer la fonction avec :
[code:1]
[CmdletBinding()]
[/code:1]
ensuite
[code:1] $Variable_De_l_Appelant=$PSCmdlet.SessionState.PSVariable.Get(\&quot;_\&quot;«»).Value
[/code:1]
Merci à Bruce Payette et au programme MEAP.
Mais coup de pied au c.. à MS pour sa documentation fantomatique, voir en toc