Problème d'assembly depuis un objet

Version imprimable

Bonjour à tous
Je suis confronté au problème d'appel des "assembly" depuis des objets.

Un exemple parlant bien plus que des mots, je vous présente une portion de code qui résume à lui tout seul mon problème
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 Add-Type -AssemblyName System.Windows.Forms Add-Type -AssemblyName System.Drawing Class W_Dialog { # Classe de gestion de l'affichage d'une fenêtre type PopUp # ========================================================= # Propriétés [String] $titre = "" [String] $texte = "" [Int] $icone = 0 # 0 : Aucune icône | 16 : Erreur | 32 : Question | 48 : Avertissement | 64 : Information [Int] $bouton = 0 # 0 : OK | 1 : OKCancel | 2 : AbortRetryIgnore | 3 : YesNoCancel | 4 : YesNo | 5 : RetryCancel [String] $reponse = "" # Méthodes Create() { # Création et affichage de la fenêtre de type PopUp $this.reponse = [System.Windows.Forms.MessageBox]::Show($this.texte, $this.titre,$this.bouton,$this.icone) } } [W_Dialog] $msgbox = @{'titre' = "Information"; 'texte' = "Ceci est un test"; 'bouton' = 0; 'icone' = 32;} $msgbox.Create()
Quand je lance mon script, j'ai un beau message d'erreur m'indiquant qu'il ne trouve pas System.Windows.Forms.MessageBox alors que je l'ai déclaré au tout début de mon script.

Si je crée un second script
Code:

1 2 Add-Type -AssemblyName System.Windows.Forms Add-Type -AssemblyName System.Drawing
Et que je le lance dans une console PS, puis qu'ensuite je lance mon script initial dans cette même console PS, cela fonctionne.
Où est ce que je pêche ? Comment dois je permettre à PowerShell de prendre en compte mes déclarations d'assembly ?
Ma seule contrainte non négociable est de ne posséder qu'un seul fichier PS1, pour une très grande portabilité (pas de module d'auto-chargement ou autre à placer dans d'autres répertoires).

Je vous remercie d'avance.

18/03/2021, 15h02
ericlm128

Il semble que ce soit ta classe W_Dialog qui masque les type ajoutés.
Je ne sais pas trop pourquoi car je n'utilise pas souvent les Class en powershell je découvre donc le phénomène.
Mais c'est intéressant :)

Il en parle ici :
https://stackoverflow.com/questions/...37458#34637458
https://stackoverflow.com/questions/...37458#34637458
https://github.com/PowerShell/PowerS...ment-297151112
https://github.com/PowerShell/PowerShell/issues/6652

Ps : Essaie d'utiliser les bon types
Ps : Lors de l'utilisation du splatting les variables ne sont pas entre-coté

Si ça peux t'aider à comprendre ceci fonctionne

Code:

1
2
3
4
5
6
7
8
9
10
11
12
Add-Type -AssemblyName System.Windows.Forms
 
Invoke-Expression @‘
Class W_Dialog {
    Create()
    {
        [System.Windows.Forms.MessageBox]::Show("texte", "titre")
    }
}
'@
 
[W_Dialog]::new().Create()

18/03/2021, 15h43
Aknot

Bonjour Eric
Merci pour ta réponse très claire, elle répond très bien à ma problématique ! :D
Je vais donc m'orienter vers cette solution.
Pour répondre à ta remarque concernant la mise entre quotes de mes clefs dans les [HashTable], c'est surtout parce que j'utilise souvent des nombres au format chaine de caractères pour les définir. Ce n'est vraisemblablement pas la bonne méthode, mais elle me permet de mieux déboguer mes scripts au prompt.

Je clos donc le sujet.
18/03/2021, 16h32
ericlm128

Oui enfin c'est claire sans vraiment l'être, si quelqu'un de plus calé à une réponse plus précise sur ce comportement et contournement possible je suis preneur
18/03/2021, 19h11
Laurent Dardenne
Salut,

Citation:

Envoyé par ericlm128

Oui enfin c'est claire sans vraiment l'être, si quelqu'un de plus calé à une réponse plus précise sur ce comportement et contournement possible je suis preneur

Je ne sais si je suis plus 'calé' mais j'ai qq infos sur le sujet.
Comme il est dit dans les posts que tu as cités, le parseur Powershell traite d'abord les définitions de classes puis traite les autres instructions du script.
On a donc ce comportement déroutant qui fait que les instructions que l'on lit séquentiellement ne sont pas exécuté dans l'ordre.
Il est recommandé d'utiliser un module pour déclarer des classes, bien que d'autres problèmes surviennent dans ce cas.

Il est préférable d'éviter l'usage du cmdlet Invoke-expression.

Il existe un cas où une classe PS peut en masquer une autre, si elle porte le même nom :
Code:

1 2 3 4 5 6 7 8 Add-type -TypeDefinition @' public class Test { public string Name; } '@ Class Test { [Int] $Name;}
Pour info :

Citation:

De : Jason Shirk (POWERSHELL)
Envoyé : vendredi 18 septembre 2015 17:27
Objet : RE: [PSMVP] Powershell classes hidde dotnet classes ?

- Is it by design that the existing Powershell classes hidde dotnet classes ?

Yes, PowerShell classes are defined in their own assembly (one per script/module) and each assembly can define types with the same name.
This may be useful for mocking.
18/03/2021, 19h19
Laurent Dardenne

Voir aussi ce post et celui-ci sur les classes/modules.
18/03/2021, 21h36
ericlm128

Citation:

Comme il est dit dans les posts que tu as cités, le parseur Powershell traite d'abord les définitions de classes puis traite les autres instructions du script.
On a donc ce comportement déroutant qui fait que les instructions que l'on lit séquentiellement ne sont pas exécuté dans l'ordre.
Il est recommandé d'utiliser un module pour déclarer des classes, bien que d'autres problèmes surviennent dans ce cas.

Il est préférable d'éviter l'usage du cmdlet Invoke-expression.

Merci pour ta réponse/traduction :)
Je comprend finalement mieux pourquoi je n'utilise pas les classe en Powershell :lol:
J'espère qu'il améliorerons ce fonctionnement dans les futurs versions