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.
Related
I have a VS2017 MFC C++ application which uses a ribbon based UI. Up until now I have been using the statically linked MFC libraries but now have to move to MFC in a DLL as I need Multithreaded DLL linkage /MD in order to support another third party SDK (Vulkan). One of the reasons for using statically linked MFC is that it allowed me overcome some problems in the implementation simply by including the source for the item I needed to change in my application. e.g. to use data the edit part of a combo box to select the nearest item in the drop down. This doesn't work when I use the DLL version of MFC for obvious reasons, is there any way around this? I can't simply inherit from MFC base classes as my application is building the ribbon interface from a ribbon resource file and there don't seem to be any hooks to customise this behaviour.
My current thoughts for possibilities include building my own version of the MFC DLLs or simply adding the full MFC source as a sub-project and change my main project Use of MFC to Use Standard Windows Libraries. Both of these seem like nasty hacks.
Edit: In response to the comment below from IInspectable, I'm not entirely sure why the current behaviour doesn't work but have some ideas. Linking the static lib version of the code, if I include my own copy of a function that occurs in the lib, the lib version never gets called (possibly never even gets linked). When linking the DLL version of MFC, my modified function never gets called. This could be because it is called by another function in the same DLL which never sees my code or it has a slightly different decorated name. My thinking is that including all the MFC source in my app and not linking any MFC in the compiler options is one brute force solution, though a pretty horrible one.
I ended up recompiling a custom version of the MFC DLL based on this project, https://www.codeproject.com/Tips/5263509/Compile-MFC-Sources-with-Visual-Studio-2019 This lets me keep my MFC modifications while also using MFC in a DLL with minimal changes to my existing project
This is a newbie request. I'm looking for materials on .dll creation. Specifially, i want to create a .dll out of a simple 3D engine i've made to learn about the process. I need information on dynamic link libraries that go deeper than the wikipedia page, how are they created, what's necessary, how to create different .dll files for "debug" and "release", how to create a PDB file for it and how to create a header file that'll allow for easy usage of the library from a, f.e., C++ program. Material with strong theoretical side (not as much, "how to create a dynamic link library in visual studio") would be great.
Please share good materials on the subject, all i can find is some information here and there and it doesn't paint the picture for me.
Reading between the lines, I think you really want to know about libraries in general rather than dll's specifically. A library is simply a handy package of object (compiled) code, along with some information about how to call into it. In C++, this usually takes the form of a .h file.
With static libraries (.lib), the linker pulls in the code it needs in exactly the same way as it does with all the rest of your classes. A normal class will get compiled to object code (MyClass.obj), and when they're all done the linker sticks them all together and wires up any inter-object calls with the appropriate addresses. It's the identical process with .lib library files. You end up with a big ball of executable code which includes both your classes, and the library functions within it.
With a dynamic library (.dll), the only difference is that the linking (wiring) happens at runtime instead of at compile time, and the library object code remains in a separate ball - the dll file. When you compile your exe, all calls that use functions in the library are mapped to a stub function. When Windows loads the dll for you, it will stick the dll code into the same memory area as your process, and wire up the stub functions to the real functions that are now available.
The only other difference is that a dll must expose a function that Windows can call when it loads or unloads the dll, in case the dll wants to do any initial setting up / clearing down. This is traditionally called DllMain().
If you want to learn about libraries, I would concentrate on creating a static .lib first before worrying about dll's. This is where most of the work is. Once you have a lib it is child's play to turn it into a dll.
The main thing you need to think about when creating a library is how you are going to expose your API (Application Programming Interface). This is just which functions/classes you are going to expose to the people using your library. You don't have to expose them all, but you do have to decide WHAT to expose. Are you just going to expose some C style functions, or are you going to expose entire objects? This is the real challenge when designing a library. You should try and make your API as easy to use, and obvious as possible if people (and you!) are going to find your library useful.
As for pdb files, differently named release/debug modules, and creating .h files. These are identical to when doing so in an exe.
1) Create a new DLL project, using VS wizard.
2) Add your existing source files to it.
3) Put into *.def file (which should have been created by the wizard) the names of the functions that you want to export from your DLL, as described here.
Basically, that's it. Debug and release configurations are automatically created by the wizard, but if you want the 2 variants to be named differently, you can change their output names: go to Project Properities -> Configuration Properties -> General -> Target name.
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 have inherited an old C++ (MFC) project and will have to add new functionality.
The new functionality will mostly not conflict with the existing C++ code, like additional dialogs etc.
Having limited experience with C++ MFC, I would very much prefer to do the additional functionality in Delphi, create a DLL and use the DLL in the C++ project.
I guess this is generally possible, similar to using C++ DLLs in Delphi?
Are there limitations on what can be done this way?
Basically, there are no issues. But if you're going to use dialogs and so on, your application will be using two frameworks, MFC and the VCL, and they may not play very well together.
Delhi if I recall my history should create Dll's happily. See here 'Calling delphi DLL from MS Visual C++' for an example
I am working on a neural network project that requires me to work with C++. I am working with the Flood Neural Network library. I am trying to use a neural network library in an unmanaged C++ project that I am developing. My goal is to create an instance of a class object within the Flood library from within another project.
There is plenty of documentation online regarding how to reference an unmanaged C++ project from within a C# project, but there is not enough information on how to reference one C++ project within another. Similar to how I would do it in C#, I added the Flood project as a reference in my other project, but I have tried all sorts of techniques to work with the object. I have attempted to use the #include directive to reference the header file, but that gives me errors stating that I need to implement the methods declared in the header file.
How to add a reference in unmanaged C++ and work with the class objects?
Yes. You need to do two things:
#include the respective header files, as you did
Add a reference (Visual C++ supports two types, "dependencies" which are outdated and should not be used anymore, and "references" which are the correct ones). Use them to reference the other project, which must be a part of your solution. Meaning, in this case you must be able to COMPILE the other project.
Alternatively, if you do not have the source code, or you do not wish to compile the 3rd-party code for any other reason, you may also reference a compiled binary. The best way to do it is pragma comment lib. If this is what you need, please comment and I will edit my response.
Looking at the provided vcproj file, the flood distribution is really weird, and builds an exe file.
As such, the supported way to use Flood in your own project is not via two projects (being your application and a "libflood" project) - But simply to add all the flood cpp files to your own project and build that.