2008-08-20 18 views
22

¿Alguien ha averiguado cómo hacer que PowerShell use los archivos app.config? Tengo un par de .NET DLL que me gustaría usar en uno de mis scripts pero esperan que sus propias secciones de configuración estén presentes en app.config/web.config.PowerShell App.Config

Respuesta

32

referencias cruzadas con este hilo, que me ayudó con la misma pregunta: Subsonic Access To App.Config Connection Strings From Referenced DLL in Powershell Script

he añadido lo siguiente a mi guión, antes de invocar la DLL que necesita ajustes de configuración, donde $ configPath es la ubicación de la archivo que desea cargar:

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

Wow ... una respuesta después de todos estos años :). Gracias voy a dar una oportunidad. – Kev

+0

+1 ¡Muchas gracias! En toda la red, la única solución mencionada para este problema es 'ConfigurationManager.OpenMappedExeConfiguration' y ninguna para un escenario en el que no tengamos control sobre el ensamblado al que se hace referencia. Esto funciona perfecto para mi caso. – fozylet

+2

Este código no funcionó, terminé usando la solución de Robert Mooney: http://stackoverflow.com/questions/16216736/loading-app-config-into-the-appdomain#answer-33290175 –

6

Supongo que las configuraciones tendrían que estar en powershell.exe.config en el directorio de powershell, pero eso parece ser una mala forma de hacer las cosas.

Puede usar ConfigurationManager.OpenMappedExeConfiguration para abrir un archivo de configuración basado en el nombre de la DLL de ejecución, en lugar del exe de la aplicación, pero esto obviamente requerirá cambios en las DLL.

+0

No recomendaría esta solución. Envuélvalo en una aplicación de consola que escriba datos como JSON en STDOUT o en la aplicación ASP.NET WebAPI. La elección entre la consola y la API dependerá del alojamiento y la seguridad. – yzorg

+0

Otra razón para NO usar esto: PowerShell se actualiza con el sistema operativo y powershell.exe.config es un archivo de sistema operativo protegido, lo que significa que no puede ser editado con un bloc de notas. – yzorg

2

Intentar una nueva respuesta a una vieja pregunta.

Creo que la respuesta moderna sería: no hagas eso. PowerShell es un caparazón. La forma normal de pasar información entre partes del shell son variables de shell. Para PowerShell que se vería así:

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

Si se espera que los ajustes que se hereda a través de los procesos de los límites de la convención es utilizar variables de entorno. Extiendo esto a configuraciones que cruzan el límite de C#/PowerShell. Un par de ejemplos:

$env:PATH 
$env:PSModulePath 

Si usted piensa que esto es un anti-patrón para .NET es posible que desee volver a examinar. Esta es la norma para las aplicaciones alojadas en PAAS, y será la nueva configuración predeterminada para ASP.NET que se ejecuta en CLR optimizado para servidor (ASP.NET v5).

Ver https://github.com/JabbR/JabbRv2/blob/dev/src/JabbR/Startup.cs#L21
Nota: en el momento de la escritura que estoy ligarse a .AddEnvironmentVariables()

he revisited esta pregunta varias veces, incluyendo preguntando por mí mismo. Quería poner una estaca en el suelo para decir que las cosas de PowerShell no funcionan bien con <appSettings>. OMI es mucho mejor adoptar el aspecto shell de PS sobre el aspecto .NET a este respecto.

Si necesita una configuración compleja, tome una cadena JSON. POSH v3 + tiene ConvertFrom-JSON incorporado. Si todo en su proceso utiliza la misma configuración compleja, colóquelo en un archivo .json y apunte a ese archivo desde una variable de entorno.

Si un solo archivo no es suficiente, hay soluciones bien establecidos como el patrón PATH, GIT .gitignore resolución o resolución ASP.NET web.config (que no voy a repetir aquí).

+1

"* no hagas eso. *" - claro, y aprecia el tiempo que has puesto en esta respuesta. Pero las variables de entorno, etc. no funcionarán con estos ensamblajes heredados, esperan poder leer sus configuraciones de la colección 'AppSettings'. – Kev

+0

@Kev Entonces esos ensamblajes realmente no deberían usarse en un contexto de PowerShell. Es posible que deba alojar PowerShell usted mismo. Consulte "incrustación de PowerShell", en la "Consola de administrador de paquetes" de Visual Studio. – yzorg