I'm using visual studio 2012 in the first days when I want to stop application in IDE, application was still running on IIS Express, I could browse and work with running application, but now I can't. IIS Immediately shutting-down application if I press stop button. Since I remember I didn't make any changes in setting. How should I do that running same as first days.
I recently faced a similar situation when suddenly my IIS Express stopped right after I stopped debugging. This happened after I turned on "Enable Edit and Continue". So if you disable this you will see that IIS Express stays running even after debugging is stopped.
Right click your project > click Properties > select the 'Web' tab on the left > uncheck the Enable Edit and Continue checkbox.
In VS2010 and VS2012, the edit and continue option is disabled by default when creating a new web application project. In VS2013 it is turned on by default.
You can find this option on the Web tab in the web project’s properties window.
With “Enable Edit and Continue” on, the VS debugger starts your web application in IIS Express. When you stop debugging, IIS Express is closed too. With this behavior, you will see the IIS Express system tray shows up during debugging and gone after debugging. This behavior is the same as in VS2012 when the Enable Edit and Continue option is turned on.
If you don’t need "Edit and Continue" functionality during development and would like IIS Express to stay after a debugging session, you can simply turn the Enable Edit and Continue option off.
If you want to use "Edit and Continue" or you are developing an Asp.net 5 site (ASP.NET 5 projects don't have an Edit and Continue checkbox in project properties) you have to use the "Detech all" command to stop debugging.
The debugger will detach from the iis process without closing it.
Clearly "Edit and Continue" feature will not work until you start debugging again.
Instead of hitting the (X) STOP button, you can use the Detach all menu item in the Debug menu. The major difference is that the stop button will terminate any process that is currently being debugged, while Detach All will disconnect the debugger from the processes, but will not terminate them.
The normal IIS worker process would also be terminated, but since it used to be running as a service, it will also automatically start up again and thus you could continue to use it without having to restart the process through |> Debug or |> Start without debugging.
Screenshot for Reference
It seems like since the release of Visual Studio 2015 Update 2 the accepted solution no longer works.
The easiest solution I've found so far is to start the project by selecting "Start Without Debugging" from the Debug menu.
This is probably best categorized as another workaround, but it works for me.
I generally start the project for the first time with the "View in Browser" context menu (or CTRL-Shift-W).
From then on, anything that requires debugging, I usually attach to the new existing iisexpress process. While mousing thru context menues would make this a non-starter, it is nearly as quick as F5 with the following keystrokes:
Shift-F6 to build the current project or Ctrl-Shift-B to build the
entire solution (this is only required if you have made changes but I
thought I should mention it since F5 already does this).
Ctrl-Alt-P opens the attach to process dialog
typing "iis" will then bring you down to the iisexpress process
hit enter and you're attached
If you have more than one iisexpress running, the last one started will generally appear at the top of the list. Another option is to shift-select and attach to all of them.
This has a number of advantages IMO. First and foremost, it doesn't terminate the process. Second, the browser window isn't closed when you stop debugging. It cracks me up when I see a developer repeat 7 steps to get to reproducing a bug, when all he needs to do is hit F5 in an existing browser window to just repost once the debugger is connected. Last, I have to do this already when attaching to nunit, so I get a more consistent experience.
Related
Is it possible to simulate non-UserInteractive mode when debugging in Visual Studio, and if so, how?
I have a service that is running that I'd like to debug, but the behaviour is different depending on whether I'm debugging it or running the service.
I found this question:
How do I debug Windows services in Visual Studio?
The answer there doesn't quite do it for me because following that, when you debug it, the debugger runs the process in UserInteractive mode. What I want is the debugger to debug the process, but without UserInteractive mode.
For example, I had an error that was buried deep in the code because a library it uses was trying to display some sort of dialogue box (even though the dialogue box wasn't seen by the user). This would not be picked up in Debug because UserInteractive mode is used. I want to be able to do more debugging on these kinds of issues
To debug a service you would need to
Build your service in the Debug configuration
Install your service to see how to do this go to this link https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-install-and-uninstall-services
Start your service either from services control manager, server explorer or even from the code and if you want to know how to do this then go to this link https://learn.microsoft.com/en-us/dotnet/framework/windows-services/how-to-start-services
Start visual studio as admin so that you can attach to system processes.
Optional > on visual studio menu bar, choose Tools, Options. In the options dialog box choose debugging symbols and select microsoft symbol servers check box, and then choose the OK button
On the menu bar choose attach to process from the debug or tools menu for the short key press CTRL+ALT+P
The process dialog box appears
Then select the show process from all users check box
In the available process section, choose the process for your service and then choose attach
Hope this helps
I hate attaching to a process from Visual Studio. It works, but it also seems to take forever to build the list of processes to choose from. Perhaps that's because our systems are locked down too tightly. It's entirely possible that in a different environment, this works just fine.
Still, I find it much easier just to trigger a programmatic breakpoint when the service is starting and jump in to debugging at the beginning. To do this, call the following in the OnStart() callback:
System.Diagnostics.Debugger.Break();
When you start your service, you should get a prompt indicating an unhandled exception has occurred.
Click the Yes option, answer Yes to the UAC prompt, select which instance of Visual Studio you want to use, and then debug normally once Visual Studio starts.
When you're finished debugging, just stop the service, and the debugger will quit automatically. However, don't close that instance of Visual Studio. Make whatever changes you need to make the service, and rebuild it. Then when you restart the service and you get to the point of selecting the Visual Studio instance to use, it'll include your original debug instance in the list. It's much faster to jump back into that one than creating a new instance each time.
HTH
I am trying to host web services with IIS Express on my local machine. I can start debugging one time. Every time after that I get a dialog box with "Unable to Start Debugging" whenever I try to run the project. If I shut down VS 2012 then open back up it works one more time. I see the issue in this post.
I believe it has something to do with my password changing a few days ago. However, I can't find where my credentials are stored and I have no idea how to change this configuration. Please help!
UPDATE:
Turns out the same thing happens if I try to run a local console app. This means (I think) it is a VS setting somewhere. I was having to shut down VS and restart it every time. However, I did find that if I shut down these tasks and then debug it works:
Any ideas?
It appears from your screenshot that IIS Express is not shutting down when you stop debugging. This is actually a setting in Visual Studio called “Enable Edit and Continue”. When enabled, IISExpress will close when Debugging ends and if disabled IISExpress will remain open.
This setting is normally set on by default in Visual Studio 2013, but actually defaulted to off in versions prior, including 2012, which you state you're using. You probably want it ON.
To adjust globally:
Open Options dialog box by clicking Tools -> Options
Click Debugging -> Edit and Continue
Toggle "Enable Edit and Continue"
You can also turn adjust on a per project basis.
Open properties for web project
Click Web tab
Toggle Enable Edit and Continue" under Debugger at the bottom of this page
Further reading on MSDN here:
https://blogs.msdn.microsoft.com/webdev/2013/07/11/enable-edit-and-continue-debugging-option-is-now-on-by-default-for-new-web-applications-in-vs2013-preview/
First Check the Identity settings
Update your credentials in the "Identity" setting, under IIS/Application Pools.
if your password had recently changed, the "Identity" might still set to your old credentials.
OR
Reset Visual Studio Settings
reset visual studio settings and restart it again.
On the Tools menu, click Import and Export Settings.
On the Welcome to the Import and Export Settings Wizard page, click Reset all settings and then click Next.
If you want to save your current settings combination, click Yes, save my current settings, specify a file name, and then click Next.
—or—
If you want to delete your current settings combination, choose No, just reset settings, overwriting my current settings, and then click Next. This option does not delete default settings, which will still be available the next time you use the wizard.
In Which collection of settings do you want to reset to, select a settings collection from the list.
Click Finish.
OR Check Truely Reset VS
I am using VS2015 and have a C# / ASP.NET webforms project which is working well. However, now I am needing to add new syntax and test it, so I opened it and set a few breakpoints, but the code is not stopping on the breakpoints! I opened both webconfig and Webconfig and they both have debug=true I also tried to re-build my project from the build menu and this did not solve it either. So what else should I do to get debugging working?
EDIT
and yes I am set to debug configuration, see image
Make sure that in addition to setting debug in Web.config that you've selected the DEBUG configuration for the project in Visual Studio. Look for the dropdown box in the toolbar that has Release vs. Debug. If it wasn't in Debug, rebuild all after that and confirm you still have zero errors.
Then make sure you are attaching the debugger. If your web project is the default, then the little green arrow next to the debug/release dropdown will launch a web browser on your site and (critically) attach the debugger. As long as you keep that browser instance running, the debugger will stay attached and you'll hit breakpoints even when someone else and/or another browser hits your site.
Finally, be aware that without some special tricks, it is very hard to hit breakpoints in Global.asax:Application_OnStart because this code runs before the debugger has a chance to attach. You can add trace statements in there and then view them after the fact though.
Posting this since it seems to have been the answer
I usually see this happen when the IDE is running from an old copy of the assembly. For instance, if you had two branches of the same project open and built... sometimes your changes aren't caught as being changes so you end up running on an old build. I'd shut down every other instance of VS, clean the current instance then shut that instance down. Make sure IISExpress is also shut down (check the tray). Then start it back up and try again
Pls don't mark it as duplicate .. bcoz I have seen all the solutions but nothing is working for my case..
I have two machines devMachine and serverMachine
in devMachine I am developing application with Visual Studio and Now I have a simple Console Application..my need is I need to run this Console Application in serverMachine and debug from devMachine via Remote Debugging.
As told in Microsoft document, I have installed Remote Debugging tool in serverMachine and set the Authentication mode as Native (No Authentication) and run the Console Application in serverMachine.
Now , I have attached the remote process in devMachine's Visual Studio. All are working fine
But only problem is breakpoint is not hitting in Visual Studio
Note: I have placed required .pdb file in serverMachine and set that .pdb file path in devMachine's Visual Studio (Tools->Option->Debugging->Symbols).
Can anyone help me to resolve this issue?
What does the error message on the breakpoints say (if you hover over the breakpoint) - that it's different from the source? --> You can try disabling (from Tools/Options/Debugging) - Enable source file to exactly match the original version
What does the Modules window say - do the PDB's appear as loaded? if not, have you tried loading them manually (from the Modules window, right click the PDB and load)? - Is there an error message if it fails?
--> you might be in a case where the source files in the local machine are different from the ones on the remote one. Try copying everything over and see if that works (PDBs would be in the same folder as the EXE)
There are two reasons for the remote debugger to not hit the breakpoint
Wrong symbols.
Using the wrong .Net framework while debugging ( you can select on the "attach to process" window in visual studio).
Don't attach and just set remote debugging on. Copy all the project files to the identically placed and named folder in the server during post-build.
I had an issue with Visual Studio not breaking at my breakpoints although it looked like everything was setup correctly for the remote debugger on an IIS machine. I searched everywhere for an answer. The issue finally presented itself when I tried to manually attach the VS debug to a process (VS menu --> Debug --> Attach to process...) For some reason, there were multiple processes for the same application pool (there should only be one process, not sure where the others came from) I logged into my IIS server and killed all the processes for my application pool and then restarted the IIS application. When I saw there was only one process for the app pool (as I expected), I tried debugging in Visual Studio and it attached to the correct process. It turns out that when there were multiple processes for the same application pool, it attached to the "wrong" one.
Looking at your screen shot, could it be simply because the break points are in the "main" function which could already have finished before you can attach the debugger?
Suggestion:
Maybe put some artificial wait/delay code of say 20 secs in "main" above the first break point to give yourself enough time to attach to the process before "main" completes.
I have seen this option under the debug menu, but I don't completely understand what it means. Could somebody explain it to me? Thank you in advance.
When you Attach to a Process, you're causing the debugger to attach to the process and allow you to set breakpoints within code that you have not started from a debugger. This is very useful in the situation of trying to debug things that have an automatic spawning process (such as .NET code that runs under IIS).
Instead of pressing F5 to start an instance of your app (or pressing the green "go" button), you can attach the debugger to an already running program. While you /can/ attach to an instance of Notepad, since Notepad is not a .net application and you don't have the .pdb debugging symbols for notepad, it won't do much good.
To attach to an already running instance of your program (or an internet explorer instance that is running your code)...
compile non-optimized
compile "Full" debugging symbols (the
default for the DEBUG configuration)
make sure the .pdb file is in
the same directory as the .dll or .exe (or you can find them manually)
make sure the code is in the same path as when it was compiled (or
you have to find it manually)
I don't know what the official documentation says, but this is how I use it.
If you are working in a project that runs continuously, say a web site deployed in IIS or a windows service and you have the solution with the code of the running program open in VS, you can attach to the process and debug it as if you had launched it hitting F5, set breakpoints, etc. It also allows to attach to a process running in a remote machine if it is properly configured, which turns out to be useful if you are debugging a process in a staging server or something like that.
You just need to make sure that the code you are editing is the one used to compile the binary.
You can attach the debugger to a running process and start debugging it where its at. Mostly useful only if you have the debugging information for the executable.
I tend to use it if my program hits an exception and I'm not already debugging it. I can attach and then view the variables and call stack.
That means to attach a debugger (i.e visual studio's integrated debugger) to the process so you can pause it and inspect variables at runtime. This happens when you hit F5 automatically, or can be done manually using the debug menu.