Pour infos si on renseigne le nom de fichier de ressources, cela ne fonctionne pas:
[code:1]
$Global:messages = import-localizeddata \"G:\PS\Log4NET\testlocal\fr-FR\PackageLog4Net.psl1\" $myculture
[/code:1]
J'utilise ce cas car j'ai un script d'initialisation
InitializeLG4N.ps1 et ce script charge le script
PackageLog4Net.ps1 qui lui est localisé.
Le parsing suivant du nom de fichier ne se fait pas :
[code:1]$FileName = [IO.Path]::GetFileNameWithoutExtension((split-path -Leaf $MyInvocation.MyCommand))[/code:1]
Au passage sous PS V1, l'appel suivant suffit :
[code:1] [IO.Path]::GetFileNameWithoutExtension($MyInvocation.MyCommand)[/code:1]
Donc si on déplace cette instruction dans le corps du script pour tester les 2 cas, alors il faut interroger le scope de l'appelant :
[code:1]
write-host \"FileName : $FileName\" -fore green
$ParentInvocation = (Get-Variable MyInvocation -Scope 1).Value
write-host \"Invoke $($ParentInvocation.MyCommand)\" -fore green
if ($FileName -eq [String]::Empty)
{ $FileName=$ParentInvocation.MyCommand }
$FileName= [IO.Path]::GetFileNameWithoutExtension($FileName)
write-host \"FileName : $FileName\" -fore green
[/code:1]
De mon coté, pour faciliter la distinction des noms de fichiers j'ai renommé en DataFileName et CallerScriptName.
Une dernière, si une des ligne ne respecte pas la structure
ChaîneClé=ChaîneContenu, par exemple
;test alors le script part en erreur, normal. Mais dans ce cas on a un peu de mal à savoir ce qui se passe.
Cas d'erreur :
;todo
=
A=
=B
t=#dir#
C#=Language
#tests pour unescape
K1=\t\Tabulation
K2=\t\Tabulation
K3=Tabulation\x
K4=Tabulation\z
K5=c:\test\fichier.txt
K6=\"c:\test\fichier.txt\"
#Seul le nom de fichier suivant est pris en compte sans erreur
K7=\"c:\\test\\fichier.txt\" #ce commentaire est inclus dans la valeur de la clé
\tK1=Tab
J'ai ajouté le contrôle suivant, pour les exceptions levées par $Ht.Add et $Value=[Regex]::Unescape :
[code:1]
...
Foreach {
trap [System.ArgumentException] {Write-error \"$key=$value`r`n$($_.Exception.Message)\";Continue}
...
[/code:1]
Ensuite pour la chaîne d'origine suivante :
[code:1]Throw \"Add-LogAppender : le paramètre Logger n'implémente pas l'interface ILoggerWrapper.\"[/code:1]
je déclare la chaîne :
NotImplementInterface={0} : le paramètre {1} n'implémente pas l'interface {2}.
sa construction se fait par l'appel suivant :
[code:1]
throw $messages.NotImplementInterface -F \"Add-LogAppender\",\"Logger\",\"ILoggerWrapper\"
[/code:1]
Rien d'extraordinaire donc.
Si on souhaite effectuer d'autres traitements par exemple un expandstring, on peut créer une méthode sur la hashtable au lieu de créer des routines annexes (je suppose une seule hashtable de localisation par script):
[code:1]
$messages=$messages|add-member ScriptMethod Get {
#Args[0] contient par convention la clé de la Hashtable
# -F recoit un tableau de string
$this.Item($Args[0]) -F $Args[1..($Args.Count-1)]
# Exemple pour : NullParameter={0} : le paramètre {1} est à null.
# $Datas.Get(\"NullParameter\",\"Getlogger\", \"Logger\"«»)
#Si on passe à la fonction formatage plus de paramètres que nécessaire cela ne pose pas de pb
} -pass
$messages=$messages|add-member ScriptMethod ExpandString{
$ExecutionContext.InvokeCommand.ExpandString($this.Item($Args[0]) )
} -pass
#$messages=$messages|add-member ScriptMethod UnEscape, etc
#Appels
throw $messages.Get(\"NotImplementInterface\",\"Add-LogAppender\",\"Logger\",\"ILoggerWrapper\"«»)
throw $messages.ExpandString(\"FileError\"«»)
[/code:1]
Il reste, je pense, un cas à étudier : J'utilise la culture par défaut US mais sur un poste configuré par exemple en cyrillique, en arabe ou en japonais.
Dans ce cas je ne sais pas ce que donnera l'affichage, j'ai donc relu ce
post
. A ton avis pour le tester l'installation d'une de ces pages de code suffit ?<br><br>Message édité par: Laurent Dardenne, à: 11/02/09 15:46
