Dynamically Loaded Assemblies and Custom ConfigurationSe ction Handlers

[Smithers]

I have a Windows Forms application that implements a plug-in architecture
whereby required assemblies are identified and loaded dynamically.

Here are the relevant classes:

A = application = Windows Forms class

B = a singleton hosted within A. B is responsible for dynamically loading
classes X, Y, and Z.

X, Y, and Z = "worker bee" classes that do all of the grunt work of this
application. Each of these classes exists in its own assembly. B loads their
containing assemblies dynamically via reflection:
System.Reflecti on.Assembly.Loa dFile(pathToAss embly).

Being that X, Y, and Z are contained within their respective class
libraries, they cannot have their own .config files. I decided it was okay,
for this particular application, for the App.config file (of A, the
application class) to have custom configuration sections for each of the X,
Y, and Z classes. So X, Y, and Z, if/when loaded, need to read their
respective custom configuration sections from App.config.

Now, to get into the problem area:
I am dynamically loading the assemblies containing X, Y, and Z from
C:\SomeFolder --- and NOT from \bin or a subfolder under \bin

The loading of the assemblies happens just fine, as I am able to specify the
full path to the assemblies via Assembly.LoadFi le(pathToAssemb ly).

So far so good.

Here's where the problem happens:

While X, Y, and Z can read App.config - no problem - the custom
ConfigurationSe ction handler classes, which are also compiled into the
assemblies containing classes X, Y, and Z are INCORRECTLY assumed by the CLR
to exist in assemblies located in or under project A's \bin. I have verified
this through my testing:

Test 1:
If I ensure that the assemblies for X, Y, and Z do NOT exist in project A's
\bin, then I get this exception message when the custom ConfigurationSe ction
handler classes are attempted to be instantiated:
"An error occurred creating the configuration section handler for
NameOfCustomCon figurationSecti onHandler: Could not load file or assembly
'MyCompany.Asse mblyX' or one of its dependencies. The system cannot find the
file specified."

Test 2:
I then place a copy of the assembly containing X, Y, or Z into \bin\Debug.
Note that at this point TWO copies of, assembly X (for example), are in
play - one in C:\SomeFolder, and another in project A's \bin\Debug. Here's
the ensuing exception message:
"Unable to cast object of type 'MyCompany.MyNa mespace.XSettin gs' to type
'MyCompany.MyNa mespace.XSettin gs'."

"XSettings" is the name of my custom ConfigurationSe ction class (real names
changed to protect the innocent).
Notice that this message is telling us that it cannot cast to and from the
EXACT SAME type. This suggests to me that the CLR believes these are
different types [even though the qualified names are identical] BECAUSE they
are loaded from different assemblies - the first being the copy of the
assembly loaded via reflection from C:\SomeFolder and the other assembly
loaded by the .NET Configuration system from project A's \bin\Debug folder.

Attempted Resolution:
In trying to resolve this I started with a look at how the custom
configuration section handler is/can be defined in App.config:
<configSections >
<section name="MySection "
type="MyCompany .MyNamespace.Cl assName, MyCompany.Assem blyX" />
..
What's going on here is the type attribute lets us specify the qualified
class name, a comma, and finally the name of the assembly in which the class
can be found (less the .dll extension of course).

In reading MSDN and points beyond, it appears that we cannot specify a path
to the assembly file here - only the assembly name. The CLR apparently then
attempts to locate the assembly in or under \bin

I then attempted to introduce the <probingeleme nt into App.config to tell
the CLR where to look if it could not find the assemblies in or under \bin:
<runtime>
<assemblyBindin g xmlns="urn:sche mas-microsoft-com:asm.v1">
<probing privatePath="bi n;c:\SomeFolder "/>
</assemblyBinding >
</runtime>

NO dice with that per my testing, plus the docs say that <probingcan ONLY
be used to specify folders under \bin

So I'm fresh out of ideas on how to resolve this. I would appreciate
suggestions for how to make this work. Is there any way to tell the CLR to
load custom configuration section handlers from assemblies that exist
somewhere other than in or under \bin ??? That would be great. If not, I'd
appreciate suggestions for making this work that don't entail me introducing
a bunch of dependencies or breaking out the custom configuration section
handlers into their own\separate assemblies; or otherwise breaking my slick
plug-in architecture. It's taken a bunch of work to get X, Y, and Z to
participate in the application with A knowing absolutely nothing and B
knowing practically nothing about them (and vice versa); I'd like to keep it
like that if possible.

FWIW: This whole thing has been developed from scratch using Visual Studio
2008 Beta 2 (.NET 3.5). and no problems with Beta 2 - totally stable for me
with full-time development since a day or two after it was released.

Thanks!

[=?Utf-8?B?WWFyb24gS2Fybmk=?=]

Can you pls ask the question more briefly?
--
Sincerely
Yaron Karni
http://dotnetbible.blogspot.com/
"Smithers" wrote:

I have a Windows Forms application that implements a plug-in architecture
whereby required assemblies are identified and loaded dynamically.

