views:

43

answers:

2

When invoking

[System.Configuration.ConfigurationManager]::GetSection("MySection")

from within a PowerShell prompt, it throws an exception because the assembly containing the type represented by "MySection" in the app config is unable to be loaded. However, I have previously loaded the assembly containing that type, and I am even able to instantiate the type directly using 'new-object'.

How is the ConfigurationManager resolving types such that the assemblies already loaded into the PowerShell app domain are not visible to it?

A: 

How exactly did you load the assembly? Binding contexts matter:

http://blogs.msdn.com/b/suzcook/archive/2003/09/19/loadfile-vs-loadfrom.aspx

-Oisin

x0n
It was loaded using Assembly.LoadFrom. As to exactly how the assembly is loaded indirectly via GetSection I have no idea. But I think the MS documentation makes it clear that the assembly location matters in the case of app config files.
Dan
Yeah, the GetSection will probe for assemblies in the private path of the hosting process, i.e. powershell.exe. It might be easier to new up an appdomain and then marshal the string data back out of it. This is not too hard to write, even in powershell script.
x0n
A: 

Try changing the app_config_file location to a path to your own app config file that specifies a private probing path to the dir containing your DLL. See this SO post for more details. This works for connection string data but I'm not sure if it will work with a private probing path outside the app's base dir.

Keith Hill