Load dynamically assembly and app.config

  • Thread starter Thread starter Sebastien Lange
  • Start date Start date
S

Sebastien Lange

Hi,

My application must load dynamically some assemblies (plugins).
Theses plugins use a third party assembly.
I'm using Assembly.Load to load my plugin and everything's working fine.

If the third party software is recompiled (no break, just bug correction),
normally I should recompile the plugins. But I don't want.
So I created a config file (myApp.exe.config) to redirect to the correct
third party dll. (the config file is ok, it has been tested by another apps)

Now, I installed a new version of the third party, and tried again my app.
Assembly.Load throws an exception (FileLoadException) because it can't find
the correct dll (the one that was referenced by the plugin) and does not
seems to use the config file, no trace in the log.

How can I force it to look in the config file when loading dynamically
assemblies?
I know I can by creating a second AppDomain, but I'd like to find a easier
solution.

Sebastien
 
Grabiele,

Thank you for the interesting article.
However, I don't think it answers my question. Based on the article, imagine
PluginProject1 references a third party dll. If you get a new version of the
third party dll, and you don't recompile your plugin, the code will break!
Even if you create a config file (ExtensibleApp.exe.config) that asks to use
the new version of the third party dll.
So my question is why isn't the config file read when calling
Assembly.LoadFrom?

Sebastien
 
Sebastien,

I'm not an expert of configuration files, but could you post it so everybody
can take a look at it?

Gabriele
 
Hello Sebastien,

Thanks for your post. As I understand, you want to dymanically load DLL
settings in the app.config, and then call Assembly.Load to load the
corresponding DLL. Now the problem you are facing is how to dynamically
read app.config. Please correct me if there is any misunderstand. Now I'd
like to share the following information with you:

The AppSettingsReader class reads the application settings when the default
AppDomain is loaded, and then those settings are cached for the lifetime of
the AppDomain. As you know, creating a second AppDomain is one of the
workarounds.

If you do not want to create an AppDomain, I strongly recommend you create
a custom Application Configuration class which loads the configuration
dynamically. You might consider also using Mike Woodring's nice little
extension class:

Arbitrary Configuration File Parser
http://www.develop.com/technology/resourcedetail.aspx?id=a69c6aa4-728c-4edb-
b221-d52ecc9b3c53

In addition, I believe the following MSDN article is helpful:

Persisting Application Settings in the .NET Framework
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/ht
ml/persistappsettnet.asp

Please feel free to let me know if you have any problems or concerns.

Have a nice da!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.
 
Arg, I'm so stupid... I found the bug while trying to reproduce in a small
sample.
The plugin was compiled with version 2.0.0.1 of the third party. Now, I have
version 2.0.0.5.
My config file contained:
<bindingRedirect oldVersion="0.0.0.0-1.65535.65535.65535"
newVersion="2.0.0.5"/>
It's better with this one:
<bindingRedirect oldVersion="0.0.0.0-2.65535.65535.65535"
newVersion="2.0.0.5"/>

Thanks for your answers.
Sebastien
 
Back
Top