I have a project that is auto generated. This project is referenced by my web app in visual studio. When i step through the code in debug mode the code from this project gets stepped into. Is there a way I can skip this code in debug mode.
I can't use System.Diagnostics.DebuggerStepThroughAttribute since the code will get replaced every time my datasource changes.
Thanks,
i think you should remove pdb files of the project which you don't want to debug.
A program database (PDB) file holds debugging and project state information that allows incremental linking of a Debug configuration of your program.
similar question/answer : Can you debug a .NET app with ONLY the source code of one file?
Related
We lost some source code, so I used Telerek's Just Decompile to decompile a dll and create a C# project in Visual Studio. I changed project that referenced the dll and instead referenced the new decompiled project that I added to the solution.
When I went to debug my project, I expected to be able to step into the decompiled code. Instead, it stepped over the line of code where I expected the debugging to step into.
I discovered that if I changed my Debug options and unchecked the "Debug Just My Code" setting and then selected Debug => Windows => Modules and loaded the debug symbols for the decompiled project, I could step into the code of the decompiled project but I did not have normal debugging capabilities such as the ability to display variables values much less the ability to change code and continue.
I expected to be able to debug the decompiled project as normal. I could try to create a brand new project and copy each code file, one at a time into it to see if I could reconstruct a brand new project manually, but this would be long and tedious.
Any thoughts on what do I have to do to my decompiled project to be able to create a project that I can debug as a normal project?
I'm debugging .Net Core in Visual Studio, and the breakpoints are working fine in the current file, but when a method from a different file is called, its breakpoints aren't being hit. I'm not familiar with Visual Studio because I usually debug in VS Code so I'm sort of lost.
I've googled it, but can't find any info - is it possible that VS ignores breakpoints in files other than the current one?
(It's ignoring the Debug.WriteLine I added as well but I just need to confirm if it's really not hitting breakpoints rather than not actually calling the method.)
Visual Studio ignores breakpoints in different file
If this issue is as phuclv's descroption, a net core project references a c++ Dynamic link library, you can follow the link, open the c++ project-->change it as mixed and then open net core project, choose Enable native code debugging. Also,
If you create the project in vs-code and then migrate it into VS2019,since vs-code is different from visual studio, you should try these steps:
1) delete the bin and obj folder first
2) make sure that these two options are checked under Tools-->Options-->Nuget Package Manager.
3) Try disabling Just My Code under Tools--> Options --> Debugging-->General
4) If the file is from the other project,please add reference to these projects by Right-click on the Dependencies-->Add Reference-->these projects or just copy these projects's dll and pdb files into the main project's output folder(Bin).
5) Use Debug mode to debug your project.
In addition, if these do not work, please try to create a new net core project in vs and migrate your old project into the new project to test whether this issue persists.
I have a VS 2010 solution with a web application project, and several class library projects to which the web app project has project references. When I am trying to debug the code for one of the class library projects through the F5 debug build process, the Modules window normally fails to load the symbols for the DLL in question, or if it does, the breakpoints are ignored anyway. However, on the second attempt at an F5 debug build, the breakpoints usually are recognized, and the code will halt in the required location.
I have tried ALL sorts to fix this issue - all the usual solution cleaning business, repeating the referencing procedure. I didn't see this issue until I upgraded to VS 2010, after which I rebuilt a new VS2010 solution from existing projects. I am beginning to think this is some sort of timing bug in 2010, as I am making no changes between the first and second attempt - it's as though VS 2010 is disregarding the dependendencies in the build configuration, and starting the web app build before the PDB for the class library is ready, or before it can locate the PDB for the class library.
Has anybody seen similar behaviour in VS2010? As you can imagine it is adding considerable amounts of 'productivity killing' time to my debugging, having to build everything 2 or 3 times just to get the breakpoints to be recognized.
Thanks if you can advise.
Try erasing the bin and obj folders between runs. does it help?
I have similar issues with a web server which does not get changes made to the configuration file on VS2010.
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.
I am using Visual Studio Professional 2010 and the Team Foundation Server Express (beta). My VS Project (C#.Net / WPF) has been migrated from VS 2008 (without TFS) to VS 2010 (with TFS).
Whenever I apply changes to my code and try to debug my application, I get messages like This breakpoint will not be hit. (in german: Der Haltepunkt wird momentan nicht erreicht. Der Quellcode weist Unterschiede zur Originalversion auf.) and the project is started using the old executable version (the one with the last successful build). No errors occure, the code is OK, but the changes are not applied either.
When I manually cleanup and rebuild my project, everything works quite fine - but there has to be a fix for this issue?
Edit: I just added a new project to my VS solution and checked it in on the TFS Server. Using this new project the problem does not occure. Even when I add the same dependencies I used in the project mentioned above, the debugging and building of the new project works fine without the errors mentioned above.
Maybe this information helps you to lead me to a solution.
It's not clear whether existing answers are not sufficient. I can't know exactly what's causing your problem; but, I can detail some places this potentially comes up.
The first area that I commonly see this is when a project references an assembly directly. You can create a project that creates an assembly. Another project might use that assembly and you can reference by assembly directly (and not add a reference to the "project"). This disconnects VS from really knowing it needs to "build" that referenced assembly first and it will sometimes get out of sync with the debugging symbols (PDB). You can tell if a project has been referenced or an assembly has been referenced in the properties of the reference (expand References in Solution Explorer, right-click a reference, and select Properties). A referenced project will not have a Specific Version property, while an assembly reference will. You can sometimes also tell from Project\Project Dependencies. If you have a reference to an assembly generated by another project but that project isn't a dependency in Project Dependencies, it might be an assembly reference. To fix this, you can usually just delete the reference and add a reference to the project.
I've also find that sometimes breakpoints confuses the debugger. If I have many breakpoints or they've been kicking around a long time, the debugger sometimes does some weird things. If I delete all the existing break points (Debug/Delete all breakpoints) and re-apply them the debugger is usually much happier.
You can find the answer here. The assemblies might be in GAC or a project or some projects need to be rebuild to generate the pdb files again, which are used for debugging. If you don't choose to rebuild it might use the old pdb files.
My guess is that you are putting breaking points somewhere your program can't access them.
Ex:
const int x = 5;
if(this.x == 1)
//do sth <--- breakpoint here
If you are running a mixed mode application (unmanaged native C++ & managed C#), make sure to set Enable unmanaged code debugging in your C# application's Properties window.
You have to rebuild, there isn't an easier way around it.
The program database files (PDB) need to be recreated. You should also have your configuration setting set to debug.
Also the first answer to this question must be of help as well.
This happened to me when I started VS as an admin, and it also happened to me when the project is set to a different architecture than a DLL that I used in this project.