Methods for categorizing 'plugin' DLLs

In my team, we are creating a .NET (WinForms) application that loads additional assemblies (DLLs) as pluggable components.

These actions needed to be classified into product categories, in order to be presented in the GUI in an organized way.

We've just started to implement this feature, so for starters, we keep a master .xml file that maps different assmeblies to categories.

This process is brittle and prone to many errors, and the final version of this feature should automatically create this mapping (somehow).

What we're looking for is some method to map the different DLLs now (and in the future) and keep all of this in sync.

Some suggestions we've had are:

1. Attributes - mark each assembly with some attribute, and run some custom tool 开发者_高级运维during build to produce some sort of mapping file, according to these attributes.

   This process will work, however this means static compilation of category name into the assembly itself, making it impossible to dynamically update on a client machine after installed.

2. Configuration file - Add a configuration file for the assembly (a practice this is rarely used i believe) and contain the needed information there in some form.

These are mainly the 2 options i have considered, one is static and the other dynamic (updateable after the app has been deployed).

Although we don't foresee any changes, requiring this mapping to be dynamic, i somehow feel that statically compiling this as an attribute is wrong.

Are there any other good options for meeting such a requirement? Also, are there any other pros/cons i haven't considered with the presented solutions ?

The first questions you should ask here is:

• who is the one who must be able to change the assembly<->category mapping?
• can every of your plugin assemblies be associated to an arbitrary category, or does that make no sense / may be a cause of errors?
• is it sufficient when a category change takes place during the install of an update?

Metadata to be build into the assemblies is the right thing, if each assembly can only belong to a defined category (or a defined list of categories) at one point in time, and it may be result in a runtime error if someone changes the category in a wrong way. Updating the category mapping later is not impossible, it is possible whenever you install a new release of your components.

Putting the mapping into separate configuration file or XML file is the right option if someone else should be able to change the actual mapping, without having to install a new release of your software. This may result in the need of having a user-friendly dialog to change the mapping in a not-so-error-prone way.