Using MFC with Windows Forms

Hi everyone--

So this may be a silly question, excuse me because I'm very new to VC++..
The essentiality of this question is this:
I'm using MS VS 2005 Standard Ed. When I create a new Windows Forms Application, and try to include afxwin.h, the program will compile just fine, but when I try to run it, it gives me a debug library error:

Debug Assertion Failed!

Program: ...
File: dbgheap.c
Line: 1414

Expression: _CrtIsValidHeapPointer(pUserData)
.

The reason I would want to do this is that I'm trying to create the User Interface for a program, but the base libraries I'm leveraging were originally written in VS6.0 and use MFC, and yell at the references to CWnd when I don't include afxwin.h.

Any ideas on how to approach this problem
I really don't want to have to give up everything I've already written using Windows Forms.

Visual C++8

No answer I'm afraid but some more info that might help the experts solve this issue. I've seen this error but also have seen the program deadlock at startup at various places, one of them on the infamous loader lock. The easiest way to reproduce this is to start a new project with the wizard and pick the C++ Windows Forms template. Change the compiler option /clr:pure to /clr and just add #include <atlbase.h> to the main C++ file.

The current deadlock I'm getting has this call stack trace:

rpcrt4.dll!LRPC_CASSOCIATION::CreateBackConnection() + 0xb80a bytes
rpcrt4.dll!LRPC_CASSOCIATION::ActuallyDoBinding() - 0x11a6 bytes
rpcrt4.dll!LRPC_CASSOCIATION::AllocateCCall() + 0x21bbe bytes
rpcrt4.dll!LRPC_BINDING_HANDLE::AllocateCCall() + 0xb6 bytes
rpcrt4.dll!LRPC_BINDING_HANDLE::NegotiateTransferSyntax() + 0x23 bytes

ole32.dll!7760142b()
[Frames below may be incorrect and/or missing, no symbols loaded for ole32.dll]
ole32.dll!7760122f()
ole32.dll!77525de6()
ole32.dll!77525d81()
rpcrt4.dll!NdrpPointerBufferSize() + 0x1132d bytes

rpcrt4.dll!_NdrClientCall2() + 0xa55 bytes

ole32.dll!7750ea34()
ole32.dll!77505979()
ntdll.dll!_bsearch() + 0x46 bytes

[Managed to Native Transition]
> cppforms.exe!_initterm(void** pfbegin = 0x00408180, void pfend = ) Line 130 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative() Line 534 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize() Line 680 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::Initialize() Line 824 + 0x9 bytes C++

Here's another one, same program after a clean rebuild with the program deadlocking on the loader lock:

ole32.dll!775063af()
[Frames below may be incorrect and/or missing, no symbols loaded for ole32.dll]
ole32.dll!7750c57e()

ole32.dll!77527ed5()
ole32.dll!77527e3e()
rpcrt4.dll!NdrpInterfacePointerBufferSize() + 0x60 bytes
rpcrt4.dll!NdrpPointerBufferSize() + 0x1132d bytes

rpcrt4.dll!_NdrClientCall2() + 0xfc bytes

ole32.dll!7750ea34()
ole32.dll!77505979()
ntdll.dll!_bsearch() + 0x46 bytes

[Managed to Native Transition]
> cppforms.exe!_initterm(void** pfbegin = 0x00408180, void pfend = ) Line 130 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::InitializeNative() Line 534 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::_Initialize() Line 680 C++
cppforms.exe!<CrtImplementationDetails>::LanguageSupport::Initialize() Line 824 + 0x9 bytes C++

Is there a bug in Product Feedback on this, Hans

Yes, I should research that Brian. Could you recommend a search term, "loader lock" isn't going to get me anywhere.

Generically, this has all kinds of different behavior, I've seen the invalid heap pointer assertion and when I tried to re-create it, I got the deadlocks. Different ones with the same .EXE. Sounds a lot like "you shouldn't try to do this". Did you ever get it to work

I've never seen this myself. If you can provide a repro that is submittable, then you'd be saving future devs headaches! :)

This is caused by /entry:main switch in the linker settings. Your winforms application by default sets to /entry:main to tell linker that entry function in user code is main(array<String^>^). When you make your Winforms application compile as /clr, not /clr:pure and you add MFC headers, you need to remove this command and /subsystem:Windows to make it work. There are bugs reported about this.

However, I am questioning if you are building a right level of abstraction. If your exports in your DLL take MFC type of parameters and DLL consumer is not MFC, this is bad practice of passing data types across DLL boundaries and you are steps from issues related to this. I recommend creating a level of abstraction between WinForms application and MFC dlls that uses C++ built-in types or Win32 types only.

Thanks,

Nikola

Thanks for the feedback, but, ummm, sputter. I ran into this issue just because I thought I needed the A2OLE macro from ATL. Can you give us some insight in how the ATL plumbing (just getting the static trace stuff linked in) is messing up the works to the point that deadlocks and heap destruction is the result

I had the same issue as nobugz -- Winforms app, /clr, uses MFC, similar crash. As suggested, I tried turning off /entry:main and /subsystem:windows, but then my app comes up as a console app and does not run (no form!) :(

Ok, I found a workaround at

http://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx FeedbackID=99715

I have an MBCS app, so I had to use WinMainCRTStartup instead of wWinMainCRTStartup.

My app now links properly and runs.