Question AD OU Keep tree order

6ratgus écrit:

Laurent
j’essaie de partir sur des solutions simples qui sont souvent les meilleurs.

Oui, mais parfois on ne le sait qu'à la fin
Il faut aussi reconnaitre quand on fait fausse route.
6ratgus écrit:

C'est dommage car tu avais donné la bonne réponse dés le début.

La réponse peut être pas, une piste probablement.

D'habitude je ne réponds pas aux questions sur L'AD, car je ne maîtrise pas le sujet et surtout je n'ai pas d'AD de test sous la main.
Je peux coder des traitements autour de l'AD, mais cela ne fait pas de moi un admin, car ce n'est pas mon activité quotidienne.
6ratgus écrit:

a savoir enregistrer des info dans un CSV avec un ordre des noms de colonnes différent que celui par défaut.

Je comprends, bien qu'un mécanisme de stockage ne soit pas en théorie considéré comme ordonné.
C'est le traitement sur les données qui le nécessite, on ne doit pas coupler les deux. Mais souvent on 'triche'.
6ratgus écrit:

Par contre pour le passage de paramètre, j'ai pas compris le miracle ToString !
...
Va tu me répondre la même chose :

Non.
6ratgus écrit:

Ma compréhension me dis que dir vois que $obj n'est pas un objet System.IO.DirectoryInfo

Dir renvoie de tel objet, mais le paramètre -Path attend un type string, un tableau de string ( [string[]] )
D'où l'importance de savoir lire la doc d'un cmdlet, la difficulté pour un débutant est qu'il doit connaitre ces points pour comprendre tout ce que la doc porte comme informations implicites.
Il faut donc commencer par apprendre des points avancés pour expliquer des points simples...
Mais pour un usage basique de cmdlet, ce n'est pas nécessaire.

Ce n'est pas le cmdlet, mais la partie analyse de paramètre commune à tout code PS qui se charge de cette tâche.
Cette analyse, le 'ParameterBinding', lit les métadonnées du cmdlet/fonction/script/scriptblock puis fait sa cuisine.
6ratgus écrit:

et il tente de le convertir l'argument en string,

Le ParameterBinding oui, pas le cmdlet. Si on simplifie on peut dire que c'est lui qui rempli ce rôle.
( Les attributs de paramètres sont destinés au 'ParameterBinding' et c'est lui qui contrôle et renseigne les arguments des paramètres d'un cmdlet/fonction/etc. )

Ici cela fonctionne, car le paramètre ciblé, -Path, est du type string. Pour un autre type cela ne peut pas fonctionner.
A moins qu'on suppose les conversions :
[code:1]
$O=1|select PID
#PID n'est pas typé
$O.PID=\"$pid\"
# ParameterBinding trouve la propriété PID et la transforme avec succès en [int]
$O|Get-Process

#La transformation en [int] échoue
$O.PID=\"toto\"
#ParameterBindingException
$O|Get-Process
[/code:1]
Ici on ne peut pas mettre à contribution la méthode ToString(), car -PID attend un [int].
Pour typer le membre il faut utiliser d'autres techniques .
6ratgus écrit:

et toi tu interceptes cette demande de conversion (pour renvoyer $this.Name) ?

Oui, plus précisément je sais que dans la cas exposé le 'ParameterBinding' appelle ToString() avant d'affecter la valeur à -Path.
Je fais donc en sorte que lors de l'appel, l'objet renvoi l'information attendue. Mais ce n'est pas une interception/ Hook .
Si je change de contexte( de cmdlet) l'info renvoyée peut ne pas correspondre. On revient donc au point de départ.
Le membre de type Alias est plus beaucoup plus souple pour diriger le 'ParameterBinding' selon les besoins.

6ratgus écrit:

pour un débutant c'est pas évident parfois

Tout à fait.
Mais comme je l'ai déjà dit, moins tu en dis en formation moins tu en as expliquer. C'est un choix avec ces avantages et ces inconvénients.
6ratgus écrit:

mais il faut un bon forum \"d'Entraide pour les débutants\" alors

Il peut faire gagner du temps, mais ne remplace pas un travail personnel.