Problem creating a DLL due to conflicts using MFC, Visual C++ 2008

Hello,

I've already spent some hours trying to find a solution, but I couldn't, since I am not familiar with these settings, so I look for your help. This is the problem in detail:

I have a VC++ project to create a DLL that will be used as a Plug-in in an external programm. This DLL uses some MFC functions. The initial configuration of the project was:

-Use of MFC: Use MFC in a Static Library

-Common Language Runtime support: No Common Language Runtime support

-Runtime Library: Multi-threaded Debug (/MTd)

This configuration worked fine, there were no compilation errors and the resulting DLL worked correctly.

The problem came when it was necessary to add to the DLL some functions of .NET, using the namespace System and similar. To do that, I had to change the Common Language Runtime support, to Common Language Runtime Support (/clr). Then, when I tried to compile, I got this message:

'/MTd' and '/clr' command-line options are incompatible

So I changed the Runtime Library to Multi-threaded Debug DLL (/MDd). Then I got this error message:

Building MFC application with /MD[d] (CRT dll version) requires MFC shared dll version

So I also changed the Use of MFC to Use MFC in a Shared DLL.

After this, the compilation was correct. Then logically the size of the generated DLL is smaller, but this new DLL does not work correctly, the external programm in which this DLL is used crashes.

I don't know what to do to fix the problem. Maybe I need to add some other DLLs or files to the directory where the DLL is located, where the external programm uses it. But I would prefer to include a single DLL file, but this seems to be incompatible with the use of .NET functionalities.

Sorry for the long explanation. I would be very thankful is somedoby could help me.

Thank you in advanced.

Dario

1. Define "crashes".
2. Did you debug your dll?
3. Note that only Release version of your dll may be deployed.

Quote:

---

Originally Posted by VictorN

1. Define "crashes".
2. Did you debug your dll?
3. Note that only Release version of your dll may be deployed.

---

Hello,

thank you for your answer. The DLL, compiled with the initial configuration (without Multi-threaded Debug (/MTd) and without clr) works fine.

The external programm crashes when it uses the DLL. The error that I get when I debug this with Visual C++ is the next:

An unhandled exception of type 'System.NullReferenceException' occurred in PI_Parameter.dll
Additional information: Object reference not set to an instance of an object.

And it crashes in the third line of the code of the function of the DLL, that is the next:

