By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
435,089 Members | 2,301 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 435,089 IT Pros & Developers. It's quick & easy.

Dynamically Loaded Assemblies and Custom ConfigurationSection Handlers

P: n/a
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.Reflection.Assembly.LoadFile(pathToAssembly ).

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.LoadFile(pathToAssembly).

So far so good.

Here's where the problem happens:

While X, Y, and Z can read App.config - no problem - the custom
ConfigurationSection 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 ConfigurationSection
handler classes are attempted to be instantiated:
"An error occurred creating the configuration section handler for
NameOfCustomConfigurationSectionHandler: Could not load file or assembly
'MyCompany.AssemblyX' 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.MyNamespace.XSettings' to type
'MyCompany.MyNamespace.XSettings'."

"XSettings" is the name of my custom ConfigurationSection 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.ClassName, MyCompany.AssemblyX" />
..
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 <probingelement into App.config to tell
the CLR where to look if it could not find the assemblies in or under \bin:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;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!
Aug 22 '07 #1
Share this Question
Share on Google+
2 Replies


P: n/a
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.Reflection.Assembly.LoadFile(pathToAssembly ).

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.LoadFile(pathToAssembly).

So far so good.

Here's where the problem happens:

While X, Y, and Z can read App.config - no problem - the custom
ConfigurationSection 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 ConfigurationSection
handler classes are attempted to be instantiated:
"An error occurred creating the configuration section handler for
NameOfCustomConfigurationSectionHandler: Could not load file or assembly
'MyCompany.AssemblyX' 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.MyNamespace.XSettings' to type
'MyCompany.MyNamespace.XSettings'."

"XSettings" is the name of my custom ConfigurationSection 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.ClassName, MyCompany.AssemblyX" />
..
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 <probingelement into App.config to tell
the CLR where to look if it could not find the assemblies in or under \bin:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath="bin;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!
Aug 22 '07 #2

P: n/a
<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
Aug 22 '07 #3

This discussion thread is closed

Replies have been disabled for this discussion.