PowerShell App.Config

Question

Quelqu'un a-t-il trouvé comment utiliser PowerShell app.config des dossiers?J'ai quelques DLL .NET que j'aimerais utiliser dans l'un de mes scripts, mais ils s'attendent à ce que leurs propres sections de configuration soient présentes dans app.config/web.config.

Answer 1

Recoupement avec ce fil de discussion, qui m'a aidé avec la même question :Accès subsonique aux chaînes de connexion App.Config à partir de la DLL référencée dans le script Powershell

J'ai ajouté ce qui suit à mon script, avant d'appeler la DLL qui nécessite des paramètres de configuration, où $configpath est l'emplacement du fichier que je souhaite charger :

[appdomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $configpath)
Add-Type -AssemblyName System.Configuration

Voir ce post pour garantir que le fichier de configuration spécifié est appliqué au contexte en cours d'exécution.

Answer 2

Je suppose que les paramètres devraient être dans powershell.exe.config dans le répertoire PowerShell, mais cela semble être une mauvaise façon de faire les choses.

Vous pouvez utiliser ConfigurationManager.OpenMappedExeConfiguration pour ouvrir un fichier de configuration basé sur le nom de la DLL en cours d'exécution, plutôt que sur l'exe de l'application, mais cela nécessiterait évidemment des modifications des DLL.

Answer 3

Tenter une nouvelle réponse à une vieille question.

Je pense que la réponse moderne serait :ne fais pas ça.PowerShell est un shell.La manière normale de transmettre des informations entre les parties du shell consiste à utiliser des variables shell.Pour PowerShell, cela ressemblerait à :

$global:MyComponent_MySetting = '12'
# i.e. 
$PSDefaultParameterValues
$ErrorActionPreference

Si les paramètres doivent être hérités au-delà des limites des processus, la convention consiste à utiliser des variables d'environnement.J'étends cela aux paramètres qui dépassent les limites de C#/PowerShell.Quelques exemples :

$env:PATH
$env:PSModulePath

Si vous pensez qu'il s'agit d'un anti-modèle pour .NET, vous voudrez peut-être reconsidérer votre décision.Il s'agit de la norme pour les applications hébergées PAAS et ce sera la nouvelle valeur par défaut pour ASP.NET exécuté sur un CLR optimisé pour le serveur (ASP.NET v5).

Voir https://github.com/JabbR/JabbRv2/blob/dev/src/JabbR/Startup.cs#L21
Note:au moment de la rédaction, je crée un lien vers .AddEnvironmentVariables()

J'ai revisité cette question à plusieurs reprises, notamment en la posant moi-même.Je voulais mettre un point d'honneur à dire que les éléments PowerShell ne fonctionnent pas bien avec <appSettings>.OMI, il est bien préférable d'adopter l'aspect shell de PS plutôt que l'aspect .NET à cet égard.

Si vous avez besoin d'une configuration complexe, utilisez une chaîne JSON.POSH v3+ a ConvertFrom-JSON intégré.Si tout dans votre processus utilise la même configuration complexe, placez-le dans un fichier .json et pointez vers ce fichier à partir d'une variable d'environnement.

Si un seul fichier ne suffit pas, il existe des solutions bien établies comme PATH modèle, GIT .gitignore résolution, ou ASP.NET web.config résolution (que je ne répéterai pas ici).