MSDN help on the topic could look a bit misleading.
Did you see this code sample:
http://www.thegecko.org/[^]?
[EDIT 1]
The problem is that the crash happens
before the handler of
AppDomain.CurrentDomain.AssemblyResolve
even is added to the event invocation list, before start of main.
So, it looks like this schema does not really work. (Maybe it need some more research.)
I would consider well-working alternative: using dynamically loaded assemblies.
Please see this:
Create WPF Application that uses Reloadable Plugins...[
^],
AppDomain refuses to load an assembly[
^].
Some designs I described in the above Solutions are overly difficult or problematic. In your case you need the simplest of the cases: non-reloadable (loaded-once) plug-in, which is really simple.
You can use a simple extra trick: my schema suggests you create a plug-in interface, but you don't want to add any shared libraries (you want all the libraries in one place, found by application). You can put this interface in the application: an application assembly (in EXE file) can be loaded exactly as a library, referenced by other assembly.
[EDIT 2]
It was interesting exercise. :-)
As we face such difficulties, let's do something more realistic.
Don't you think you over-estimated the hassle of application
config
? Did you use
probing
.
option? Look at this sample file:
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<probing privatePath=".\Mediasoft\Assembly"/>
</assemblyBinding>
</runtime>
</configuration>
It means that I place this file with my application in some directory, and all my library assemblies are put in its sub-directory "
.\Mediasoft\Assembly
", they are shared by some set of my applications and are automatically resolved under this sub-directory. It does not have to be a sub-directory, can be somewhere on top of directory structure.
—SA