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.
Related
I have legacy code in C++Builder 6. I try to create a DLL from source code, but only one thing which I have on output is an EXE. I tried to change the application target extension and entry point, but nothing helps.
I think about compiling from console, but there is some errors in the project, that I can't see when compiling in the IDE. I have linker errors, which I can't fix.
At least all code are "extern C" and I need lib and dll.
How can I compile a DLL from the app source?
A DLL needs certain pre-defined functions and the project Wizard creates them for you automatically, so
Start a new fresh project as a DLL/library project.
Create a simple function that you can test.
Compile the DLL and load it (and call the test function) from an .exe in another project to check that it's working.
Copy the essential parts of your old code, bit by bit, from the old .exe project into the correct places in the new DLL/library project.
Done.
Basically, I have a Visual Studio project that builds a DLL (a VST audio plugin). Where this type of project scenario has been set up for me in the past, I would be able to build, run, and debug the plugin. Visual studio would automatically launch whichever program I was using to host the plugin. I am trying to achieve the same effect in my current project, but I don't know how to set that up. Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". The DLL still builds, and I can still run it, but I can't debug it from Visual Studio, because I don't know what I need to do in my project settings to make this happen. How can I do this?
MORE INFO:
What I do know is that, in projects where this sucessfully works, there are some modifications made to the Visual Studio project settings under fields marked 'pre-build events' and 'post-build events', so presumably what I want to do is edit these in some way to tell Visual Studio the following: "Hey, before you try and run and debug this DLL, you have to launch another program (my program is called Max.exe), and then you have to wait until that program loads the DLL. Then you can debug! Don't be a stupid computer and try to debug it before it's even loaded in Max.exe..."
What I do not know : EVERYTHING ELSE. This is literally all I know about what I'm trying to do, hense the colourful attempt to talk to a computer in English.
Currently when I build and run my DLL in Visual Studio, I get the error "Unable to start program". This is unsurprising seeing as the project knows nothing about the environment I want to use to test the DLL, but the problem is that I don't have a clue what Visual Studio needs to know. I really don't know enough about programming to understand the implications of what I'm trying to do either. Yes, I did mention those fields marked pre-build and post-build because I remember them being important, but I don't know exactly what or how to write in those fields, and I also do not know if there will be more things I need to tell Visual Studio before this will work.
Q.E.D I'm not actually sure what pre and post build events are, or how they work. And I barely know the first thing about customizing VS project settings. All I know is how to write audio processing code. I felt the need for this disclaimer because typically my questions are met with angry programmers who think I don't do my own research; they fail to realize I am an audio engineer who skipped programming 101. Yes, how to debug a dll is a common question I'm sure, but answers to those questions tend to assume pre-requisite knowledge that I do not have.
You will want to edit the Command field in your project's Debugging properties. Right-click on your project in the solution explorer and click Properties (it's generally the last item). Open the Debugging page under Configuration Properties. The Command field indicates which executable to launch when debugging.
By default this contains $(TargetPath) which refers to the final binary your project compiles. This is useless for DLLs since DLLs are not executable. Change this to the path of whatever third party application you are writing a plugin for.
With this change, launching with debugging will actually launch the third party application and attach the debugger to it. Once the application loads your plugin, you will be able to debug it normally.
For Visual Studio,
In Solution Explorer, right click on project and select Properties.
In Properties, choose Configuration Properties -> Debugging.
For Command, enter the full path of the executable that will be loading your DLL. Fill in the Command Arguments and Working Directory accordingly.
In addition, you need to make sure that the executable actually loads the DLL you are building. A mistake that a lot make is to launch their executable, and not realize the executable is loading another version of the DLL they are trying to debug. This can happen due to Windows searching for the first DLL that it finds using the DLL searching logic (exe directory, path, etc.).
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.
I am a professional working for a software firm.In my past company basically i was working on C & C++ on unix.Now i suddenly shifted to C++ on Windows and i feel like i am in a completely different world.Basically i am working on a very big application which was totally written in C++.To keep it simple ,i dont have the source code .I have the exe of the application and several other dependent files.it is a GUI application(several windows,reports,graphs and huge mathematical calculations are done by this application).Now i finally have the source code of the application which includes some headers,some vcproj files,some dsw files and several other which i dont even understand why the hell are they present.
Now as i C++ programmer my responsibility is to make all the BUGS that the clients identify replicate and fix them.
If its a bug on unix i can simply use the binary and source code and run gdb/dbx and find out the issue in some or other way like adding adding some printf statements.
But given the files i mentioned above.how could istart debugging an application in VC++ in VISUAL STUDIO.
Is it very difficult for a C++ programmer to shift from Unix to Windows.
Is ther any good resource which i could refer for this kind of change where i could grasp things quickly?
given the exe and the source code of the application how can i start debugging a program by running the application in VS C++-(BTW i am using VS 2005)
The main difference is that on Unix, you'll have Makefiles, which you won't find on Windows. Visual Studio organizes your code in projects and solutions, and those project files contain all the information VS needs to compile&link your projects.
If you have a *.sln file, just double click it to open it in VS. Then build the source (usually by pressing F6) and run in debug mode (usually F5).
More details:
A project is a collection of source files that result in 'something', usually a LIB, a DLL or an EXE.
A solution is a collection of projects. Useful when e.g. one project creates a LIB that is used by another project. When you set dependencies between projects, VS will build the projects in the right order.
Extensions used:
*.vcproj : Project file for C/C++ sources
*.vcproj..user : contains which windows are open in the GUI.
Can safely be deleted.
*.sln : Solution file
*.ncb : Intellisense database for a solution. Can safely be deleted.
*.suo : contains which windows are open in the GUI. Can safely be deleted.
*.dsw : Visual Studio 6.0 related file - not used in VS2005. (Replaced by *.sln IIRC)
./Debug/* : folder with all
intermediate files for a Debug build
(can be changed)
./Release/* : folder with all
intermediate files for a Release
build (can be changed)
That's all I can think of at the moment.
If you only have a .DSW file and not a .SLN file, then it means that the project was probably last worked on with VC6 and not one of the later Visual Studio versions.
That's a shame, because there have been lots of changes to the C++ compiler since VC6, and you're probably going to find the project doesn't compile with VS2005 without needing some minor changes to source code.
Do you have a .SLN file - if so, what's the version number at the top of the file (it's a text file)? If you don't have a .SLN file, can you get hold of VC6?
I would always try to get stuff going on an unfamiliar platform with the best matching tools, before I tried to bring it forward to later versions.
I understand your pain; I took the same path a few months ago.
You probably figured it out, but Visual Studio is not the exact alternative of gcc/g++. It embeds a text editor, a debugger, and so on.
Usually, you have two compilation "modes", debug and release. (you can add your own)
When in debug mode, all optimization are disabled and you can execute your program in the debugger, use step by step, add breakpoints, ...
Just start it using the F5 key.
More notes on the additional files:
In the Visual Studio world, .vcproj files represents "projects": a bunch of file that belongs to the same project (source files, headers, resources, ...).
A .dsw (old name for current .sln files I believe) is a "solution" file: a group of one or several projects which can have internal dependencies. Example: you can have in the same solution, a library and a software that depends on it. So that when you compile the whole solution, things are built in the correct order.
First thing you should try is to attach to the process while it's running (Ctr-Alt-P and select the process) if you have the .pdb (debug information) files you should be able to debug the process without re-building it.
If that fails try to un-check the "Require source files to exactly match the original version" option in Tools -> Options -> Debugging.
If that too fails you'll have to build the application again (by opening the .sln file and performing a build) so that the binary matches your source files.
Good luck.
Compile the code with debug info and press f5 (Start Debugging). I don't see where is the problem. On linux is sort of the same.
VS2005 can convert the dsw file for you to a sln file, but you need all of the original VC6 files in order for the conversion to be successful. For debugging please check out following msdn link, I hope this will help you.
http://msdn.microsoft.com/en-us/library/sc65sadd.aspx
Please select hyperlink "Debugging Native Code" for C++ specific.
Im using vs 2003. When I try to debug some program that uses several dll files i can debug
(put breakpoint - without question mark) only on the cpp files of the project that creates
the dll and was the last one that i compiled . breakpoints located on others dlls (that are part of the program and located in the same solution) are marked with question mark and the debugger doesnt reach them at all.
how can i solve it ??
thanks,
liran
You must build these dll's as debug and make sure they have the correct symbols in them? just a guess.
You can load up the symbols from other assemblies by specifying the symbols path to them in Visual Studio. I'm not sure if the feature is in VS2003 or not, however.