Topi Mäenpää wrote:

...

So the problem is already ratched up to another level of complexity.

class X can be in a DLL. class Y can be in an application

everything is fine so far

class Z :: public class Y creates a problem in that class Y gets registered in the application even if its already in the DLL. This will require some thought to know what the correct way to handle this is.

I have a suggestion, please comment. The problem _could_ be in that guid_initializer isn't exported. If I register my base class in a DLL, the DLL interface does not expose the guid_initializer::instance I have created. Since my exe now doesn't know about it, it creates a new definition. The same applies to other DLLs. (This would also explain why the same code works on Linux: all symbols are automatically exported.) What if we exposed the guid_initializer struct to the DLL interface? Would it help? At least it shouldn't do any harm to export it from the exe.

That might explain the behavior. We'll look into it. I'm having problems making test which uses a dynamically loaded DLL that I can run under bjam. Robert Ramey