Problem creating a DLL due to conflicts between MFC and .NET, 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.

I opened a thread about this in the wrong forum. The link is this:http://forums.codeguru.com/showthrea...=1#post2103441

Thank you in advanced.

Dario

Combining native and .NET code in a single project can be quite tricky, even without involving any (3rd-party, I assume) host app. So the first question to ask may be: Is there really no option to achieve what you want without .NET? Which features of the .NET framework are you using?

OTOH, I already managed myself to get a .NET DLL (written in C++/CLI) which exposes .NET ojects over COM to nicely work together with Excel 2003 (non-.NET), so things like that are possible. That DLL doesn't use MFC, though.

One diagnostic step you can take is writing two minimal host apps using your DLL, one MFC-based and one .NET-based, both not touching the respective other technology. If the DLL works with both of them, I think we can half-way certainly rule out that it's an interference between your DLL and one of the frameworks (or an isolated bug within the DLL itself), but instead with the host app. BTW, is the host app .NET? It should be possible to tell that from the DLLs the running app loads: If there's a clr.dll among them, it's .NET (at least partially) or it's already using external .NET-based components.

Quote:

---

Originally Posted by dariotojeiro (in the other thread)

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.

[...]

Code:

---

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

---

---

Weird IMO: That's clearly a .NET exception, but I that line, nor the MFC code it calls, doesn't touch any .NET stuff whatsoever. (Well, at least I wouldn't expect the MFC code to do that.)

And, as Victor already asked: What does AfxGetApp() return?

Finally, just to make sure: The correct version of the .NET framework as well as the required CRT and MFC DLLs are installed on the target system, aren't they?

Thank you for your help.

Quote:

---

Which features of the .NET framework are you using?

---

I have to use some DLLs to communicate with a camera, DLLs that work in .NET framework. However, if I cannot manage this, I will contact the camera manufacturer and try to get the C++ source code to communicate with it.

Quote:

---

BTW, is the host app .NET?

---

No, it isn't a .NET application

Quote:

---

One diagnostic step you can take is writing two minimal host apps using your DLL, one MFC-based and one .NET-based, both not touching the respective other technology.

---

I tried part of this. I added some .NET functions to the original DLL and compiled it. Then I created another .NET project and used the DLL, using these new functions, and worked fine. On the other hand, I created a MFC project, but I don't know how to add a DLL reference to that project, I have never used MFC before, sorry.

Quote:

---

And, as Victor already asked: What does AfxGetApp() return?

---

With the original DLL, it returns a pointer, but I don't know what this pointer refers. Anyway, when I eliminate that line, the original DLL works the same, and the new DLL crashes the same.

Quote:

---

Finally, just to make sure: The correct version of the .NET framework as well as the required CRT and MFC DLLs are installed on the target system, aren't they?

---

Yes, they are correctly installed. All the applications are running in the same PC, where .NET, Visual Studio and so on are installed.

Quote:

---

Originally Posted by dariotojeiro

I have to use some DLLs to communicate with a camera, DLLs that work in .NET framework. [...]

---

What interface, exposed by these DLLs, do you use to communicate to them? Plain .NET classes/functions? COM? In the former case it may (just?) be a matter of writing a native wrapper for the .NET interface, which is quite a common procedure in interop scenarios, and as such has been done already quite some times, so chances are we can get that to work. If it's COM, OTOH, the fact that the camera DLLs are using .NET should for the most part be transparent to the COM client, and ideally not mattering at all if the DLLs are implemented properly.

Quote:

---

[...] On the other hand, I created a MFC project, but I don't know how to add a DLL reference to that project, I have never used MFC before, sorry.

---

I have done some MFC in the past, but that's quite some time ago, so I'm a bit rusty at that. However, interfacing to your DLL shouldn't depend that much on MFC anyway. If your "production" DLL project, i.e. the one that interfaces to the camera over the 3rd-party DLLs, and your test client project are part of the same solution, it's probably the simplest approach to set up a project reference to the production DLL project in the test client project.

If they're in distinct solutions: Buiding the production DLL should have produced a .lib file of the same base name along with the .dll. This is the import library that you can add to the additional dependencies in the Linker\Input properties in the test client project. The import library just announces the functions defined in your DLL to the linker and contains no actual executable code. Therefore you must make the actual DLL accessible to your test client executabe, and the easient way to do that is to copy the DLL to the directory where that executable is. All the dependencies of your DLL need to be accessible as well. (Setting up a project reference may be possible in this scenario too but more complicated.)

Quote:

---

With the original DLL, [AfxGetApp()] returns a pointer, but I don't know what this pointer refers. Anyway, when I eliminate that line, the original DLL works the same, and the new DLL crashes the same.

---

AfxGetApp() returns a pointer to the singular MFC application object. I doubt a DLL that is used by a host app should have such an object of its own at all, but perhaps it returns the host app object, but then not only the host app must iself be MFC-based, the object also needs to be passed to the DLL somehow. Not really sure about all that, though. Rusty, as I said...

The fact that removing the line doesn't eliminate the crash as such but changes the crash location reported may indicate that it's not AfxGetApp() itself that suffers the crash, but rather something that is called by it in turn (unless the alternative crash location is itself a call to AfxGetApp() or lies inside that function or anything that has been called by it, directly or indirectly). The MFC library comes with source code, so stepping into the library functions when deugging may provide additional insignt, but it probably is a bunch of work and perhaps we can achieve an equivalent result by simpler means.

I think that this is a bit more than I can handle. I got the C++ code to control the camera, so first I will try to use this code in the original DLL, leaving aside .NET libraries. Hopefully this solution will work.

Anyway, thank you for your help.

Best regards,

Daio

If the host app is native (i.e. non-.NET), this most probably is the optimal solution.