In Eclipse, it's possible to "match" a zip archive (or a folder) containing sources to a compiled jar. This allows the debugger to do source-stepping on the associated sources with relatively low ceremony.
I'd like to do something similar in Visual Studio, given a dll, its associated pdb and the source code in some form.
The problem I'm trying to fix is that I'm creating a tools library that is delivered to QA in binary form and used in different projects (made of automatically generated code, FWIW). The QA engineers then need to be able to do source stepping inside the library method calls.
A related problem is, the QA engineer can't use "Go to definition" on a library method in the VS editor while not debugging.
For problem #1, the QA engineer currently needs to get the appropriate sources from the SVN server and manually specify their location to the debugger.
From what I can tell, in Visual Studio (and other debuggers) the traditional way is to use a symbol server which would provide both the pdbs and the sources, having only the library dll as input.
I know about SymbolSource.org - it uses 'NuGet symbol packages' (which I currently generate) but management won't agree to host off-site. I had a feeble attempt to set up their free source server offering locally, without much success.
So... is there an easier way (a la Eclipse)?
Related
I have a C# project in which I have a COM Reference. It compiles fine when opened in VS 2013. But, it fails as part of TFS build definition.
TFS version : 2013
TFS Build Controller & Agent : 2013
VS version : 2013
The failure message says that it could not find the Interop dll. I cannot manually create the Interop dll and check-in into TFS because it would keep changing and I want my C# project to always take the udpated COM reference.
I tried the COMFileReference suggestion but it did not solve my issue. I even manually registered the COM dll using regsvr32 but still I am facing the issue.
Any help is highly appreciated.
Regards,
kvk1985
A COM reference is the safest way to ensure that your program matches the actual installed component when you test your code. The compiler will read the type library of the component, a very similar mechanism that's used for normal .NET assembly references. Except that the type definitions come from the type library instead of .NET metadata.
But has a disadvantage in your case, it can only work when the component is actually installed on the machine. That probably did not happen on that build server. That's fairly normal, the people that maintain build servers don't particularly like anybody messing with it. And it is a maintenance headache, the build breaks when the devs update their machine with the latest version but forget to update the build server as well. And old builds get to be hard to reproduce.
So installing the component on the build server is the Quick Fix. If that's an insurmountable obstacle then somebody needs to run Tlbimp.exe on their machine. That generates the interop assembly, it needs to be checked-in to source control. And the project must be modified, remove the COM reference and add the reference to the generated interop library. It will now build the same way on the build server and the dev machines.
That's of course brittle the other way, if a dev updates the component on his machine then there will be a mismatch with the interop assembly. That can be a very ugly one, an E_NOINTERFACE runtime error if the COM vendor did it right, something excessively nasty like calling the wrong method, a stack imbalance or an AVE if he didn't. Otherwise the exact same kind of failures that can occur if the user's machine doesn't have the right version of the component installed. Standard DLL Hell.
You'll have to make the call yourself, there's no One Right Answer.
Just maybe trivial, maybe stupid question.
I have two solutions:
1) The main app
2) The sets of libraries
The first solution is accessible via the SourceSafe with the dll files(from the 2 solution) placed in its lib directory.
In order to debug the main app with the ability to jump to the source code of the libraries from the 2 solution Do i have to add the projects from 2 to 1? And Is it the only one option?
Even if I added (if it is possible to add with omitting certain projects in the SC) projects from 2 to 1 solution, I would have to change dll references in the app which is controlled via SourceSafe and I would mess it up for my colleagues.
What Can I do?
To debug all you need is that all third-party dlls have their corresponding pdb in the same directory. When you step into a third-party function for which you have pdb, Visual Studio will prompt you for the source, At this time you may browse to a local or network share where you have a the third-party source.
The place I used to work for used .NET Reflector to step through external DLLs. It's a Visual Studio add-on that uses reflection to allow you to debug through the source code of .NET binaries (actually their MSIL reversed equivalents) and is pretty simple and efficient when it comes to non-obfuscated code.
First let me say that I can remote debug a release build on the remote computer. I set up my release build much like my debug build but I mostly had to make sure the Debug flag was not set. I've dealt with doing this for a while and finally decided to try and figure out why I had to go through this. I should also mention that my remote debugging experience is limited to this project and the C# program uses a C++/CLI (built with /clr) .DLL to mediate to some critical C++ libs. I don't need to debug the underlying C++ libs but I do need to debug the C++/CLI code. (One reason I mention this is I can't link libs in statically while using the /clr flag).
I recently discovered Dependency Walker so I used it to see what was going on. Turns out with the debug flag set, the linker links in MSVCR100D.DLL and MSVCP100D.DLL, when the flag isn't set it uses the files without the "D" suffix. Now normally I might just copy over my versions of those .DLLs to the remote machine but there's a problem. My dev laptop with VS2010 is a 64 bit machine and the target machine is 32 bit. That means the only versions of those DLLs I own are 64 bit. I have installed the remote debugging for VS2010 (I had this same problem under 2008) on the remote machine but it doesn't include the debug versions of these .DLLs either (I'm not sure why but I'm assuming this is by design). So my questions are:
As a registered owner of VS2010 is there a valid source for 32 bit versions of these .DLLs I can put on the remote machine?
Is there a simpler way for me to get Debug support? That is can I change some other setting that just tells VS to not use the debug version of those two DLLs? The advantage here is the DEBUG symbol would be set and any conditional code using it would work.
The debug versions of the CRT DLLs are all available with the standard Visual Studio installation, including the x86 versions even on 64-bit machines.
By default, they're located in the following path:
<Program Files folder>\Microsoft Visual Studio 10.0\VC\redist\Debug_NonRedist
Under that folder, you'll find two additional folders (x64 and x86) that contain the debugging versions of these DLLs for the respective platforms.
But pay special attention to the name of the folder (Debug_NonRedist). That indicates that these debug DLLs are not redistributable. It's certainly OK for a developer who owns a license for VS to use them when testing his/her code on another machine, but they should not be distributed to client machines and used to run your application. (Sounds like from your question that you know this, but it's worth pointing out anyway for future Googlers.)
Alternatively, you can change which version of the CRT DLLs that a Visual Studio project links to for specific project configurations. That means that you can compile a "Debug" version of your application, but tell Visual Studio to link to the full redistributable versions of the CRT.
To do that:
Right-click on your project in the Solution Explorer and select "Properties".
Ensure that the "Debug" configuration is selected in the drop-down box at the top of the dialog.
Expand the "C/C++" item in the TreeView, and select "Code Generation".
Change the setting of the "Runtime Library" option to either "Multi-threaded DLL (/MD)" or "Multi-threaded (/MT)".
Notice here that you're just telling Visual Studio not to use the "Debug" variants of each of these options. They still mean the same thing. The first will dynamically link to a DLL, the second will statically link the CRT into your application. Pick the one most appropriate for your case. (I often find it convenient to configure my "Debug" builds to statically link exactly for instances like this.)
This question is for an older version of Visual Studio, but in case anyone comes here for a newer version (as I did), there is built-in support to deploy the debug DLLs that you need in VS 2013 (perhaps earlier). This is an obvious setting, but it can be easy to miss if one is rushing through things (as I was). So maybe this will help somebody.
In the property pages, under Debugging, when Debugger to launch is set to Remote Windows Debugger, in the property list, there is an option called Deploy Visual C++ Debug Runtime Libraries. Simply set that to Yes.
Update -- as requested, this is to clarify which property pages I'm referring to, by way of how to access them: In Solution Explorer, right click the startup project (the one in bold), and click Properties on the context menu. The Property Pages window appears. In the panel on the left side, expand Configuration Properties, and then select Debugging, the second item under Configuration Properties.
Edit to the Update: I got here via notification, and did not see that I could have just said, "See Cody Gray's answer for a picture of the window," to meet the request for clarification. But, there's the how-to anyway in case anyone needs it.
Within a Visual Studio (2005/2008) Project I'd like to use an open source library. I'd like to link to the binaries so that I'm not responsible for a proper build and can check those binaries into the source control server (SVN).
So far so good, but if I'd like to debug into the open source library or want to take a look at a class implementation I would be forced to add the the source of the project into my solution and than link my project to the source instead of the binaries.
Is it possible to tell Visual Studio a location of the source of a linked binary library so that things like "go to definition" and debug is working?
Absolutely, if you have the pdb symbols its all done for you - look at MFC for example, you get the binaries yet can debug through the source.
If you don't have the symbols, then its a lot more complicated, when you debug through the code it may ask you to show it the source lines, and you'll just have to find them for it (usually the path is the same so its easy).
There are multiple ways you can achieve this.
Like gbjbaanb suggested you can use pdb symbols. It's going to work for both managed an unmanaged code.
If you're using .NET you can debug with Reflector. Oran Dennison wrote how to debug with Reflector and Visual Studio. One of my favorite tools is TestDriven.NET. Author of this tool, Jamie Cansale, also blogged about how to debug with Reflector when you have TestDriven.NET. In his article, Jamie has a link to screencast where he demonstrates how to do it step by step.
Last, if you use for your SVN client like TortoiseSVN, you can add files/directories from check in. More details how to Ignore Files and Directories with TortoiseSVN.
I am trying to configure our in house development code as a symbol server, with source control file access when debugging in Visual Studio 2008. We can use this on other projects that reference our core set of libraries.
Sadly, we use SourceGear Vault for our SCM system, which is currently unsupported when it comes to indexing our .PDB files with their source control references.
I wouldn't really need direct source control access, I'd be happy with just a network share access but I can't see how to update the references in the PDB files.
I have the symbol server configured and have added what would seem the right references to the original build source code, however, when I debug in Visual Studio and try and step into the code referenced, it does not load the PDBs from the source server and consequently no source code is available.
Also, where Visual Studio can download the core .NET PDB files via the Load Symbols command, I do not have that option when I click the module.
Does anyone have any personal experience of setting this sort of thing up?
Many thanks if anyone can help.
This issue has kind of been resolved at this other related question.
Source indexing was missing from the overall process so the PDB symbol server should work properly now.