VS 2010 Dll That Is Implemented By A Class With A Default Constructor

I have a base class which must be overriden. This base class sits in one dll shared by all. The derived classes will each be in their own dll such that the addition of a new derived class can be done by distributing a new dll. The set of dlls, and therefore the set of derived classes, will be discovered by the main program on startup. That's all pretty straightforward. The problem is that the main program needs to be able to query a database to figure out which type of derived class it needs, then create a class of that type. Naturally, it can't know which types will be available ahead of time because even I don't know that. The program has to be dynamically extensible.The obvious way to do this is to have an interface in the dll that is implemented by a class with a default constructor. The sole purpose of that class would be to return an object of the type (one of the derived types) defined in that dll. The derived types can't really be this class, because they can't have a default constructor since the base class doesn't have a default constructor, and the derived class can't make up the arguments that the base class constructor needs.

So basically, each dll that houses a derived class would also house a simple class that implemented an interface for the sole purpose of creating that particular derived class. The main program would examine the dll to find a class that implemented the interface, and once it found one, it could ask it what type of class it created, or it could ask it to create an instance of that class. It seems like there ought to be an easier way to dynamically add new classes to the project. It seems like the derived class ought to be able to tell the main project what type it was. This could be done, except that the derived class would have to exist before any of its methods could be called unless the methods were shared. Since you can't have a shared method in an interface, the interface itself would make no sense at that point, in which case I would need to discover whether the class in the dll derived from the base class in the second dll, just to figure out whether or not I wanted to create it. That's getting convoluted by now, so I guess I'll leave it there. The basic point is that the base class is known to the main program from a common dll. The number and types of derived classes can't be known at this time, so the program has to be able to discover them dynamically. Each derived class will sit in its own dll (or there could be more than one in a dll), and has to be discovered, and instances created, as needed, by the main program.