I use a 3rd party DLL in my VB.NET project (VS2005) that responds to slow and give wrong values in debug mode. In run-time mode everything works as expected.
I do understand that there are something going on in the debug mode which makes the DLL communication slow. This behavior makes it hard to debug the application correctly.
Is there any way to force VS to communicate with the DLL in "run-time" mode during debugging but let the rest of the project be in control of the debugger?
I found a setting that resolved my issue:
Project Properties > Debug > Enable Debuggers > select "Enable unmanaged code debugging".
Now the DLL communication flowed smoothly. The DLL I use is a middleware between my app and a USB device. There is no Debug/Release version of the DLL.
Change the debug DLL for the release one, either by switching files or by telling the linker/build process to only use the release one, but like the comment above I'd suspect there's some funky stuff going on in both.
Related
When I run my program with Visual Studio in debug mode I get a real slow down compared to release mode. I know that debug mode unoptimize code and especialy the one from Standard Library which I don't care about. However I really need to be able to debug an unoptimize code when I wrote it. Is there any way to keep Visual in debug mode with my code fully unoptimized while everything from the Standard Library is optimized ?
Cheers
Victor
My understanding is that you could change the project property for you project or referenced project like optimization or un-optimize if you have the project source code or you can re-compile it. Of course, if we enable the optimization for one project or reference project, it would impact some debugging feature more or less:
https://msdn.microsoft.com/en-us/library/606cbtzs.aspx?f=255&MSPPError=-2147217396
I am using VS 2010 professional [64bit - Windows 7] and in my solutions, i have 3 class library project and 1 wcf service projects are there. All these dll's are refereneced in my WPF applications. For the last 1 year, it was working fine and i was able to debug the all the referenced projects. But from yesterday itself, debug is not working all of a sudden.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
When I checked in the Debug --> Windows ---> Modules window, all those projects dlls are not seen there and says no pdb files are available ???
But in the WPF bin\Debug folder, i have all the referenced dlls and their pdb are ther.
What could be the problem ?
Even I am not able to debugg the wpf project as well. For getting break point or debug, each time i have to clean the solution or project then rebuild it again. Then i will be able to debug the WPF project.
In the case of referenced dlls, I removed the dlls and added the new compiled dll again and copied that pdb files to the wpf project exe folder. Still no use !!!!
I have changed the options in the Debug and Options [disabling and enabling the Just my code options etc]. But still it is not working.
This is not only my problem. One of my colleague also have this problem we took the whole latest solution code from TFS. SO I changed the Local code path to a new folder and took the latest code from TFS again. Still the problem exists !!
I am able to run the application. But debug is not working. In the WPF project, all those dlls are referenced properly.
Can anyone help us ???
I guess I don't have enough points to comment to ask specifics, so this may or may not solve your problem but I'll take a crack at it. Also, there appear to be other questions about this. So I would check those out first to see if they will help.
This question was solved by adding configuration to tell the program which version of the framework to use during debugging.
Why doesn't VS2010 debugger stop at my breakpoints?
Why does Visual Studio 2008 skip over my break points?
If those don't help, I'll give it a go.
When I put a break point on a class in the wcf project, it says breakpoints cannot hit as the source file is different from....etc.
This sounds like it could be one of the following issues:
Remote debugging and Visual Studio does not know where to load the symbols from or they are out-of-date
Need to clean and rebuild (which you seem to be doing)
The server you are running your WCF service on is not getting the updated DLLs and PDB files. If it's IIS Express, try killing the process between builds.
Also, make sure you are building in Debug mode and not Release mode. While building Release mode will generate the PDB files if it's set to do so which will allow you to debug an application, the code may be optimized as well which can cause breakpoints to be missed.
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.
I use a third-party dll in my application developed in Visual Studio 2010 and C#. When I debug my application by clicking the "Run (Debug)" button in Visual Studio 2010, that dll can detect and know that I am in so-called "development mode".
When I go the bin/debug folder and double click my application's exe file, the dll doesn't complain.
How can I configure so when I run the application in "development mode", the dll still thinks that it is executed in normal mode?
It's probably checking Debugger.IsAttached.
Solution: Don't use the debugger.
Real solution: Buy the library.
Depending on what the library does, it may be possible to separate out your application into separate components, one of which uses the library and does not run in debug mode. This will allow you to debug your application while still using the library.
Pro: What you are trying to do is definitely in violation of the license. This solution might not be in violation of the license.
Con: This will make it impossible for you to debug your use of the library. All it accomplishes is to allow you to debug the rest of your application by separating off the library usage.
Con 2: This will probably makes your application more difficult to maintain. It may also impact performance.
One of the awesome things I remember in Visual Basic 6 from years ago that you could just load up an ActiveX exe project into the IDE, set a breakpoint, press Run and whenever someone (either an EXE or a project in a different IDE) called that DLL, your breakpoint would hit.
Is something like this possible with Visual Studio 2008? Can I load up a WinForms project into one IDE and a Class Library project into another IDE and have the WinForms project call the Class Library project?
In VS you cannot attach two debuggers to the same process (it is possible to attach VS and WinDbg to the same process, but not in the default manner).
Point is, you don't have to use two debuggers or include the auxiliary project in your solution. Immediately after the dll load you'd be able to step through it and set breakpoints in it as if this was the solution you just compiled - all you need is the dll's debug symbols (pdb). Typically the dll load time is at process launch - but if it is loaded dynamically you might want to break immediately after the LoadLibrary call and only then set breakpoints in the dll. You can set the breakpoints in advance, but you'd still have to break somewhere after the dll load to enable the breakpoints to be translated into instruction addresses.
[Edit:] This does (I hope) answer the question as you put it, but it would not reproduce the VB experience you describe. AFAIK there is no way to set breakpoints in a library that would be applied to every process that loads that library. The closest I can think of is for you to set a MessageBox displaying the process ID in the library initialization routine (essentially DllMain), then manually attach a debugger to that process and set breakpoints as desired.
You can:
1) Add the project with the DLL to the solution with the EXE (this not quite what you're asking).
2) You can attach the IDE with the DLL project to the process running the EXE from Debug -> Attach to process. I never tried to attach two debuggers to the same process at the same time though.