steve_hsk
asked on
C++ .NET using a managed class library
Hi guys ...
I have written a C++ managed class library DLL and a simple app to use this managed DLL. In order to use this class I have started as follows :
Assembly *asm = Assembly::LoadFrom("D:\Tes
Type *asmTypes[] = asm->GetTypes();
for (int i = 0; i <= asmTypes->Count - 1; i++)
{
if (asmTypes[i]->GetInterface
{
Object *TestObject = Activator::CreateInstance(
IRequiredInterface *reqInt = dynamic_cast<IRequiredInte
Note that IRequiredInterface was defined in a shared header file that both the DLL and the EXE share - Mistake 1 ...
Although the intellisence now gives me the methods in IRequiredInterface eg :
reqInt ->IRequiredMethod1();
The dynamic_cast operation fails at runtime and returns NULL.
I know that I can use late binding to export each of the methods 1 by 1 from the DLL :
MethodInfo *MyMethod1 = asmTypes[i]->GetMethod("IR
Object *tmpObj = MyMethod1->Invoke(TestObje
The problem I face here is the number of methods that are required, multiplied by a selection of different DLL's makes late binding an ugly solution.
My question : After retrieving a class from a managed DLL, is it possible to instantiate it and then make method calls from it, without late-binding, so using it is almost like using a normal (local) class ?
Any help here is greatly appreciated ...
¬STeve
I have written a C++ managed class library DLL and a simple app to use this managed DLL. In order to use this class I have started as follows :
Assembly *asm = Assembly::LoadFrom("D:\Tes
Type *asmTypes[] = asm->GetTypes();
for (int i = 0; i <= asmTypes->Count - 1; i++)
{
if (asmTypes[i]->GetInterface
{
Object *TestObject = Activator::CreateInstance(
IRequiredInterface *reqInt = dynamic_cast<IRequiredInte
Note that IRequiredInterface was defined in a shared header file that both the DLL and the EXE share - Mistake 1 ...
Although the intellisence now gives me the methods in IRequiredInterface eg :
reqInt ->IRequiredMethod1();
The dynamic_cast operation fails at runtime and returns NULL.
I know that I can use late binding to export each of the methods 1 by 1 from the DLL :
MethodInfo *MyMethod1 = asmTypes[i]->GetMethod("IR
Object *tmpObj = MyMethod1->Invoke(TestObje
The problem I face here is the number of methods that are required, multiplied by a selection of different DLL's makes late binding an ugly solution.
My question : After retrieving a class from a managed DLL, is it possible to instantiate it and then make method calls from it, without late-binding, so using it is almost like using a normal (local) class ?
Any help here is greatly appreciated ...
¬STeve
ASKER
Hi, thanks for the post ...
In my hast to get the question out and find an answer I have missed the fact that this code forms part of a module manager for a plugin architecture, and subsequently it is not possible to reference the plugin DLL from the module manager. It must be loaded at runtime, and the plugin(s) may potentially be selected by the user from a file browser dialog.
However, as this can be done at design time AND the framework gives the ability to load a class in at runtime : Activator::CreateInstance(
Apologies for any confusion,
¬STeve
In my hast to get the question out and find an answer I have missed the fact that this code forms part of a module manager for a plugin architecture, and subsequently it is not possible to reference the plugin DLL from the module manager. It must be loaded at runtime, and the plugin(s) may potentially be selected by the user from a file browser dialog.
However, as this can be done at design time AND the framework gives the ability to load a class in at runtime : Activator::CreateInstance(
Apologies for any confusion,
¬STeve
ASKER
Hi guys ...
I have managed to find the answer I was looking for in c# and used the same methods in C++ :
http://www.skeet.org.uk/csharp/plugin.html
The key problem was storing the interfaces in a shared header file. Although the source is the same the CLR recognises these interface objects in the EXE and the DLL as different binary objects, as they have been compiled as different times.
The solution, is to create a 2nd DLL and transfer the interfaces from the the shared header file, into this DLL. When this Interface DLL is used by the EXE and the PlugIn DLL, it is the same binary, the CLR recognises this, and the subsequent cast suceeds :
IRequiredInterface *reqInt = dynamic_cast<IRequiredInte
So before reqInt was returned NULL by this cast, now the cast is successful and not only will intellisense so the list of class methods, but the calls to these methods also suceed :
reqInt ->IRequiredMethod1();
This method will allow for more complex interfaces (not always a good thing from a design perspective, but sometimes necessary), and very little coding when compared to late binding methods.
If there are no objections, I shall post a refund request in community support ?
Best regards,
¬STeve
I have managed to find the answer I was looking for in c# and used the same methods in C++ :
http://www.skeet.org.uk/csharp/plugin.html
The key problem was storing the interfaces in a shared header file. Although the source is the same the CLR recognises these interface objects in the EXE and the DLL as different binary objects, as they have been compiled as different times.
The solution, is to create a 2nd DLL and transfer the interfaces from the the shared header file, into this DLL. When this Interface DLL is used by the EXE and the PlugIn DLL, it is the same binary, the CLR recognises this, and the subsequent cast suceeds :
IRequiredInterface *reqInt = dynamic_cast<IRequiredInte
So before reqInt was returned NULL by this cast, now the cast is successful and not only will intellisense so the list of class methods, but the calls to these methods also suceed :
reqInt ->IRequiredMethod1();
This method will allow for more complex interfaces (not always a good thing from a design perspective, but sometimes necessary), and very little coding when compared to late binding methods.
If there are no objections, I shall post a refund request in community support ?
Best regards,
¬STeve
No problem.
I discovered the same solution lat night by trial and error - no Internet in the hotel, though, so I couldn't post it. Isn't it nice that it's so well documented by Microsoft? I'll file this one away for future use as it's a bit unexpected coming from regular C++ development.
Good luck.
I discovered the same solution lat night by trial and error - no Internet in the hotel, though, so I couldn't post it. Isn't it nice that it's so well documented by Microsoft? I'll file this one away for future use as it's a bit unexpected coming from regular C++ development.
Good luck.
ASKER
Another documentation feux pas ... add it to the list of overlooked and poorly documented features :-)
Although class control is a logical step in the path of reflection, I am impressed with this solution. If and hopefully when I find the time, I feel a codeproject article coming on !
Thanks again for your efforts !
¬STeve
Although class control is a logical step in the path of reflection, I am impressed with this solution. If and hopefully when I find the time, I feel a codeproject article coming on !
Thanks again for your efforts !
¬STeve
ASKER CERTIFIED SOLUTION
membership
This solution is only available to members.
To access this solution, you must be a member of Experts Exchange.
DLLProj::ClassName *pC = new DLLProj::ClassName(...);
where DLLProj is the namespace from the dll and ClassName is a class you implemented in the dll. Then you will have intellisense and can use functions directly. The managed C++ dll can also be referenced and used from other .NET languages - use syntax appropriate for the language.