My company gave me a web application project and I went to debug it and set some breakpoints and they dont fire. I am using Response.Write all over the place to debug. Anyone know what maybe going on?
I am running the application off my localhost I was pushing F5, but since the breakpoints dont hit by making changes and adding Response.Write statements and clicking save then refreshing my browser I get the changes for whatever reason.
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Another tidbit is I created a new web application project and created a breakpoint and it works, its only specific to this application it seems like, but dont know what it could be?
Hovering over the breakpoint it says "The breakpoint will not currently be hit the source code differs from the original version"
Try this:
Close Visual Studio and make sure any instances of ASP.NET development server are closed as well
Delete everything from "C:\Windows\Microsoft.NET\Framework\v4.0.30319\Temporary ASP.NET Files" (where v4.0.30319 is the version of your .NET Framework)
Definitely need more info, but I would check that your are building with debugging symbols to cover the dumb stuff.
Okay, after reading the comments posted on your question I was making the following assumptions.
You are running using the built in VS development server
You are compiling in debug mode
You've set debugging true in your web.config
I've seen this problem before and for me it's been resolved by restarting Visual Studio.
Assuming that you are running on IIS on the same machine that you have visual studio installed:
Have you attached to the application pool process
Is you code the same as what is deploy? (Is the latest version deployed)
Are you logged in as administrator?
Are you running visual studio as administrator?
Just to make sure, you are running in debug mode?
I ran into this problem a while ago as well, instead of using response.write, you could try outputting the data to a label control's text value instead to see the values of your code.
It's a bit of a sloppy work around, but I couldn't figure out why that one particular project I was working on didn't let me debug it.
This problem is, for me, mostly caused by a mismatch of the loaded dll files (symbols) by webserver, and those that the project are pointing to when you try to breakpoint. It's different files. I have located different causes. One could be a simple hang-up by webdev instans (force shutdown. But also that there occur some kind of mismatch if you got different compilation methods between project within same solution as the web project.
This desc may not be your exact problem, but perhaps it will lead you into right direction. I find this often being a dirty unlogic error that just are irritating (but also completely fixable without data loss or reconfiguring, when u understand the trick).
I had the same problem, and it turned out only Internet Explorer works with debugging and breakpoints. To avoid having IE as my default browser, I changed the launch settings in the .Web project to run IE with the path as command line parameters.
Related
I have an puzzling problem. I have a new ASP.NET web application in VS2005 that runs fairly well, but I am having a problem and would like to set a break point to see what is going on. I have compiled the project in Debug mode. I have debug=true set in the web.config. But it appears that the IDE is not attaching to the process at all. Have I overlooked something? I am using the development server and not IIS. This has never been a problem in the past, but is this time.
Have I overlooked anything? Thanks for any help.
Rob
I had this issue a while back with VS2005. I don't remember where I got the following instructions from (copied them to a file which I'm now copying to you) but doing the following steps worked for me. It has something to do with IE8 attaching itself to multiple processes and messing up the debugger. Word of warning, this has you editing the registry, so use at your own risk / take all your normal precautions, etc.
Open RegEdit
Go to HKEY_LOCALMACHINE -> SOFTWARE -> Microsoft -> Internet
Explorer -> Main
Add a dword under this key called TabProcGrowth
Set TabProcGrowth to 0
If you run into the same problem on
Vista or newer, you will also need to
turn off protected mode.
Please note also that I was/am running XP at the time, so I did not have to use the "Vista or newer" clause there. No idea if that has any adverse effects either.
Sorry if I am stating the obvious, but you need to Start Debugging <F5> rather than just running the executable after compiling. Are you doing this?
If you don't hit the breakpoint, you are either not debugging (F5) or your code isn't reached at all. If you want to know which of the two is happening you can throw an exception right at the code where your breakpoint is. If your application is failing at the exception, you know you are not running it with the debugger. If it doesn't fail at the exception you are simply not reaching that piece of code and you will have to look harder for which code you are actually running.
throw new Exception("if I see this exception, I am not running the debugger");
Or maybe you are running two instances of the development server. I've had that sometimes. Look in the Windows system tray for the icon. If you see two (or more) you can right click to stop them and restart debugging.
I know that many people have had this problem... but I am now having it and cannot solve the issue. VS 2008 is randomly giving me an error after working on a project for weeks. When I set a debug point, I get a warning: The breakpoint will not currently be hit. No symbols have been loaded for this document.
I have re-built the solution with no debug points and re-tried. I have also tried to Load Symbols from path and that has not worked either... Can someone please help walk me through the necessary steps to getting my debug function working again.
Thanks.
Delete the solutions suo file. This has fixed weird debugging problems with breakpoints every time for me. Note, you will lose your solution settings, such as bookmarks, breakpoints, and such.
1) Does creating a new project work? If so, you have a corrupted settings somewhere. Moving your files over to your new project would be the easiest procedure to resolve your issue.
2) Does taking your solution to another PC work? If so, then you have an issue with your environment.
Try these checks in order:
1) Select your Configuration Manager, check if your CPU is "Any" or your "x86" or "x64" depending on your hardware.
2) Try remove all the other configuration other than Debug. Add a new Configuration based on your Debug and the CPU as Any
3) Drastic move.. close your visual studio and run the following
devenv /ResetSettings
4) Even more drastic move...
devenv /Setup
Good luck
There is a hotfix for Visual Studio SP1 regarding debugging issues here. It did fix issues I had with catching breakpoints in multithreaded source code. It also fixes other potential causes for breakpoints to be missed, so it is definitely worth a try.
Also, have a look at this SO question.
Regards.
I run into this occasionally and each time the solution is a bit different. This time I was using a different user profile to develop than I normally do in Visual Studio 2008 and found that I couldn't debug (breakpoints cannot be hit) shortly thereafter - on a solution with 2 vb.net projects. I ended up doing 2 things but I think the latter did the trick for me.
In the main projects properties, go to the Advanced Compile
Options button on the Compile tab and ensure the "Generate debug
info:" is set to Full.
Right-click on the main project and
select "Set as a startup project"
Working on an ASP.NET Project (not Web Site) and trying to Start without Debugging from Visual Studio.
First this:
alt text http://uploadimages.epiforge.com/Crash.png
Then this:
alt text http://uploadimages.epiforge.com/Burn.png
Once completely reinstalled Microsoft Visual Studio 2008 and it was fixed... for a while.
Looking for any information I can find, including:
What in the Hell is going on?
What way is there to fix it other than completely reinstalling VS2008?
How can it just be fixed permanently?
Try this - shouldn't take more than a minute or two.
Create a brand-spanking-new, empty Web Application Project. Enter something like "hello world" on the default.aspx page. Run it.
If your problem disappears, you've got something (3rd party DLL, etc) referenced in your project causing the issue.
Else, your looking at an OS, IDE or other environmental issue. I've had some odd VS issues in the past on Win7 that were solved by available updates. I still have to run VS as an administrator to use the "attach to process" for debugging.
update
So, the new project works, which tells us that the problem is somewhere in your old project. This is where the fun part starts, which is what I like to call "binary search debugging." It's crude, a pain in the ass, and if your app is pretty complex, sorting out dependencies can be a pain in the ass.
Create a new project and add all of your source to it.
Build, run. Did it work?
No? Remove half of the source.
Build. run. Did it work?
If so, the problem is in the half that you removed.
Else, it's in the half that remains.
Now, I know this is an incredibly naive approach to debugging, and its very brute-force, and some app configurations can make this damn near impossible, but at least its straightforward.
Any other service listening to the port number you're using? Try changing the port number or use IIS instead of running it on cassini.
I never had this problem before, but I reinstalled my computer recently and Visual Studio is not behaving well in debug for an ASP.NET site.
I am attaching visual studio 2008 to the w3wp process to debug a website. When I am debugging a method line by line with F10, sometimes visual studio will decide that it continues until it encounter a breakpoint... It's almost like if I pressed F5 to let it continue, but I press F10. For example if a method call is called more than once and there's a breakpoint at the beginning, while I am debugging line by line inside the method sometimes the execution will continue to the breakpoint at the beginning for no apparent reason so I lose all my debugging...
Anyone had this problem before?
Thanks,
I have the same problem, whenever I press step-into or step-over it continues to execution as if I pressed F5.
Debugging is working only if I put a break point on every line I wish to evaluate.
Is anyone else experiencing this besides me and the poster?
I've tried re-installing VS and everything but that didn't help.
Furthermore, debugging does work in some other projects, to be specific WinForms projects, and when I press step into on the webservice call and "attach", debugging still works as it should.
OK, Update...
I have found that my problem lies with Optimizations in compilation.
I had optimizations turned on in debug configuration.
Make sure you uncheck that for debug configuration on all your projects and their references.
Also try: http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
The patch for this issue is here: http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
KB957912 - Update for Visual Studio 2008 SP1 Debugging and Breakpoints
Cehck to make sure that your build mode is set to Debug not Release. In Release mode the optimizer is turned on and code can be rearranged or removed. Your breakpoints may make no sense from the perspective of the actual code.
You're probably debugging an assembly with an out of date PDB file, or perhaps the code has changed and wasn't recompiled.
In any case, it sounds like you have a mismatch somewhere between:
code
dll
pdb
(and as another guy noted, make sure you're building in Debug, not Release).
This almost sounds like the behaviour you get when debugging while having several threads or requests going on in parallell, alternatively if your method makes recursive calls. Are you sure this is not what happens?
I had the same issue after rebuilding my computer. After searching for answers, I found this thread. The solution for me was the hotfix found on MSDN, noted by a user in this thread.
http://code.msdn.microsoft.com/KB957912/Release/ProjectReleases.aspx?ReleaseId=1796
--Notable discussion--
MSDN does also have a great topic discussion, also noted by a user in this thread, with some workaround and a link to the patch.
social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193
I have seen a post where the following line of code was placed at the beginning of Page_Load(...) method. Personally this was not an option for me, but if you are comfortable with this being a fix for your problem and it works...
Response.Cache.SetCacheability(HttpCacheability.NoCache);
My setup:
- Windows XP pro
- Pentium 4 3.0GHz HyperThreaded
- VS 2008 Professional Edition
- .NET Framework 3.5 SP1
- SQL Server 2008
- Development language: c#
For me it started working only after cleaning and rebuilding the solution.
You aren't using multiple threads are you? That could cause this behaviour.
And do you have this problem in different projects, or just in a single project?
Line by line debugging is F11 (Step Into), not F10 (Step Over).
Step Over will skip debugging on any methods you call.
Alternative thought - have you tried using step into (F11) instead of step over (F10). If you're finding that method calls appear to be "skipped", it's possible that you're executing over the next line without actually stepping into it...
Make sure your line endings are consistent. Windows likes CR/LF. Sometimes it gets confused about what line it is on if they aren't consistent.
Workaround found here http://social.msdn.microsoft.com/Forums/en-US/vsdebug/thread/f3fcb4fb-8a08-4fa0-8d58-9ed6f3eb1193:
1) Open Visual Studio but do not open any projects.
2) Start the Task Manager (Ctrl+Shift+Esc) and navigate to the “Processes” tab.
3) Right-click on devenv.exe and select “Set Affinity…” (this option is only available on multi-processor or multi-core machines).
4) Uncheck every CPU except one and click OK.
5) Open your project and debug as normal.
Silverlight tools are not fixing the problem and the other patch provided in this forum thread either. This is the only working workaround I found yet.
Does any else have a problem where when using VS2005 or VS2008, it suddenly 'forgets' to color code and format the text for you? All of a sudden it acts like its a plain old notepad editor. Sometimes if I save and re-open the file, or else re-start Visual studio altogether, it suddenly 'remembers'. I thought maybe this was because of a bad install on my machine, but recently upgraded to a new one, brand new fresh install with all service packs - and we are right back to the erratic behaviour....
Is this a known problem? Is there a workaround (i.e. a key combo I can hit to tell it to do its thing?)
PS: This happens for me when doing asp.net with VB code - not sure if it affects other flavors of the tool...
EDIT: This is a clean install of VS2008 on Vista, but also have had it on XP. No addins on either setup, problem happens routinely.
Sometimes something similar to this happens to me in VB.Net. In my case it has alway been the backgroundcompiler service that has stopped working for one reason or another. Haven't found anything that helps besides restarting visual studio.
I got this often when working on large web projects (> 1K pages and 4K total files) and most often on ashx files.
At the same time, I would lose intellisense, This was happening because the files I was adding were not getting marked as "Compile" in the file properties -> build option.
I never found the cause (assumed it was overburdening the solution) but I found that it would stay fixed for longer if I deleted the SUO file periodically (it was getting into the 1MB range).
Since coming to a new company, new PC, etc, I have not had this problem but then again I'm not working on as large of a web project.
I use C# in VS2008, and haven't had any problems. Maybe this is VB.NET related?
I used to see the problem with "Web Sites". I have since changed most of my projects to "Web Applications" and haven't seen the issue in a while.
I had a similar issue with VS 2003. I use VS 2008 right now and this doesn't happen anymore.