I am using Visual Studio 2015 Community Edition and I followed Microsoft's tutorial on creating implicit dll's here https://msdn.microsoft.com/en-us/library/ms235636.aspx and I referenced the dll successfully in a C++ console application (I did it just to see if it would work).
When I tried adding the dll project to the references for a Visual Basic Windows Form Application, I got an error saying "A reference to 'DLL Project Name' could not be added." After some research, I think it's because VB targets the .NET framework while the C++ dll targets Windows, but that's all I managed to figure out. I would greatly appreciate any help on reconciling this, or setting up some solution that involves a C++ dll and a GUI project that uses the dll (I just chose VB for the GUI since it's really quick and easy to set up).
Note that both the DLL project and the Visual Basic project are in the same solution.
Your tutorial won't help you invoke the code from .NET and you are correct in assuming it to be a .NET framework inter-op. issue. You can use p-invoke to import and call the DLL or create a COM wrapper around your DLL and register it in the GAC then reference it via a COM CreateObject call.
Other possibilities are to convert it to a C++/CLI .NET C++ DLL.
References:
P-Invoke
COM
-UPDATE-
I suppose I should also mention that if you target Universal Windows Platform (UWP), it also provides a clean binding across .NET and C++ and hides some of the busy COM wire-up.
A C++ DLL should be added to your *.NET application with a post-build event "xcopy" command like this one:
xcopy "$(SolutionDir)DLL\$(ConfigurationName)"\*.dll "$(TargetDir)"*.* /Y
from your selected project go to Project-->Properties-->Compile-->Build Events-->Post-build event command line
Enter the appropriate copy command.
In the above example, several C++ DLLs were collected in a "DLL" folder in the Solutions Directory. They all get copied to the application folder every time the application is built. There were DEBUG and RELEASE versions of those DLLs in separate sub-folders.
As other posters noted, you also must have correct p-invoke declarations for your C++ DLLs in your *.NET code.
Related
I'm building an application using Qt 5.3.1 in Visual Studio 2012. I also want to use a hardware library which requires me to add a simple ATL object to the project. This can be done by using a Visual Studio wizard. The wizard complains that my project is neither an MFC executable nor an MFC DLL with full ATL support.
My question is: How can I add this support to my application? In the project properties I configured the project to link to the ATL and use the MFC. It did not work. Both statically and dynamically.
If there's another solution in order to add a simple ATL object to the project, please let me know.
The wizard which adds ATL support works on source code of the C++ project, including both checking if the current code is already ATL project, whether the project is okay for adding ATL support to, and code modification per se.
If the wizard "does not like" something in your project it displays an error which basically means that the wizard does know how to safely modify your source code. It does not however mean that adding ATL support is impossible. And enabling an option in project settings is insufficient since source code needs some explicit initialization stuff.
The best you can do to add ATL support without thinking too much about it, is to create a new empty project that matches the project type you currently have, e.g. MFC application. Then take a snapshot of source code, then add ATL support using the wizard. Then compare changes and duplicate them on your real project. The same applies to next step of adding ATL Simple Object using Visual Studio wizard.
Some relevant links (even though the method above looks the easiest to me):
How To Add ATL Support to an MFC EXE
Adding ATL support to existing mfc application
Add automation support to MFC DLL
Using Visual Studio 2013, I have created a Windows Phone (8) app which references a Windows Phone Runtime Component which in turn references a C++ DLL (all in the same solution). Without doing anything explicitly, the DLL would not get deployed to the target platform, and so there would be a runtime error as the runtime component attempted to load the DLL. I got around the problem by adding the DLL (the DLL project output) as an additional deployable file to the runtime component project. (As one might add any other data file)
While my hack works, I'm sure it is not the correct thing to do... because it is a reference to the debug DLL (no release DLL built thus far), and if I were to do a release build for the solution, the same debug DLL would be deployed, where it ought to be the release version.
What is the proper/best practice way to ensure that the correct (debug vs release) "sub" project DLL gets deployed with a phone app?
The right way is to include the dll project in your solution and than in the References of the Solution Explorer via the opening dialog.
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 need to create a windows DLL that exports functions and has a graphical user interface. The reason for the GUI in the DLL is that the DLL serves as a kind of plugin for another 3rd party application. Currently I only have access to Visual Studio Express which AFAIK doesn't support MFC so I'm looking for alternative ways to create a GUI in a DLL. After some research I came across Qt which seems promising. And it seems like it might be easier to just use the Qt Creator IDE rather than Visual Studio Express.
However, how do I create a windows DLL in Qt Creator? (I guess a regular DLL, I don't think a COM or managed DLL will work)
UPDATE:
I got this working! After jumping through several hoops, two important keys were to add
#include <windows.h>
And then to use the Qt/MFC Migration Framework tool (currently officially available at: http://qt.gitorious.org/qt-solutions/qt-solutions/trees/master/qtwinmigrate EDIT: I believe this is the new link: https://github.com/qtproject/qt-solutions/tree/master/qtwinmigrate)
I used this example to get me going:
http://doc.qt.nokia.com/solutions/4/qtwinmigrate/winmigrate-qt-dll-example.html
EDIT: I believe this is the new link http://htmlpreview.github.io/?https://github.com/qtproject/qt-solutions/blob/master/qtwinmigrate/doc/html/winmigrate-qt-dll-example.html
Add the folowing line to the .pro file: TEMPLATE = lib
That's just about all you'll have to do to have QtCreator make your 'app' into a dll.
check qt plugins http://cartan.cas.suffolk.edu/qtdocs/plugins-howto.html
I have a vb project which calls functions in a dll.
The dll is created in a separate vs project (portaudio), which is written in c.
The dll c project compiles clean and builds the required dll, which I am currently dropping in c:\windows\system to vb runtime can see it.
VB Project lives in c:\devprojects\vbtest
C Project lives in c:\devprojects\portaudio with the project file in c:\devprojects\portaudio\build\msvc. Dll created in Win32\debug under this msvc directory.
When I call the dll function, is it possible for the vs debugger to step through the c function in the dll - I have all the code etc, but I don't know if VS2005 supports this kind of mixed language debugging.
If this is possible, could you advise how I should set up my Visual Studio to achieve this.
Many thanks
David
It is not necessary to have both projects in the same solution, but you should compile both projects with debug symbols enabled.
Now in your VB net solution Project/Properties, in the Debug tab make sure that "Enable unmanaged code debugging" is checked.
Also make sure that the dll loaded is in the same place where it was compiled, else it may not found the pdb where the debug symbols are stored.
Create a solution with both projects, add the reference in VB project to C project using 'Add Reference..' dialog -> Project and build them all in debug mode.
How do you calls C dll from VB?
If its VB.NET then this is very easy, just set up a solution with both projects under it, set up their dependencies and ensure that on build the debug version of the VB project links to the debug lib/dll produced from your C++ project. Visual Studio does the rest.
I've done this before a couple of times with C# applications calling a C++ dll. I didn't intend to set this up, but tried stepping through whilst debugging assuming I would get the assembly listing and could at least work out somethig of what was going wrong with my code... however it loaded the correct .cpp file and allowed me to continue stepping through that code.