Separate class-library initialization for each client assembly

Question

I'm writing a set of plugins for a third-party application which are implemented as .NET libraries and are loaded on application start, so they are all in the same application domain. One of the libraries is a collection of utility classes and extension methods that are used by others (including plugins written by other people, so this is basically a meta-library).

The problem is : inside the utility library there is an initialization code that allows to set up things like plugin title and such; which are, obviously, should be set per-client, ie per library in that case. This, of course, cannot be achieved using a static configuration class, as there would only be the single instance of it within the domain.

I'm also not allowed to load this library dynamically inside other plugins into a separate domain; and that will be a waste of memory, which is a concern.

The questions are :

1. Is it even possible/reasonable to implement such per-client runtime configuration for other libraries?
2. If it is, what approach would you recommend?

Answer 1

I am not sure I understand the question correctly, but you seem to be suggesting that there is an app which loads plugin-dlls at startup. You (the app developer and potentially plugin developer) want to provide a static class which has utility functions, that the plugins can use, without having to "re-invent the wheel" for every plugin. Below is my assessment (based on the above understanding)

• Your utility class seems to store plugin specific data - so by definition it cannot be static
• Yes, you can potentially load a plugin specific configuration file (file name might have to follow a naming convention to be effortlessly loaded by a static function) and offer the utility services - but I would say that is a bad design
• I would rather provide a utility which does not store any plugin specific data, but simply provides services based on method arguments. If you see yourself passing the same parameters a lot of times to the utility, then you should encapsulate those parameters into its own class/struct (like PluginData?)

EDIT

Let me expand a bit on the 3rd approach specified above:

You can represent your plugin configuration using a class, something like below, or you can get fancier.

class PluginConfiguration {
    public string PluginName {get; private set;} // This represents a property that all plugins share i.e. well known properties

    // all the configurations "private" to the plugin can go here
    // You might want to use some XmlDocument or a different data structure for this purpose
    public Dictionary<string,string> ConfigItems {get; private set;}

    public PluginConfiguration(string configFile) {
        // Load the configuration from the config file
    }   
}

Now your utility library can pass arguments or return data of type PluginConfiguration and help you centralize all repeating code for plugins