extern "C" void WINAPI DllInfo(HWND hwndMain)
//
// entry point for display of about info dialog box for plug-in DLL
//
{
// connect to main app window
CWnd* pWnd = new CWnd;
pWnd->Attach(hwndMain);

AfxGetApp()->m_pMainWnd = pWnd; ->Here crashes

I didn't changed any code for the moment, I just changed the configuration as I described. The size of the DLL with the initial configuration is 1795 Kb, and with the new is 218 Kb.

In summary, the configuration now is:

-Use of MFC: Use MFC in a Static Library
-Common Language Runtime support: Common Language Runtime Support (/clr)
-Runtime Library: Multi-threaded Debug DLL (/MDd)
-I added also _AFXDLL to the preprocessor

I have tried in both debug and release modes, with the same results.

Thank you for your help,

Dario

Quote:

---

Originally Posted by dariotojeiro

And it crashes in the third line of the code of the function of the DLL, that is the next:

Code:

---

extern "C" void WINAPI DllInfo(HWND hwndMain)
//
// entry point for display of about info dialog box for plug-in DLL
//
{
        // connect to main app window
        CWnd* pWnd = new CWnd;
        pWnd->Attach(hwndMain);

        AfxGetApp()->m_pMainWnd = pWnd;[/I]  ->Here crashes

---

---

What does AfxGetApp() return?

Quote:

---

Originally Posted by dariotojeiro

The problem came when it was necessary to add to the DLL some functions of .NET, using the namespace System and similar. To do that, I had to change the Common Language Runtime support, to Common Language Runtime Support (/clr).

---

And once you did that, you are taken into a different world.

You are mixing in a different technology than what is expected in a normal DLL. Since you now added .NET code to your DLL, you basically are out of the realm of what this forum can help you with. Instead you now enter the world of .NET and Managed code, and there is a separate forum dedicated to that type of coding (the Managed Code) forum.

Regards,

Paul McKenzie

I didn't programm the DLL actually, but it seems to be a function of MFC:

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

Quote:

---

Originally Posted by Paul McKenzie

And once you did that, you are taken into a different world.

You are mixing in a different technology than what is expected in a normal DLL. Since you now added .NET code to your DLL, you basically are out of the realm of what this forum can help you with. Instead you now enter the world of .NET and Managed code, and there is a separate forum dedicated to that type of coding (the Managed Code) forum.

Regards,

Paul McKenzie

---

Thank you for your answer. Should I post then my doubt in the corresponding Forum? or is it impossible to mixture the 2 technologies?

Quote:

---

Originally Posted by dariotojeiro

I didn't programm the DLL actually, but it seems to be a function of MFC:

http://msdn.microsoft.com/en-us/libr...=vs.80%29.aspx

---

Yes, we do know that AfxGetApp() is "a function of MFC".
And what does it return inside your dll

Code:

---

extern "C" void WINAPI DllInfo(HWND hwndMain)

---

funcrion?

Quote:

---

Originally Posted by dariotojeiro

The problem came when it was necessary to add to the DLL some functions of .NET, using the namespace System and similar. To do that, I had to change the Common Language Runtime support, to Common Language Runtime Support (/clr).

---

How are you communicating between the application and your DLL? Do you only use a C API or do you export classes or use non-POD types in exported functions as well?

Quote:

---

Originally Posted by VictorN

Yes, we do know that AfxGetApp() is "a function of MFC".
And what does it return inside your dll

Code:

---

extern "C" void WINAPI DllInfo(HWND hwndMain)

---

funcrion?

---

Using the DLL that works correctly, it returns a pointer not NULL, but I don't know what this pointer refers. Actually, if I delete that line of code, the DLL works the same. The complete function is the next:

Code:

---

extern "C" void WINAPI DllInfo(HWND hwndMain)
//
// entry point for display of about info dialog box for plug-in DLL
//
{
        // connect to main app window
        CWnd* pWnd = new CWnd;
        pWnd->Attach(hwndMain);

        AfxGetApp()->m_pMainWnd = pWnd;
 

        // execute dialog
        CInfoDlg* pDlg = new CInfoDlg(pWnd);

        pDlg->DoModal();
        delete pDlg;

        pWnd->Detach();
        delete pWnd;

        return;
}

---

Anyway, without that line of code, the external programm also crashes. Although this time it is not a file of the DLL, it's a file of the external application called afxwin1.inl

Quote:

---

How are you communicating between the application and your DLL? Do you only use a C API or do you export classes or use non-POD types in exported functions as well?

---

I don't really know, since the application and the DLL were given to me in order to include (or try to...) some functionalities. Sorry that I cannot give you more information about this.

Quote:

---

Originally Posted by dariotojeiro

I don't really know, since the application and the DLL were given to me in order to include (or try to...) some functionalities. Sorry that I cannot give you more information about this.

---

Well, I'm sorry to say this, but if you don't know how the code works, you won't be able to change it. So, my advice would be to start studying how the code works.

Quote:

---

Originally Posted by dariotojeiro

Using the DLL that works correctly, it returns a pointer not NULL, but I don't know what this pointer refers.

---

I agree with D_Drmmr that you need to know exactly what you're doing before changing anything. Just the fact that you attempted to add .NET functions to a non-NET DLL started you out on the road to problems.

Windows/MFC/C++ programming is technical enough. You can't just go about things thinking that you can apply duct tape here and there and things will work.

The AfxGetApp() is one of the core MFC functions when it comes to managing a main window and initialization. You must know what it does if you program an MFC application. If you don't know how to use it, what it does, and any nuances that come with using such a function, then you're off on the wrong foot.

Regards,

Paul McKenzie