Here are the relevant classes:

A = application = Windows Forms class

B = a singleton hosted within A. B is responsible for dynamically loading
classes X, Y, and Z.

X, Y, and Z = "worker bee" classes that do all of the grunt work of this
application. Each of these classes exists in its own assembly. B loads their
containing assemblies dynamically via reflection:
System.Reflecti on.Assembly.Loa dFile(pathToAss embly).

Being that X, Y, and Z are contained within their respective class
libraries, they cannot have their own .config files. I decided it was okay,
for this particular application, for the App.config file (of A, the
application class) to have custom configuration sections for each of the X,
Y, and Z classes. So X, Y, and Z, if/when loaded, need to read their
respective custom configuration sections from App.config.

Now, to get into the problem area:
I am dynamically loading the assemblies containing X, Y, and Z from
C:\SomeFolder --- and NOT from \bin or a subfolder under \bin

The loading of the assemblies happens just fine, as I am able to specify the
full path to the assemblies via Assembly.LoadFi le(pathToAssemb ly).

So far so good.

Here's where the problem happens:

While X, Y, and Z can read App.config - no problem - the custom
ConfigurationSe ction handler classes, which are also compiled into the
assemblies containing classes X, Y, and Z are INCORRECTLY assumed by the CLR
to exist in assemblies located in or under project A's \bin. I have verified
this through my testing:

Test 1:
If I ensure that the assemblies for X, Y, and Z do NOT exist in project A's
\bin, then I get this exception message when the custom ConfigurationSe ction
handler classes are attempted to be instantiated:
"An error occurred creating the configuration section handler for
NameOfCustomCon figurationSecti onHandler: Could not load file or assembly
'MyCompany.Asse mblyX' or one of its dependencies. The system cannot find the
file specified."

Test 2:
I then place a copy of the assembly containing X, Y, or Z into \bin\Debug.
Note that at this point TWO copies of, assembly X (for example), are in
play - one in C:\SomeFolder, and another in project A's \bin\Debug. Here's
the ensuing exception message:
"Unable to cast object of type 'MyCompany.MyNa mespace.XSettin gs' to type
'MyCompany.MyNa mespace.XSettin gs'."

"XSettings" is the name of my custom ConfigurationSe ction class (real names
changed to protect the innocent).
Notice that this message is telling us that it cannot cast to and from the
EXACT SAME type. This suggests to me that the CLR believes these are
different types [even though the qualified names are identical] BECAUSE they
are loaded from different assemblies - the first being the copy of the
assembly loaded via reflection from C:\SomeFolder and the other assembly
loaded by the .NET Configuration system from project A's \bin\Debug folder.

Attempted Resolution:
In trying to resolve this I started with a look at how the custom
configuration section handler is/can be defined in App.config:
<configSections >
<section name="MySection "
type="MyCompany .MyNamespace.Cl assName, MyCompany.Assem blyX" />
..
What's going on here is the type attribute lets us specify the qualified
class name, a comma, and finally the name of the assembly in which the class
can be found (less the .dll extension of course).

In reading MSDN and points beyond, it appears that we cannot specify a path
to the assembly file here - only the assembly name. The CLR apparently then
attempts to locate the assembly in or under \bin

I then attempted to introduce the <probingeleme nt into App.config to tell
the CLR where to look if it could not find the assemblies in or under \bin:
<runtime>
<assemblyBindin g xmlns="urn:sche mas-microsoft-com:asm.v1">
<probing privatePath="bi n;c:\SomeFolder "/>
</assemblyBinding >
</runtime>

NO dice with that per my testing, plus the docs say that <probingcan ONLY
be used to specify folders under \bin

So I'm fresh out of ideas on how to resolve this. I would appreciate
suggestions for how to make this work. Is there any way to tell the CLR to
load custom configuration section handlers from assemblies that exist
somewhere other than in or under \bin ??? That would be great. If not, I'd
appreciate suggestions for making this work that don't entail me introducing
a bunch of dependencies or breaking out the custom configuration section
handlers into their own\separate assemblies; or otherwise breaking my slick
plug-in architecture. It's taken a bunch of work to get X, Y, and Z to
participate in the application with A knowing absolutely nothing and B
knowing practically nothing about them (and vice versa); I'd like to keep it
like that if possible.

FWIW: This whole thing has been developed from scratch using Visual Studio
2008 Beta 2 (.NET 3.5). and no problems with Beta 2 - totally stable for me
with full-time development since a day or two after it was released.

Thanks!

[Smithers]

<snip>

Can you pls ask the question more briefly?

Sure.

Is there any way to tell the CLR to load custom configuration section
handlers from assemblies that exist somewhere other than in or under \bin
???

If the answer to the above question is "no" then...

I'd appreciate suggestions for making this work that don't entail me
introducing a bunch of dependencies or breaking out the custom configuration
section handlers into their own\separate assemblies; or otherwise breaking
my slick plug-in architecture (described in the OP).

Thanks

-S