Dependency Hell on .NET (C#) Application Plugin

Question

I am currently working on a plugin for a 3rd party WindowsForms application, where it will coexist amongst other plugins. Note that I have no control over the source or the files used by the base application (being it dll files, configuration files, etc.) nor over the other plugins that may be loaded at runtime.

Let us imagine that one of the other plugins, when loaded before mine, loads a dependency on version 1.0 of the library A (“A.dll”). If my plugin tries to load version 2.0 of the library A (also named “A.dll”), I am promptly greeted by the classic “System.IO.FileLoadException”.

After diving into the subject of dependency hell, I was presented with a few options (like here or here ). However all these options seem to focus on standalone applications, over which the developer has generally full control, that require two versions of the same library to be loaded (maybe for legacy support or any other strange reason). These solutions do not seem to be applicable on my case because of the plugin environment. Also, they often require:

• The insertion of an assembly in the GAC, which AFAIK will require administrative right on the final user's machine, which I do not have;
• Control over the base application's configuration file (*.exe.config), which I do not have.

Can anyone help me figure out a way to use a newer version of a library which is also used, as an older version, by another plugin, keeping in mind the constraints I've described ?

Answer 1

If you provide library A.dll version 2.0 yourself, you could rename it to A.2.0.dll and reference that.

Answer 2

You can handle the event AppDomain.AssemblyResolve to control which assembly is used depending on which assembly is trying to load it. Seems like a hack to me, but there probably is no clean way to solve this.