Cross-referencing with this thread, which 7 helped me with the same question: Subsonic Access To App.Config Connection Strings From Referenced DLL in Powershell Script
I added 6 the following to my script, before invoking 5 the DLL that needs config settings, where 4 $configpath is the location of the file 3 I want to load:
[appdomain]::CurrentDomain.SetData("APP_CONFIG_FILE", $configpath) Add-Type -AssemblyName System.Configuration
See this post to ensure the configuration 2 file specified is applied to the running 1 context.
I'm guessing that the settings would have 7 to be in powershell.exe.config in the powershell 6 directory, but that seems to be a bad way 5 of doing things.
You can use ConfigurationManager.OpenMappedExeConfiguration 4 to open a configuration file based on the 3 executing DLL name, rather than the application 2 exe, but this would obviously require changes 1 to the DLLs.
Attempting a new answer to an old question.
I think the modern answer would be: don't 28 do that. PowerShell is a shell. The normal 27 way of passing information between parts 26 of the shell are shell variables. For powershell 25 that would look like:
$global:MyComponent_MySetting = '12' # i.e. $PSDefaultParameterValues $ErrorActionPreference
If settings is expected 24 to be inherited across processes boundaries 23 the convention is to use environment variables. I 22 extend this to settings that cross C# / PowerShell 21 boundary. A couple of examples:
If you think 20 this is an anti-pattern for .NET you might 19 want to reconsider. This is the norm for 18 PAAS hosted apps, and is going to be the 17 new default for ASP.NET running on server-optimized 16 CLR (ASP.NET v5).
Note: at time of 15 writing I'm linking to
I've revisited this 14 question a few times, including asking it 13 myself. I wanted to put a stake in the 12 ground to say PowerShell stuff doesn't work 11 well with
<appSettings>. IMO it is much better to embrace 10 the shell aspect of PS over the .NET aspect 9 in this regards.
If you need complex configuration 8 take a JSON string. POSH v3+ has ConvertFrom-JSON built-in. If 7 everything in your process uses the same 6 complex configuration put it in a .json 5 file and point to that file from an environment 4 variable.
If a single file doesn't suffice 3 there are well established solutions like 2 the
PATH pattern, GIT .gitignore resolution, or ASP.NET web.config resolution 1 (which I won't repeat here).
More Related questions