Alright, I've been searching forever and can't find the answer to this.
So on my work computer I run Windows 7 and Visual Studio 2005. I have a ASP.NET project (2.0) and let's say I hit F5 and start debugging. Now, once a page is done rendering I can edit the content or the codebehind code of the page without it throwing any error messages (just like if the project was stopped). Then if I save the file and hit refresh on the current debugging browser, it'll take a minute to recompile the project automatically and then refresh with the recompiled code. I can ONLY change the code in the ASP.NET project, not any class libraries that the ASP.NET project is dependent upon. I can also set breakpoints and it'll hit them (so it's not like the debugger is not attached or something).
Now on my home computer, I run Windows 7 and Visual Studio 2010. I have an ASP.NET project (4.0) and let's say I hit F5 and start debugging. Now, it doesn't matter if the page it done rendering or not - I cannot change ANY of the code behind, although I can change the content. If I attempt to I get a message saying
"Changes are not allowed while code is running or if the option 'Break all processes when one process breaks' is disabled. The options can be enabled in Tools, Options, Debugging."
That being said, if I put a break point, refresh the page and hit the breakpoint THEN I can change the code and then hit F5 to continue.
So my question is - what EXACTLY do I need to do to get it to work like my work computer? It's REALLY annoying to have to stop the project or be clicking breakpoints all over to edit one little piece of code (especially when I'm so used to not having to do that at work). Is this some change in Visual Studio 2010 or something? From what I've read, how it's working at home is the real "Edit and Continue", but I can't figure out what to call it on how it works with my work pc.
Another difference (might be of help):
I set it up so that my IIS goes to the project folder, and then run the project outside of the debugger on both my work and home machines.
Now on my work machine I can make a change to the code and when I hit refresh on the non-debugged browser it'll do the same pause for recompile and then refresh the screen.
On my home machine if I make a change to the code and save it and then refresh the non-debugged browser it will not recompile the code.
So this makes me think it's some IIS setting in the end to make it auto-recompile? It clearly doesn't seem to have anything to do with VS since I'm not even going through the VS debugger to access to code at that point.
Just my thoughts: maybe you use on the work WebSite project, but at home WebApplication. In case of application all code will be compiled in the single DLL and changes should be recompiled first. In case of WebSite - each page compiles in different DLL and you can chage any of the page and it will recompile it.
Related
If I F5 to debug, and browse to my test site using Chrome, and execution halts before sending a response (e.g. we get an exception and I click Stop Debugging instead of continue to the end), that Chrome window and any child windows it spawns will no longer work with the project. It will say "Loading" with the spinner in the tab, the window will be empty, and it will stay like this apparently forever. Alternately, in a new tab, I type the URL and hit enter and it does not display any loading behaviour as though it isn't even trying to load it. This persists across tabs within the same window hierarchy.
My workaround is to create incognito windows in Chrome when testing local sites. If it gets into this error state, then I have to close the window and open a new incognito session from the original browser parent. If I accidentally cause this problem in the main window, I have to fully close Chrome to proceed. Using different Chrome profiles also works as I assume it's a different top level process.
Otherwise, it does seem to calm itself after quite a while - 5+ real life minutes or something similar it will revert and start working again and the page will load if it was still trying. But is there a better solution? This is VS 2022, debugging ASPX/C#, using a hosts file for local.site.com domains and separate http/https ports.
Edit: Image to show settings page
Your issue is rare, we need to troubleshoot step by step. First, please confirm that Tools==>Options==>Debugging==>General==>Enable Edit and Continue is enabled. Then you need to use detach all instead of stop debugging.
Well, if you hit a break-point in code behind, then code has haulted, and no more web pages can be dished out. (this is standard behavour when using the built-in web server that launches by hitting F5. if you close the web page, then the web server shuts down, debugging stop, and you back into Visual Studio.
You could try hitting ctrl-F5. That runs the VS site as non debug mode, and break-points etc. thus don't usually get hit. But, f5 STARTS a copy of IIS express web server. You close that web page, then debugging stop, IIS is then shut down. This is correct behavior's.
If you want to start testing the web site with say NOT having a debugger tied to the web site, then you probably are better off to install + run IIS full edition, and not the Express Edition that is "tied" to VS and the debugger.
So, the instant you close the browsesr, or even hit the "stop" button in VS, then IIS is shut down - it is stopped each time.
However, you could/can give ctrl-F5 a try - that will launch your site as non debug mode (and you not that no stop button is highlight).
IIS "express" is a great setup for f5, step code, debug code. However, the instant you want to start testing the site, and not having launched it from "inside" of VS? Then you probably should setup a VM with the full edition of IIS, or even I suppose install full edition of IIS on your computer (I not done that, since I have a few VM's, and I don't want to "mess up" my developer box with having a full pop full edition of IIS installed on my computer.
So, if you want "others" to test the site, then setup a VM with server 2019, or whatever, and then install IIS full edition. This THEN gives you the full GUI and setup features of a web server - which is a good learning experience.
So when using f5 to debug? yes, a halt in code will halt the ability of the web server to dish out other pages. In effect, IIS process one page at a time, and when the page life cycle is done, the the next page/request can be processed.
So, if you want "more" then this setup, then you probably need/want to get a full blown full edition of IIS up and running. And I suggest that should be placed on some other computer then your dev box, or at the very least in a VM on your dev box.
You "can" sort of get IIS Express edition to be launched and running outside of a VS debug session, but it is painfully, since you don't have the GUI and all of the web configuration tools that the full edition of IIS has.
I'm working on a fairly large ASP.NET web application and I'm taking a big productivity hit when I do work in the interface. I can zip through adding features to the database and API, then I hit the interface and having to recompile and run eats up a lot of my day.
For example if i'm working on a tricky bit that isn't behaving quite right and requires a number of tweaks I'll have to go through multiple [stop/tweak/build/run/log in/navigate back to page] cycles, which really kills my flow and has me staring at the screen with my finger hovering over the hackernews bookmark each time.
I've been fiddling with ways to get around this problem but I haven't improved my situation much. Here's what I've found so far:
visual studio will restart the app frequently when you change static files (js/css/etc), which shouldn't require a restart. If you run VS with IIS express instead this problem goes away.
If I know I have a bunch of messing around to do i'll cut/paste my code into a server script tag on the markup page, run the product, and tweak until it's good, then cut/paste it back. This is annoying because it often requires setting up a number of Imports page declarations and code editing features in ASP.NET files, while better than ever in VS2010, is not as good as in C# files. Plus, it still restarts the app occasionally once enough changes are made.
I can exclude the codebehind file from the web application project, change the "codebehind" attribute in the aspx page declaration to an "src" attribute, then edit the code from there while the app runs (until i make enough changes to trigger a restart.) However now intellisense doesn't work in the codebehind, among other things.
Am I missing something blindingly obvious here, or is development in ASP.NET web applications really supposed to be this slow? Thanks for any solutions you can offer.
I never run my applications through Visual Studio. Set yourself up with IIS and then configure a site to point to the location of your application along with a faux domain. Edit your hosts file to point the domain to localhost.
Then when you want to view your site, just visit the domain that you chose. If you need to modify CSS or script, just make your changes and refresh the page. If you make a code change, compile your app and then refresh the page.
If you need to actually use the Visual Studio debugger, then just attach to the IIS process (application pool name) and your breakpoints will get hit.
I've found a combination of techniques that brings my productivity up a fair bit.
Use an alternative browser like Chrome. When you stop the VS debugger and you're using IE, VS will shut down the browser, but it won't do it with Chrome (or Firefox, or anything else.)
Switched web.config to run in Windows Authentication mode and wrote a quick transparent login routine enclosed in conditional compilation tags (debug only, this feature is not perfect for our production product.)
Now when I'm getting into it I can stop the debugger (which no longer closes the browser,) make code changes, build, optionally start the debugger again, and just hit F5 in Chrome to load the latest. The refresh obviously takes longer since the app has to start up but there's no "run browser/log in/navigate back to the page" task anymore.
Hopefully this will help somebody else in a similar situation.
I have a project that has, amongst other things, one web application (mvc) and one WPF application. For the part that matters, the WPF app connect to a WCF service hosted on the website.
What I want to achieve is that when I press Ctrl+F5 (start WITHOUT debugging), the build process kicks in (if needed, in other words, the default VS behavior), the WPF app launched, and if the webdev server is not launched, that it get launched too, but without opening any page on my browser (I'll manage that myself).
I managed to get that working as I want (configuration below), but every time I do a Ctrl+F5, I get a popup from VS that says
Choosing to wait for a request from another process without enabling
ASP.NET debugging results in nothing to debug.
I value the information, and that seems to match pretty much what I'm trying to accomplish anyway, but now, instead of having to close a useless tab in my browser, I have to close a modal dialog. Not a big improvement from my point of view.
So, how do I prevent this popup to show up ?
Additional information:
I don't want to start in debug mode (F5). If I need debug for the website, I'll do my usual (attaching to the webdev server).
I want the webdev server to be running all the time from the first CTRL+F5.
I don't want to publish it on IIS (even the express version)
The solution startup option is set on "Multi startup project" with the WPF app on "Start" and the website on "Start without debugging" (setting it on Start doesn't change anything, except that I also get the popup when debugging with F5 directly).
The website has its start action configured on "Don't open a page. Wait for a request from an external application". The ASP.NET checkbox in the Debuggers is checked.
Internet had not been a big help so far, so all my hopes lies on you SOers !
Edit
It seems that it was flagged as a bug, but I don't see any reference in what version it's supposed to be fixed...
Also, I discovered my question is a duplicate of this one.
I actually found another way : in the start actions, you can set it to "start external program" and reference a self quitting program. I used "C:\Windows\System32\PING.EXE". Not perfect, but also less annoying than the previous solutions.
I have a C# code which I am running using VS 2005.
I have put up several breakpoints in the code. When I run the code in debug mode, none of my breakpoints are reached.
However the code runs successfully.
I tried putting breakpoints at basic Page_load.
I have already tried clearing my Temporary ASP.NET files in Windows folder, cleaning the solution, getting all the files again from the code repository. But it is still the same.
I found out that it has something to do with VS2005 and IE8. Both of them doesn't work well while debugging. I got this information from following link -
VS 2005 - IE8 issue
Eventually, I made some changes and now can debug through the code. Following are the steps I took -
Go to Debug --> Attach to Process...
Select aspnet_wp.exe process and click Attach.
Go to Control Panel --> Administrative Tools --> IIS
Go to your website/application start page.
Right click and hit browse.
After which the execution stops at all the breakpoint.
I know this is laborious procedure, but at least it is working after me having to deal with putting up alert boxes.
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.