I have an MFC application that uses several MFC extension DLL's. I want this app (and several other similar apps) to be able to access some parts of the .net framework. I wrote a C# library to do the .net work I want and was hoping to be able to write an MFC dll to hide all the C++/CLI code from my apps. The apps would stay as pure MFC apps and the only C++/CLI code would be in my new MFX extension DLL. However when I did this the apps crashed when accessing the new MFC C++/CLI dll. If I put the C++/CLI code in the apps it works ok and I can debug my way all the way in to the C#.
Does anyone understand why the dll idea doesn't work?
Thanks
You can't reference managed assemblies from pure native code. You have to either flip the /clr switch on the consumer (either project-wide or in certain files,) or do some interop.
One interop option that will allow your consumer to say pure native is calling into the managed assembly via COM Callable Wrapper.
I believe I have run into a similar problem. My setup was similar - A pure MFC app with a pure MFC DLL which in turn interacted with the C++/CLI DLL. Everything would run fine, but it would crash on exit. The problem was exacerbated while testing the pure MFC DLL using CppUnit.
On debugging, I found out that due to a bug, my C++ code was throwing first-chance exceptions for access violations (objects referenced via a dangling pointer) on exit. Now, the C++ runtime ignores these violations on exit, whereas the CLR does not. The CLR runtime throws an unhandled exception making it appear that the program / unit-test crashed.
Your problem maybe different, but it does sound quite similar to the one I had.
The MFC dll project references the C# library and has one file compiled with /clr that handles the interface into my C# library. I have actually seen this work sometimes at run time but have never been able to debug into the MFC dll or into the C# code. However it doesn't seem to be at all stable and crashes in the majority of cases.
Related
I need to add Common Language Runtime Support (/clr) to my mfc dll project in order to use managed code in it.
I have do some setting for the all projects according to how to compile MFC and ATL Code By Using /clr from msdn.
I have done a lot of testing. But still failed to run my application although I only add the /clr support to the project without adding any managed code.
See below for details：
The exception, call stack, output information, the difference of output information and dependency dll between using and without using /clr please see Exception Detail
I can't get any useful information from call stack. I don't know even where to add the break point for debugging. Anyway, it's too later to add the break point at the InitInstance() of the application.
It seems the exception caused by loading dlls according the output information. But I don't know the really reason.
Otherwise I have downloaded a sample solution from msdn see Sample about Using /clr in MFC. The sample contains a mfc application calling a mfc dll with /clr support. And it works well. When I add my mfc dll(with /clr support) into this sample, it can work well too. I really don't down why it can't work in my solution. I have checked the property setting of my project compare with the sample solution. There seems nothing special.
I do need help, any suggestion?
Thank you all.
I have solved the issue by delaying loaded the dll that cotaines /clr support in the project calling it. See Set Delay Loaded DLL for how to delay dlls. It seems the exception caused by the chaotic unmanaged and managed initialization.
"Unmanaged and managed initialization is performed in two separate and distinct stages. Unmanaged initialization takes place first (via DllMain), and managed initialization takes place afterwards, through a .NET-supported construct called a .cctor. " See Initialization of Mixed Assemblies for details
I am trying to add an unmanaged C++ dll to a managed (CLI) C++ dll project. When I click the "class wizard," I get a "MFC classes can only be added to MFC projects" error message. I am not using MFC, to the best of my knowledge (Use of MFC is blank under my unmanaged dll's project page). Is there another way to add an unmanaged dll to my managed dll's project?
For anyone who is interested, I've thrown the rared solution up on my DropBox account: https://dl.dropbox.com/u/98752313/CplusplusArrayTest.rar
I realize there are far too many settings that could be wrong for me to simply copy and paste everything into the available space.
There are three projects within this solution. CplusplusArray (should be complete, it's the unmanaged .dll), ManagedCpluspplusArray (need to add the unmanaged dll, and modify a few things, it's the managed .dll), and a C# test program (not written yet, will hopefully talk to the unmanaged dll through the managed dll).
The whole goal of this project, if you are wondering, is to give C# the ability to use arrays with longs as the indexers. If you've used any amount of .Net before, you may have run into the Int32/Uint32 limit on the size of objects in the CLR. I am hoping to get around that by implementing the array in C++ land, then modifying / compiling some Mono Collections.Generics classes against it, thus giving us some breathing room. The reason I am doing C# -> C++/CLI -> C++ is so that, according to my research, we can use object oriented code with it; the DllImport stuff works fine for C-like functions only, and I want to preserve OOP, rather than modify things to work C-like. Since arrays are the building blocks of the List / etc. classes, from what I can tell, of the Collections namespace, getting just them to function in 64-bit land will give us everything else.
You need to add a new project, not a new class. Once you "Add Project", you will be asked what type of project you want to add, and a plain C++ DLL will be one of your options.
Once you have both projects in your solution (a C++/CLI DLL project, and a C++ DLL project), you can go to the workspace dependencies and indicate that one of them depends on the other.
Additional notes:
The Class Wizard is all about adding MFC classes. Because you're not interested in adding MFC classes, this is not the right tool to use.
When I have written a C++/CLI DLL that utilized a native C++ DLL, I needed to add instructions to link to the C++ DLL's import library. This was configured in:
"Project Properties > Configuration Properties > Linker > Input > Additional Dependencies"
The workspace dependencies guarantee that the unmanaged library is built first, and that if the unmanaged library is updated, the managed library will be recompiled or relinked if needed.
Our VB6 program currently calls code in a C++ dll. This dll does not need to be registered, it only needs a .def file specifiying the properties and methods. Vb6 late binds to it. The dll is written in VS2005 without a dependency on the Net framework.
As we are migrating our application to Net4 and also want to enhance the C++ dll with new functionality, I was wondering how to migrate the existing C++ code to VC++. I suppose thereafter the dll will just happily integrate in our solution which already contains C# and VB.Net libraries too.
Is there some tutorial/documentation about the do's and don'ts of this plan?
EDIT:
I think I have some basic misunderstanding about VC++, thinking that it can be ported to 100% managed code while keeping the C++ syntax. The replies I get seem to indicatie that VC++ will always produce native, unmanaged code?
From a pure C++ point of view, you should be able to convert the VS2005 solution and project to VS2010 automatically. If I recall when you load the solution or project into VS2010 it will automatically convert it for you.
If you open the VS2005 project file in VS2010, VS2010 will automatically convert the old project to the new project format and the auto-conversion will do it's very best job to get everything correct. This usually works, but not always. So the moral of the story here is, double-check all of the new project's compiler/link settings, to be on the safe side.
Also with VS2010, you have some better interop possibilities between managed and native code: P/Invoke and C++/CLI. P/Invoke is simpler, but you will find that stuff may compile but fail at runtime. C++/CLI is way more flexible, a bit more work, but makes it much easier to debug the interop, when it becomes necessary.
I got the VC++ source code of a dll for a USB device project, which the deadline is close. Right now I have to call this usb dll from another VB program. But the source code is based on the template "MFC Extension DLL", which can´t be called by VB. On the other hand, "Regular DLL with MFC statically linked" can be called by programs written in Visual Basic.
Is there a way, with the least effort of modification of the source code, to be able to call this dll directly from VB?
I tried to modify the project´s configuration properties/Use of MFC to Use MFC in a Static Library. But there is build error.
Now I am modifying the source code based on the new template "Regular DLL with MFC", but there is a lot of problems. For example, I don´t know whether I can use AFX_EXTENSION_MODULE in my new dll code.
Your problem is likely due to not implementing a CWinApp derived object which provides services that the MFC classes in the DLL rely upon. Probably you can just bung one in and it will work.
See here for more information:
http://msdn.microsoft.com/en-US/library/h5f7ck28(v=VS.80).aspx
I am working on a wxWidgets console application that I want to call into = a C# DLL from, via the CLR. Unfortunately, the application hiccups in the wxWidgets application initialization code because OleInitialize is failing. The error I'm seeing is a pop-up simply stating "Cannot initialize OLE."
It seems that this problem is usually avoided by setting the apartment style for threads by applying a directive to the application's entry point but I'm really struggling with what entry point I'm looking for. My C# code is a DLL: there's no specific entry point. The code compiled with /CLR exists in a .lib which is linked into my wxWidgets application. wxWidgets actually defines the WinMain in their code, and allows me to override behaviors via implementing wxApp.
Other suggestions include disabling OLE support in wxWidgets but In my release, 2.8.6, setting wxUSE_OLE, wxUSE_CLIPBOARD, wxUSE_DATAOBJ, wxUSE_DRAG_AND_DROP to 0 creates unresolved externals while compiling wxWidgets.
Has enjoy encountered this before and found an effective work around? Can anyone provide any clarification on what entry point I need to be modifying?
As mentioned in my question, this is a problem involving the thread style settings between the C++ application and the CLR defaults. This was apparently a bug, once upon a time, and Microsoft has released a fix:
http://msdn.microsoft.com/en-us/library/s6bz81ya.aspx
Recompiling the executable the uses the CLR-enabled .lib with /CLRTHREADATTRIBUTE:STA was sufficient to eliminate the errors I was seeing.