title: Designing a contract for plugins
body: <p>I was thinking about designing a proper contract for future plugins creation for an application I'm currently working on. Basically the idea is to define an interface, but I want the application to be aware of plugins that currently presented to the system and to show the user a nice list of plugins with their names and a brief descriptions which ofcourse the developer of the plugin should provide, the user of the application shouldn't be able to alter this easily so an additional config file is not an option. I don't want to use the class name of filename of the assembly for this. Also I think that it should be accessable without instantiating the plugin, but maybe through reflection, something like: <code>assembly.GetType(type).GetProperty("Name").GetValue(null, null).ToString();</code>. Ofcourse I could provide some logic to check for existance something like <code>if(assembly.GetType(type).GetProperty("Name") != null)</code>, but this is not a good idea either, because if the property does not exist the end user won't have an idea of what that plugin does, not even what it's name is.
  Now, it should behave like a static property, but static is not overridable so it seems that I cannot declare it as a part of an interface nor in an abstract class. Maybe I'm on wrong way, and it only looks like a static property and I can achive this functionality through another approach. So the brief question might be <em>"How to enforce the third party developer to provide some meta information about his plugin"</em>. Please advise.</p>