Problem with assemblies loaded via reflection

[Guest]

I am loading some dlls for my application using reflection. These dlls are
plugins as suggested in the MSDN article:

http://msdn.microsoft.com/msdnmag/issues/03/10/Plug-ins/

(although I came up with this idea myself before reading the article).
These plugins exist in a plugin directory and are loaded by my main
executable. The problem I am having is that some of my plugins share code
via another assembly (dll). If that dll resides in the plugin directory it
can not be loaded and I get an error message something like "the manifest for
XXX does not match the referenced assembly XXX". The simple solution is to
move these dlls into my main application directory, but this doesn't seem to
make sense as they are not part of my main application they only exist to
support the plugins. Is there a better solution? Some way to indicate that
the reference should search the plugins directory as well?

Thanks in advance,
Jon Walker

 

[richlm]

Would using the "System.AppDomain.AssemblyResolve" event help?
Not sure it is your solution but may be worth a try.

 

[Chris Dunaway]

I have been working on this problem as well. If you want it to search
your plugins folder, you can use the AppendPrivatePath method to cause
that to happen:

AppDomain.CurrentDomain.AppendPrivatePath(path)

After executing the line, the assembly prober will look in that path
for assemblies. The path must be relative to the base path of the
application.

 

[Guest]

The bad thing is that this method is deprecated in .Net 2.0
In .Net 2.0 you can't change the PrivateBinPath of the default AppDomain so
you
are ...

 

[loudenvier]

AppDomain.AppendPrivatePath has been deprecated in .Net 2.0. You can still use it tough. But it has been suggested that you use the property AppDomain.PrivateBinPath instead. I´ve setup a thread in MS forums at:

http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=767490&SiteID=1

There could be more good information in there.

Regards