2009-05-07 9 views
17

J'ai un script Powershell qui charge un assembly .NET (.EXE dans mon cas) et appelle une méthode publique qui utilise app.config pour extraire une chaîne de connexion cryptée.Powershell Calling .NET Assembly utilisant App.config

Le script copie dynamiquement le fichier exe.config de l'assembly dans le dossier Powershell ($ pshome) sous le nom powershell.exe.config et peut très bien s'exécuter à partir de ma boîte de développement. Le problème est qu'il ne s'exécute pas à partir d'une installation standard de Windows Server 2003.

J'ai vérifié que le fichier exe.config est copié dans le répertoire PowerShell correctement. J'ai lancé SysInternals Process Explorer et vérifié que le processus accédait aux fichiers de configuration (aucun fichier non trouvé). J'ai débogué à distance l'instance de powershell.exe et je peux voir que l'assembly se charge bien mais ne peut pas accéder aux valeurs de [...] ConfigurationManager.AppSettings (retourne null).

Je suis à court d'idées. J'ai lu que je peux être en mesure d'utiliser un domaine d'application distinct, mais je ne vois pas d'exemples de faire cela avec Powershell.

Mon code fait quelque chose à l'effet de:

$absolute_path = "c:\foo.exe" 
$config_path = $absolute_path + ".config" 
copy "$config_path" "$pshome\powershell.exe.config" -Force 
[Reflection.Assembly]::LoadFrom($absolute_path) 
$foo = new-object MyFooAssembly.FooClass 
$foo.DoSomething() 

Dans Vista le code fonctionne, dans Windows Server 2003, le code ne fonctionne pas.

Répondre

35

Essayez:

[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $config_path) 
+0

Si cela fonctionne, vous serez mon héros. –

+0

Confirmé que cela fonctionne avec un ensemble noddy construit dans VS2008 et fonctionnant sous XP, ne pas avoir WS2003 à portée de main, mais j'espère que cela fonctionne aussi. S'il vous plaît tester et voter si heureux :) –

+0

Été hors de la boucle quelques jours, va donner un coup de feu demain. Merci! – GabeA

4

Après des recherches plus loin, j'ai découvert la cause. Plus tôt dans le script, je chargeais SMO:

$null = [reflection.assembly]::loadwithpartialname("microsoft.sqlserver.smo") 

Je crois que c'est un peu comment mes réglages de configuration manquent. La solution était de faire comme Chris mentionne ci-dessus pour ce premier appel:

[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $null) 
$null = [reflection.assembly]::loadwithpartialname("microsoft.sqlserver.smo") 

Et puis sur mon deuxième appel à un autre ensemble faire ceci:

$config_path = $assembly_exe + ".config" 
[System.AppDomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $config_path) 
[Reflection.Assembly]::LoadFrom($assembly_exe) 

problème semble être résolu ...

Questions connexes