0

I'm using a 3rd party library in my project. My project also has a plugin system that allows users to create their own plugins that are loaded dynamically at runtime:

var plugin = Assembly.LoadFrom(pathToPluginDLL);
// later on, the constructor from the user plugin is loaded
pluginConstructor.Invoke();

I've got a scenario that one of these user plugins is referencing the same 3rd party library that my main project uses. That 3rd party library has a static object that needs to be unique for the main project and unique for the user plugin.

Here's a quick contrived code example of what happens:

// This is a class within a 3rd party DLL, referenced directly from the main project
public class SomeClassWithStaticObjects
     public static string staticString {get; set;}
}

// In the main project
SomeClassWithStaticObjects.staticString = "main project static string";

In one of the user plugins that references the same 3rd party DLL:

SomeClassWithStaticObjects.staticString = "plugin project static string";

The problem being that SomeClassWithStaticObjects.staticString is referencing the same static object between the main project and the plugin that's loaded using reflection. Is there a way that I can "isolate" the user plugin in it's own memory space so that it has it's own unique version of the static class?

bugfixr
  • 7,997
  • 18
  • 91
  • 144

1 Answers1

3

You can have have two separate instances of a static class if they are in separate application domains.

There's a lot of possibly outdated documentation on this. Here's something a little more recent.

This answer might also help.

I'm really curious what this library is that creates this problem. It just seems off.

Scott Hannen
  • 27,588
  • 3
  • 45
  • 62
  • "The only" is obviously wrong because you can have as many strongly typed versions as you want as long as you manage to load them from different places (i.e. loading from GAC), otherwise indeed separate appdomains is good solution. – Alexei Levenkov Jun 30 '17 at 02:59