LoadLibrary, a way to instantiate a class from external dll?

I开发者_JAVA百科 have written a dll in d-7. It functions correctly. It gets loaded when an application starts and unloaded when it exists.

Now, that dll must also work on the server side of that application, being loaded from the COM+ surrogate (dllhost.exe) as the server is based on com+ technology.

The problem is that one process may have only one handle for loaded library. I cannot have separate handles on each LoadLibrary call.

In com+, one dllhost.exe can serve many clients, which means that if I load an external library it gives the same instance for each clients calls.

So:

1) Is it possible to somehow workaround this problem?

2) Or Is it possible to directly create instance of the class which resides in this dll for each client call?

3) Or How to make a dll thread-safe by instantiating an internal class for each call.

Thanks for suggestions in advance!

Since a DLL uses the local memory of the thread/process that calls it, I'm not sure you're really going to have a "problem". You do not want to have the DLL maintain some global information because that will only lead to threading nightmares.

If you have a function within the DLL return an object reference (effectively a handle) you can also guarantee that each instance gets its own information to play with and not stomp on other processes or threads. Define the function to return your TWhatever object, have the DLL create it ( TWhatever.Create() ) and return it to the calling process. It would then be up to the calling process to free the object. If you need COM+ compatibility then it should be possible to use an interface reference (IWhatever) and return that from your function.

If each thread deals with its own object instance (or interface reference) then you could have the DLL serve as many threads and processes as you wish.

Your question is confusing to me so I'm not sure if I answered it correctly. :p