Intermittently when I start debugging a web application VS hangs (not responding). It will start OK if I run the appllication without debugging. When it has happened once it will do it every time until I delete the vbporj.user file.
This problem appeared when I moved to Win7 64bit. I am using VS2008 Pro and everything is patched up to date. I am using the internal IIS7.
Updates for Visual Studio 2008 SP1 debugging and breakpoints at http://support.microsoft.com/kb/957912.
Try deleting the solution user options file (.suo) where the debug/breakpoint information is stored. You will lose all solution user settings, such as breakpoint locations. When you have "funny" debugging incidents, this is the first thing to try because this file is easily corrupted.
Clear all your Visual Studio "temporary" files. Check out the "Clear Recent" script at http://missico.spaces.live.com/blog/cns!7178D2C79BA0A7E3!370.entry.
Modify it for your own needs. For instance, I dislike Flash, so you may want to remove the call to ClearStupidFlash and the other non-Visual Studio calls.
Related
I have a ASP Project running Visual Studio 2013 having very bad Performance while debuging/running the Project. The same Project running on a normal IIS Server is super fast with no Problems. Other Projects are running also super fast with no Problems (also on VS2013).
I have already tryed the following:
Delete All Breakpoints does nothing.
Debug or Release version, doesn't matter.
start without Debugging has the same problem.
Putting my project on a full IIS implementation on a web server runs it super fast with no problems.
Clean Solution, or deleting the .suo also do nothing
comment all the CodeBehind and the JavaScript
the solution with symbol loading from Visual Studio debugging/loading very slow also dont work.
Another often mentioned solution is to deactivate Intellitrace, but I don't found how to do that in VS2013 (the Intellitrace MenuItem in the Tools/Options Menu is missing)
There are many empty ScriptDocuments created while running, dont know if that has anything to do with the Problem.
Thanks for any Ideas!
This may sound strange, I had the same problem and tried all suggestions I found on the internet. The cause for me was I has a blank DVD in my drive. I found this by looking at where Visual Studio was trying to load the symbols from "my d drive (dvd)". After I ejected the blank DVD it was back to normal. This was very strange but just saying, check where VS is trying to load the symbols from in the output window. Hope this save someone from running round in circles.
I have a problem debugging a web forms application that is configured to use IIS for debugging, under Windows 7 and Visual Studio 2010. An example has just occurred, where I make a change to the code behind for a web form, save, and apparently rebuild before starting the app using F5.
The app starts, and I get an error message trying to do something in the app. I tell the debugger to break when an exception is thrown and try my task again, only to be told
The source file is different from when the module was built.
where the module is C:\Windows\Microsoft.NET\Framework64\v2.0.50727\Temporary ASP.NET Files\root\9d7b45ca\11a98b19\assembly\dl3\5e6cf0b2\636409d4_dfeecb01\PerfixEMS_Admin.DLL
The physical folder for my test web site is set to the web application project's source folder, so I have always assumed that IIS will look in the bin folder for required assemblies, and these will be rebuilt as expected. Why is this not happening?
Cleaning the solution usually works for me.
Update
Given the high number (320) of projects I understand why Clean and Build won't work for you. You should however try it at least once to see if fixes things.
If it does fix your problem but doesn't last you'll need to do one of two things.
Clean just the one file
Delete the offending temp file. You probably won't be able to do this because with VS running since it may have a lock on the DLL. You may also have to stop IIS. You can use Process Explorer to look for the processes that have a lock.
Use a custom solution
Its unlikely that you're going to be modifing all 320 projects at the same time. Create a custom solution for just the projects you're working on. You'll still be able to step through any project you have the DLL and PDB for if you need to.
Which to do
Using a custom solution has its problems since you can no longer use project reference for projects not in your solution. This impacts your team's source control. You'll also have to make sure the DLL's and PDB's from outside your solution are in a stable location and you'll need a way to detect when thoes other projects have changes that you care about.
These problems can be overcome with a careful check-in process for Project changes and scripts that copy files and working with team members to figure out how to communicate changes.
On the other hand closing VS for every change or running Clean and build isn't really tennable either.
it may be a workaround, but I just need to see if it will work or not, then we may investigate more in the original case. but for now, try this:
1- publish this website to a different folder
2- open the newly published version from your preferred browser (ex: http://localhost/APP_NAME).
3- from VS, open "Debug" menu, choose "Attach to process..."
4- select the IIS worker process "w3wp.exe" and click "Attach".
(if you can't find it, make sure that the checkbox "show processes in all sessions" is checked)
5- start debugging your source code normally and let me know what happened, thanks.
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.
I'm going crazy and wasting a lot of time. I am running in DEBUG, checked the web.config to ensure debug=true is there, checked the code to ensure I am reaching it, cleared all temp files and pdb's. The only thing that works is to continually kill the solution, create a new solution and add all the projects again. I shouldn't have to do this every day.
If you're using Windows Vista, try launching Visual Studio as an Administrator. Even if you're already running as an Administrator on the machine, still right-click on Visual Studio and select "Run as Administrator."
Right-click the solution node in solution explorer end select Properties. Check the configuration settings in there.
If you are attaching to a process sometimes this can be caused by symbols not being loaded. If you see the code skip over your breakpoint hover over the breakpoint it will tell you if symbols were not loaded. If that is the case Here are several potential solutions to your problem.
Clear out all files in C:\Windows\Microsoft.NET\Framework\v2.0.50727\ASP.Net temp files.
Ensure you deployed the *.pdb files to the bin folder of your application.
The web process has not loaded your assemblies at the time you attach your debugger. Reset the process and wait a little longer before attaching to the process to give the process a chance to load your dll's.
Actually your visual Studio is not attaching your project with process WebDev.WebServer.EXE
Do the following Steps:
click on Debug Menu
Click on Attach to process WebDev.WebServer.EXE
Now your Debugging is enabled.
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.