Ever since I added Common Language Runtime Support (/clr) for my project I
have been having so much trouble getting information from the code I am
debugging in C++. I had to enable this support so that I could load a
.NET *dll in the C++ code for my project. I am not sure why this is
happening, but I need to be able to indentify what is causing this.
The way I debug is that I attach to a java process that loads my C++ code which
is in a dll. A *pdb file for that *dll is in the same directory where the *dll is
loaded from.
I keep getting this 'undefined value' for various primitive types I could easilly
view before. Is there some easy tutorial on how to get debugging information correctly
loaded onto visual studio 2010.
Related
Suppose that I compiled a dynamic library (Windows DLL and/or Linux shared object file, .so) in debug mode for use by a client application that links to it dynamically. My source code is available to the client application developer.
I need some clarification regarding the following debugging scenario. I've always understood/assumed that in order for the client application to debug into my library
(for e.g. in order for a client application developer to step into my source code while debugging, say using F10 in MS VC++), that they would have to have actually built a local copy of my libraries themselves (with access to my source code), or atleast have local access to my source code without having built it (not sure if that would suffice?).
Am I right on this? In other words, I think it is not merely enough to provide libraries with debugging symbols (PDB files in MS VC++) if the client application is linking dynamically to my application which has itself been built dynamically. Appreciate if anyone can help sort this out for me? How about the situation in Linux? My understanding again is the same as the above. Now if I had compiled a static library (Windows LIB and/or Linux library .a); my understanding is that the they then don't need to have a locally build copy of my source code (I haven't tried this one out yet)?
Is/are my premise(s) correct? If not, can someone kindly provide some detailed explanation preferably with an example? Thanks for your input.
As requested, here's my comment as an answer. Since it only addresses the Windows side of things, anybody who has the Linux (or Mac!) part of the answer is free to edit it in (I've marked this as a community wiki answer).
For VC++, the debug build DLL + matching PDB + matching source is all you need. The hard part is getting them all to match ;-)
Also, it works more smoothly if the source files are at the same path as when the DLL was compiled, but Visual Studio is also perfectly capable of prompting you to browse to the source manually if you have it.
I have more experience with Windows than linux. But I would think the concept is similar.
if the client application is linking dynamically to my application which has itself been built dynamically.
I'm not quite sure if I understand "building dynamically". You might be confused with the dynamic aspect of dll? dll is linked at runtime (not build time) to allow a part of component to be deployed without a full app. For example, an app on Windows that rely on a dll provided by the OS are not impacted when Windows updates that dll as long as the interface is maintained. The only difference between a dll and exe is that dll's entry function is dllmain as opposed to main in exe.
(The only "dynamic build" concept I can think of is building templated classes. But I don't think that's what you mean here.)
Hence, debugging a .dll isn't different from debugging a .exe, it's just that .dll is a separate binary file from the executable. All the source code provide is allowing debugger to align the stepping with lines in source code. When source code is not available, then debugger can still step through assembly code with symbols.
When situation doesn't allow, then developers who are good at reading assembly code can do debugging with only symbols and no source code.
You can usually build a binary with optimized option, then compiler might optimize the assembly code so much that source code alignment in the debugger might not be possible. This usually happens with released code. In those cases when you step through the code, you sometimes see the line or condition jumps that are seemingly different from what you would expect. There is the same on .exe, .exe with libs, or .dll. This is probably why you thought it is always necessary to build your own binary to debug dlls?
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 am a Java programmer and have come across a very nasty situation. For POC purposes, I need to write down a small segment of my solution that will run as a standalone application doing something very specific.
I have 2 questions:-
I can write the code, but what I don't know is how do I create an installer and exe out of that C++ code.
Secondly, I need to parse a sqlite db file and show its data in the application. Is there a sqlite windows dll or some C++ library or something that I can use, instead of asking the user to install sqlite (or doing it myself through the installer)? So basically, I don't want an extra program to be pushed in, just a dll or some C++ library..
Please let me know if you have an answer to either or both the issues that I'm facing.
Thanks
Compiling your code will turn it in to an executable. For distribution, you'll want to build it in Release mode. I'm not sure what version of Visual Studio you are using, but you might have a "Setup and Deployment" Project type which will enable you to create an installer. Failing that, you may have to look at InstallShield or a tool like that to ensure that the installer has all necessary files (such as the runtime libraries).
SQLLite is called light for a reason! The source code for it can be incorporated directly in to your project and compiled alongside the rest of the files (see: http://www.sqlite.org/selfcontained.html ). This means no external libraries are necessary to link against, and no extra DLLs need to be redistributed alongside your executable.
I have a pretty annoying compiling problem.
I am trying to do a System.loadlibrary on a C++ DLL in VS2010, which in turns uses a C DLL compiled in VS2008.
The error I am getting is:
java.lang.UnsatisfiedLinkError: The application has failed to start because
its side-by-side configuration is incorrect
This occurs whenever my C++ DLL tries to do a call to a function in the C DLL. Both compiles just fine, and both are in a folder accessible by Java Applet.
Is this possible to solve somehow? Do you need any more info?
You should try and use the dependency walker on your DLLs.
From the side-by-side error I assume that one of the c runtime redist packages or one of the noredist packages is missing.
But the dep walker should show you this.
If this does not help you can get some more information from the event log of Windows since side by side errors are logged there, or you need to use sxstrace for more info.
Have you installed the runtimes of VC2010 and VC2008?
Additionally you have to make sure the manifests of both DLLs are correctly configured so that the correct version of the used library can be loaded.
See also: http://msdn.microsoft.com/en-us/library/ms235342.aspx
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.