Question guide de prod comment remplir un doc depuis wmi

Spirit écrit:

En fait non, ce n'est pas exactement un nombre.
C'est une structure de type System.UInt32.
Ce qui fait une légère différence ^^.

Pas du tout, les objets de type Int32 sont bien des nombres! D'ailleurs, il suffit de forcer le typage de la valeur pour que ça marche, sans avoir à aller chercher le Hash Code:

[System.Globalization.CultureInfo]::GetCultureInfo([int32]$a.OSLanguage)

Ca marche sans préciser [int32] avec la v2 de PowerShell, mais apparemment la v1 a besoin de se faire préciser le type pour une raison que j'ignore...

Janel

Bon, c'est vrai que tu exagères un peu, mais en même temps tu as raison de faire une distinction entre Int32 et UInt32.

Cela dit, pour ce qui est du bug de la v1, il faudra que je refasse des tests car maintenant je retrouve la même erreur avec la v2 alors que ça marchait quand j'ai posté mon message sur ce même fil... Bizarre!

A priori, le problème ne vient pas de la façon dont PowerShell traite les Int32 mais plutôt de la façon dont la méthode GetCultureInfo() traite ses paramètres: cette méthode a plusieurs syntaxes possibles, dont une qui accepte une String en paramètre. Or, de toute évidence cette méthode ne sait pas reconnaître un objet de type UInt32 comme étant potentiellement un Int32, donc elle le prend pour une String. Et comme la valeur passée ne correspond à aucun nom de culture connu, elle génère une erreur.

Quand on passe un UInt32 à une méthode qui attend un Int32, ça passe sans problème. Voir par exemple les méthodes statiques de la classe System.Math, elles prennent un UInt32 sans sourciller.

Il faudrait vérifier avec d'autres méthodes qui peuvent accepter soit un paramètre de type String soit un paramètre de type Int32 pour voir s'il s'agit d'un problème limité à GetCultureInfo() ou si c'est au niveau de PowerShell (ou du Framework) que la conversion se fait mal.

Janel