I am running/debugging an asp.net mvc3 application from within Visual Studio 2010.
Anything static in nature is not called when I re-run the app from within Visual Studio.
(or even something simple like Application_Start())
Each time I want to run the webapp 'properly' I need to kill WebDev.WebServer40.EXE in the task manager before anything static is called again.
q1) Is this normal, and if Yes, why?
q2) If no, then I would expect the ASP.NET Development Server to be restarted each time I restart a debugging session. How can I turn this on?
UPDATE:
Recompiling sometimes causes Application_Start to be called, not always.
I've resorted to calling a batch file in the prebuild, eg
kill_WebServer40.bat
which contains
taskkill /F /IM WebDev.WebServer40.EXE
exit 0
If you embed those two commands directly into the pre-build textarea your compilation will fail if the WebServer isnt running already. This linked helped fix that.
Surprised this wasn't discussed more/previously - when developing an app, as if you have any static data/caches and you want to run the application 'clean' you would run into this issue.
Yes it's normal. It will restart if you touch the web.config or recompile. The development server continues to run the application in the background after you stop debugging.
You can stop the development server in the task tray by right clicking on the icon and choosing stop.
There isn't a way to force a application restart every time you hit debug. This would only be needed for the edge case where you are debugging application start up. Just hit rebuild before debugging and it will have the desired affect.
Related
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.
Using VS2008 on my local dev machine, when I run my asp.net Web Application project, it starts up a session of Asp.Net Development Server when I use F5 to run the app in debug mode. It all works fine and I can run my app for testing and such. Then, when I stop the running debugging instance of my app (by closing the IE window with the X close button, or by clicking the square Stop Debugging button in the VS IDE), the app stops and I return to the VS IDE, but it also closes down the Development Server session, and then, after I make a few edits to my code and want to run it again, it takes forever to launch up the Development Server again and serve up the first page of my very simple app.
Is it normal for the session of Asp.Net Development Server to completely shut down like this each time?
I only have 1 project in my solution, and it uses ADO.NET Typed DataSets and OLEDB adapters, and basic asp: controls in the aspx web form. Overall, it is a very small app.
I hate waiting 20-30 seconds each time I want to run my app just to see one tiny little code change.
I was also facing same problem, but in my case "Edit And Continue" setting was a culprit. Thanks for posting this.
If you don't need to debug every time, you can actually just open the URL outside of pressing F5 (press F5 once, copy the url, stop debugging, open it in a new browser). This way you can make any changes you want, recompile, and see it immediately. But as I said, it means you're not debugging. You don't always need to debug though.
A secondary option, is to run against IIS, and only attach to the process as needed.
I have seen this for a long time, and finally decided to put the question up here. I have some applications that I need to maintain that were written in Delphi 2007 for .NET (ASP.NET 2.0). Normally, the first time I run the application (using IIS) I get the classic "Unable to start debugging on the web server. Unable to attach to ASP.NET worker process" message. I simply press F9 (run) again, and it runs. Sometimes I have to try running several times before it will actually run.
I am running Windows 7 64-bit (and have seen the same effect on Vista 64-bit). I do have IIS configured for ASP.NET, and I do have the following code in my Web.config file.
<system.webServer>
<modules>
<add name="DbgConnect" type="Borland.DbkAsp.DbkConnModule,Borland.dbkasp,Version=10.5.0.0,
Culture=neutral, PublicKeyToken=b0524c541232aae7" preCondition="managedHandler" />
</modules>
<validation validateIntegratedModeConfiguration="false" />
</system.webServer>
The point is that I eventually can run the application in the debugger, sometimes even on the first try. Many times when I get the failure it happens about 15 seconds or so after I press Run, sometimes even after I've hit a page or two (or three) of the Web app. And, yes, when Delphi gets into this mode, I can simply run without debugging, and all is fine (unless I really want to debug). And, I can just keep on trying to run in the debugger and eventually it will just work.
It appears that Delphi's .NET debugger is somehow getting the idea that the application cannot run, and then gives up and stops the process (which as I've mentioned is sometimes clearly running).
I know of other developers who have also seen this behavior. My question is, does anyone know how to stop this annoying behavior?
I don't remember the exact error message, but I believe I've seen something at least similar to this in the past. All I did to fix it was run a "Repair" on the .NET 2.0 Framework (through Control Panel --> Add/Remove Programs). Then maybe restart your computer after that...
If you have this problem, you're going to continue to have this problem. However, here is a workaround.
Begin by running your project without debugging, and then attach to it once it is working. To do this, select Run | Run Without Debugging, or press Ctrl-Shift-F9.
Once your application is up and running, and you want to have the services of the debugger available, select Run | Attach to Process. From the Attach to Process dialog box, set the Debugger dropdown to CodeGear .NET Debugger. IIS will now appear in the Running Processes listbox. On my machine, it appears as w3wp.exe. Uncheck the Pause After Attach checkbox, and then click Attach. (After using the Attach to Process dialog box the first time, it will default to the .NET debugger and Pause after attach will not be checked.)
You are now running with the debugger enabled. If you hit a breakpoint, or encounter an exception, or select Run | Program Pause, the debugger will be loaded. If you want to disable the debugger without closing the application, select Run | Detach From Program.
Apparently, since the application is already running, whatever was giving up and giving the false error message is not involved.
On the plus size, there is a nice side effect of using this approach to debugging a Delphi for .NET application. Once you are runninng, and find a problem, you can pop into the debugger and see what's going on inside. If you find a problem to fix, detach from the proces, fix the problem, and re-compile. You can leave your application running in IIS.
Once the project has been re-compiled, the next page you hit in the application using IIS will cause the updated program to load. If you need the debugger again, simply attach to the IIS process. In other words, you an debug, fix, recompile, debug, fix, recompile,... without having to ever close the application in your browser.
This may seem like a silly question, but we are having an issue debugging IIS in a shared test environment and I'm hoping that someone out there can give us an answer.
We have a Windows Server 2003 that is running IIS 6 and sharepoint 2007. We are debugging locally on the server with visual studio 2008.
When someone attaches the debugger and steps through the code, we find that all users are affected. In essence the web server stops handling all requests from all users.
Our question is whether this is a typical situation and is to be expected? Or is there some configuration that we can change that would allow the one user's session to be debugged but leave the other's unaffected.
Kev's on the right track. You need to make sure that the project you want to debug separate from the others is in its own application pool. This will isolate it to its own process and allow that process to be stopped/debugged without affecting the other applications which can remain in a different pool.
Setup
Start -> Run -> inetmgr
Right Click on Application Pools
Click New -> Application Pool
Name the new pool
Right Click on the application you want to isolate
Click Properties
Click on the Home Directory tab
In the application pool drop-down list select your new pool
Click OK
If there are any requests queued in the old process, they may take a few minutes to terminate before all requests are being diverted to the new process.
Debugging
To figure out which instance of w3wp.exe you need to attach the debugger to:
Start -> Run -> cmd
Type iisapp
You may be prompted to register CScript, if so click yes and run it again
The only gotcha you may still find is that if multiple applications are using the aspnet_state service you may run into blocking issues if you need to debug that process as well.
Links
MSDN
Developer.com
"When someone attaches the debugger
and steps through the code, we find
that all users are affected. In
essence the web server stops handling
all requests from all users."
This is normal, once you attach a debugger to a process such as inetinfo.exe or w3wp.exe and set a break point, every request/thread will be blocked until you allow the debugger to continue, until the next break-point.
I've never found a way around it. Is there some reason you can't debug on each developer's workstation?
Set up a parallel project on the server and try using that. You could use debug.mydomain.com and then just use that for testing. The only reason that I personally can think of to debug on your live servers is if there is a significant difference in the functioning of your app due to either hardware or software configuration.
Ideally you want to have a separate server/instance of your system in as similar an environment as possible so that you don't have to debug on your live machine. Also you might want to consider writing all errors to the event log or at least checking the log since asp.net usually get logged there. This way you can see where your errors are and use that to help you solve your problem in the development environment.
I believe in visual studio you can set the debugger to break only the process being debugged, and not all the processes. Depending on how your system is set up, YMMV with this.
It can't be changed AFAIK. But that's a normal practice to set up separate web-node or web-application for development/debugging purposes. If that's necessary to know exact values of some vars in certain situations you can always use debug logging.
I am trying to debug some code in my ASP.NET web app.
I set a breakpoint in one of the page events of the page's codebehind, and this once came up with a special icon in place of the red breakpoint saying symbols have not been loaded and the breakpoint will not be hit.
This error has not repeated itself but why can't I hit the breakpoint?
Also, when I press stop, I get a popup in VS stating:
Stop Debugging In Progres...
Debugging is being stopped but is not yet complete. You can force debugging to stop completely, but any processes attached may terminate.
This window will automatically close when debugging has completely stopped.
Completely stop
I also don't get the website appear in my browser either when starting to debug. :(
To make things worse, I have a line of code like this in my page's codebehind:
RssFeedSites = opml.Parse(filestream);
I am putting the problematic breakpoint on this line. But I have a programatic breakpoint in the Parse() method of opml, but this does not get hit, either.
Thanks
Could you check if the dll is perhaps in the GAC? If it is it is probably an older version and the GAC has priority over local dll's. So if the dll is in the GAC visual studio is using that (older) version instead of the newly built one.
the debugging host could not find the correct pdb's to match your executable or the debugging host is failing.
Check your build, are your PDB's all up to date and in the correct directory to be found ?
Check the debugging host process if its having problem. If your using visual studio hosting process, then has the vshost.exe process somehow terminated prematurely ? If your remote debugging, check the remote debugger. Check your web server as well. If the debugging host process fails to respond, visual studio will be stuck when trying to debug.
I don't recall the specific reason for the message when I have seen it, but I always ignore it, because the symbols get loaded when the page is executed and it always hits the breakpoint assuming it's in the process flow of the page.
If you can't hit ANY debug points and you are running from local IIS, you will need to attach to the working process(w3wp.exe). Tools->Attach to Process.