|
Thank you for your help. CLR does not seem like an obvious name for Managed c++ though. Oh well.
|
|
|
|
|
It's called C++/CLR now, it has a new name because of the changes in 2.0. CLR stands for Common Language Runtime.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: It's called C++/CLR now, it has a new name because of the changes in 2.0. CLR stands for Common Language Runtime.
C++/CLI actually - Common Language Infrastructure
|
|
|
|
|
*sigh* I don't know where that stupid mistake came from.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: I don't know where that stupid mistake came from.
STL.NET was renamed to STL/CLR - maybe that stuck on your mind.
|
|
|
|
|
I set up a DLL to define a class library. At first I set up the DLL as a native Win32 build. The calling app, however, was a C++/CLI app. The code below works fine:
<br />
#ifdef EXPORTING <br />
#define MYAPI __declspec(dllexport) <br />
#else <br />
#define MYAPI __declspec(dllimport) <br />
#endif <br />
<br />
class MYAPI MyClass() <br />
{ <br />
public: <br />
MyClass(); <br />
int DoSomething(); <br />
} <br />
<br />
<br />
#include "MyDll.h" <br />
... <br />
MyClass *x = new MyClass(); <br />
System::Console::WriteLine(System::String::Format("You got {0}", x->DoSomething()); <br />
delete x; <br />
...<br />
Building the main app with a project reference to the MyDll.dll, everything is FINE. Works great!
Now, after a little while I decided that my native class wants to have invoke some managed code (like file I/O). To do this, of course, I now have to build the DLL with the /clr option. This, in turn, totally breaks my class calling code in the main app. Mind you, I have not even added any managed code to the class yet. Just adding the /clr option and rebuilding the project killed everything.
To be specific, I get linker error messages for every public class symbol in the class, saying that the symbol is not defined. Remember, the main app project was already set to reference the dll. But for the fun of it I tried removing the project reference and manually adding #using <mydll.dll>. This did not help.
What do I need to do to get rid of the linker errors? Why is everything fine when I build the DLL as a Win32 dll?
Thanks for your help.
|
|
|
|
|
Could you copy/paste the linker errors here?
|
|
|
|
|
I made my original post without the code in front of me, so I had the wrong class name. In the error messages below, CClass32 is the native class in the DLL I am calling (a.k.a. "MyClass" in the original post). The errors were generated building the calling app with a project refernce to the DLL built with the /clr switch. When the DLL is built with no CLR support, the calling app builds with no errors or warnings.
Also, sorry for the misinformation. I forgot I got out of console mode and tried plugging this into a windows form. In the form class, I declared a private variable "pc" as a pointer to CClass32. I put a call to pc->DoSomething() in the destructor because the whole project is just a learning test (so I was too lazy to set up a button click event in the form). That's why these error messages look like they do. I don't actually expect to execute the app. But I do need to understand this whole process and need this test to build before I embark on porting one of my very large c++ 6.0 projects into a semi-managed .NET application.
Having said that, here are the errors:
Error 1 error LNK2028: unresolved token (0A000017) "public: int __thiscall CClass32::DoSomething(void)" (?DoSomething@CClass32@@$$FQAEHXZ) referenced in function "private: __clrcall CLIGLTest2::Form1::~Form1(void)" (??1Form1@CLIGLTest2@@$$FA$AAM@XZ) CLIGLTest2.obj
Error 2 error LNK2019: unresolved external symbol "public: int __thiscall CClass32::DoSomething(void)" (?DoSomething@CClass32@@$$FQAEHXZ) referenced in function "private: __clrcall CLIGLTest2::Form1::~Form1(void)" (??1Form1@CLIGLTest2@@$$FA$AAM@XZ) CLIGLTest2.obj
Error 3 fatal error LNK1120: 2 unresolved externals C:\Files\VsNet 2005\CLIGLTest2\Debug\CLIGLTest2.exe 1
When I add in the form constructor the code pc = new CClass32(); the errors are doubled, producing similar messages saying that the symbol "public: __thiscall CClass32::CClass32(void)" is not defined. So it's like the DLL doesn't even exist as far as the calling app is concerned. But as I said, I used the IDE to point to the DLL where CClass32 is defined, so I know it's not a malformed #using directive or something.
-- modified at 22:38 Thursday 17th August, 2006
|
|
|
|
|
Looks to me that the class is not exported properly. Can you show how you've exported the class?
Never mind - you've shown that in the first post. But the errors you get are typical of an incorrect attempt at exporting a class.
It'd be best to create a fresh example DLL (compiled as /clr) that exports a native class. Then first use it from a native caller, then try from a mixed-mode caller. That'd help you identify what you did wrong in your first project.
|
|
|
|
|
OK. I Started a solution from scratch, but I am still faced with the same issues. I think I can simplify the question, though:
Simply put, how do I import a native class from a mixed-mode DLL into a mixed-mode app? I can import a managed class easily from a /clr DLL. I can import a native class from a Win32 DLL easily. But I can't import a native class from a /clr DLL.
Thanks.
|
|
|
|
|
Xpnctoc wrote: But I can't import a native class from a /clr DLL.
There are many details involved, are you following any article or something?
led mike
|
|
|
|
|
No, I'm not following an article. Can you point me to a good one?
All of the articles I've come across are for other types of operations, such as importing a class from a Win32 DLL where you don't have access to the DLL source, going through the headache of using dumpbin.exe to find the public symbols and then constructing wrapper classes and such. But this is overkill for me.
I just need to know why, when I have reference an assembly built with the /clr option, I can import managed classes but not native ones. I just haven't found an article that address that issue from that viewpoint.
|
|
|
|
|
Xpnctoc wrote: OK. I Started a solution from scratch, but I am still faced with the same issues. I think I can simplify the question, though:
Simply put, how do I import a native class from a mixed-mode DLL into a mixed-mode app? I can import a managed class easily from a /clr DLL. I can import a native class from a Win32 DLL easily. But I can't import a native class from a /clr DLL.
I created a test DLL and a test EXE. I export a class from the DLL and use that class in the EXE. Both DLL and EXE are compiled with /clr and it works as expected.
Perhaps you have forgotten to add the export lib to the EXE project?
You can use the following line directly in your cpp file :-
#pragma comment(lib, "Path to DLL/DllName.lib")
|
|
|
|
|
Adding the #pragma directive succeeded! Thank you.
As follow up, can you tell me why the .lib has to be added to a project for exporting unmanaged classes compiled with /clr, but not if the DLL was build without CLR support? Or why in a /clr build, the .lib is required for importing unmanaged classes but not for importing stand-alone, unmanaged functions (that were surrounded with the "#pragma unmanaged" directive)?
Also, then, does the #using<> directive only pertain to managed code? Earlier I had tried adding the code #using < CliLib.dll >, but that did not help. Only referring to the .lib file solved the problem.
Could you direct me to any useful articles related to all of this?
Thanks again.
|
|
|
|
|
Xpnctoc wrote: As follow up, can you tell me why the .lib has to be added to a project for exporting unmanaged classes compiled with /clr, but not if the DLL was build without CLR support? Or why in a /clr build, the .lib is required for importing unmanaged classes but not for importing stand-alone, unmanaged functions (that were surrounded with the "#pragma unmanaged" directive)?
The lib is needed in bith scenarios. It's just that, without the /clr the VS IDE automatically uses the lib (possibly because you have a project dependency set appropriately).
It should really do the same for /clr too - but it looks like the IDE team overlooked doing that. This'd be a minor-level bug I suppose.
Xpnctoc wrote: Also, then, does the #using<> directive only pertain to managed code? Earlier I had tried adding the code #using < CliLib.dll >, but that did not help. Only referring to the .lib file solved the problem.
#using is used to access a managed assembly (including a mixed-mode assembly). It imports the managed meta data that allows us to use those types in our calling app.
It has nothing to do with exported native types.
|
|
|
|
|
I get it now. I didn't even think of the project dependency settings, and you are absolutely right that I do have a dependency set. I'm so accustomed to the IDE taking care of the LIB links that I just never even thought of it.
Thank you so much for all of your help.
|
|
|
|
|
hey guys, just a very quick question. How od i bring up a msgbox with c++. cant seem to find anyhting on the site.
Thank you VERY much.
- Droz -
___ ___
/\/\ /\ | |
|
|
|
|
|
AfxMessageBox if you're using MFC, MessageBox if you're not.
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: AfxMessageBox if you're using MFC, MessageBox if you're not.
And MessageBox::Show if you are using WinForms.
|
|
|
|
|
Thank you for your time.
- Droz -
___ ___
/\/\ /\ | |
|
|
|
|
|
But who does such a thing ?
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
Christian Graus wrote: But who does such a thing ?
Come on, CG, you and I know that there are 100s of 1000s of C++ devs using WinForms with C++/CLI 
|
|
|
|
|
Yeah, probably. But only because they download Express, or perhaps they live in fairyland.... :P
Ooops - this was in the managed form. My bad...
-- modified at 18:15 Friday 18th August, 2006
Christian Graus - Microsoft MVP - C++
Metal Musings - Rex and my new metal blog
|
|
|
|
|
This is one of the weirdest things I've ever seen. And its been very tricky to nail down.
We instantiate a class (foo *somefoo = new foo() ) using 'new' and get a pointer to that class.
Later in code, witihin a function of another class, we 'new' a new piece of memory (char *buff = (char*) new char [buffSize]) VERY oddly, this 'new' is returning the address of "somefoo" we instantiated earlier and not a new piece of memory.
Any ideas why this is happening? Or how we can avoid this? Remarkably, its happening at the same point in code EVERY time, although we use new everywhere. This was a pain in the a#$ to find.
Help please!?!?!?!?!?
-C
|
|
|
|
|
The most obvious answer is that the particular instance of somefoo is being deleted and returning that address to the available heap prior to the char array being allocated.
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
