STOP Debugging and Start Running in Visual Studio

[@shagrat1988]

I totally agree. Most of the time I use F5, but I think that's a habit for me because you're always thinking "Hey if there must be a bug, I will fix it by using breakpoint without stopping the application", but now I realize that I'm losing the time. Thank you!

[@Ardalis]

You're welcome!

[@vyrp]

I have been using Ctrl+F5 by default for a long time. I use F5 when I have a specific need, like breakpoints, break on exception, Diagnostics View, etc.

[@Ardalis]

Same!

[@cristirusanu]

I use CTRL+F5 and, if I notice that the result is not what I expect, I go back to Visual Studio, I click CTRL+ALT+P to attach the debugger to the browser session, then set up a breakpoint and reload the page or re-perform the action that leads to the breakpoint. But I guess most of the people just click F5 from start because, in case there's something wrong, they can put a breakpoint later and refresh the page to hit it.

[@Ardalis]

Yeah, fair enough, but you're paying a big perf penalty every time when needing to debug should be pretty rare...

[@codecomposer88]

Agreed. I'm guilty of using debug mode all the time, purely out of old habit. But I completely agree, it doesn't make any sense to run in debug mode if you are in fact not debugging. As for naming, keep it simple: "run" for run and "debug" for debug. Also naming it "run" to match the CLI is a good point. And "run", should definitely be the default F5 behavior.

[@Ardalis]

Yep. Run and Debug. I think it’s probably too much of a change to expect F5 functionality to change. But changing the menu is a step in the right direction.

[@alfflasymphonyx]

This can help a little: Right click Toolbar Select Customsize In the Customize dialog, seelct Commands tab Then choose Toolbar radiobutton And select Standard in the dropdown In the preview, select the icon/item you wish to midify Click on Modify Selection In the Modify Selection dialog, you can change the Name and the Style (Image and text) This will however not change the tooltip. It also does not work for the button "start debugging". At least you can rename, Debug to Run

[@Ardalis]

The intent is to help folks who are new to the tool to better understand the implications of the different options. I don't think giving them these instructions is likely to be the most helpful way to communicate that to new users.

[@alfflasymphonyx]

@@Ardalis Hi, My intent the same as yours: trying to help. If they can rename at least one button to Run, this surely would help. The toolbar would show, Debug and Run as two separate buttons. I understand it is a bit tricky to rename the button, but I'm only using the tools Visual Studio offers for now until a new version comes along with potentially the two buttons renamed as you suggested. It is merely a temporarily fix... as long as devs @ Microsoft aggree to change the buttons.

[@pazzuto]

I leaned about ctrl+f5 pretty quickly in my days programming Windows Forms. The same with "build current project" instead of building the whole solution for a quick change. First thing I do on fresh installs, is reassign shortcuts and mod the toolbar. :)

[@Ardalis]

Yep! Definitely speeds up that inner loop...

[@waelouf]

Normally I use run (ctrl + F5), and when I need to debug I add a breakpoint and attach to process, rarely use debug outside debugging tests

[@Ardalis]

Same!

[@JeffryGonzalezHt]

The F5 thing is like stuck in so many people's muscle memory! Ctrl+F5 for stateless apps also means you can ALT-TAB back to the code, make changes, then relaunch much easier than stopping the debugger, editing, relaunching. (ignoring any possible live-reload and it's attendant frustrations!) Great stuff.

[@Ardalis]

Good tip!

[@pdurchev]

Once you get used to just running without debugging it's very noticeable how much slower the project starts when you need to debug. It's very hard to change other people's habits though 😊

[@Ardalis]

Very true!

[@SageMadHatter]

Depends on what sort of work you do. Web world makes sense, but not for other fields.

[@Ardalis]

Good point; for WinForms, WPF, etc. it may be fine to start with debugging most of the time.

[@nickpolyderopoulos3491]

At work what I usually do is that I have setup a local IIS for the web services because I rarely (if ever) change them and made powershell scripts to run the api(s) that I want to run. I did that mostly because Visual Studio has become a performance hog on my machine to a point where one time it had 10gb of RAM. That being said I have used both Debug and Run on other applications but not as much as I would like. Visual Studio compared to Rider makes it so much harder to run an app without the debugger almost as if it is done on purpose.

[@Ardalis]

Yeah Rider's simpler Run/Debug buttons are much more clear, IMO

[@Ardalis]

See also article here: ardalis.com/stop-debugging-start-running-visual-studio/

[@melihyilman8803]

lip sync stopped 4:58 :) i tought you'll show the attach button for debugging it might be usefull

[@Ardalis]

Good point - if you don't *start* with debugging you can still attach the debugger as needed. I probably should have shown that, though to be honest I very rarely do that myself.

[@bogy912]

Thanks for the video Ardalis :) I use F5 (Debug) just for the debugging, when I need to hit a breakpoint and check something at runtime. Ctrl+F5 (Run) when I want to check something on the UI or just checkt the process I made changes to :) the VS names are so so loooong, I'm a Rider user for last 6-7 years...

[@Ardalis]

Yeah I've heard nothing but good things about Rider...

[@duznt-xizt]

What I usully do in Rider is have F5 launch a "dotnet watch" profile. It automatically reloads my app when files are changed without me having to ever touch F5 again. Then when I need to debug/hit a breakpoint, i just do "Attach Debugger" and select the running watch process. Only downside is that debugging session ends everytime dotnet watch relaunches the app and I have to do a "ReAttach Debugger" to debug again. This will have to do until they get hot reload working properly in all types of projects.

[@Ardalis]

Nice! I haven't used Rider (yet) but that sounds like a fast/efficient way to go.

[@IanGratton]

Steve, totally makes sense in VS to have as a perference. I guess for muscle memory folks can just re-order the buttons on the toolbar if they want to 🐭or - learn the keyboard shortcuts. Keyboard shortcuts are a must - I'm always a bit surprised when folks don't often know shortcuts for add/remove break points, continue, run to cursor, step in step out etc. Rider is already ctrl+R and ctrl+D respectively. Important to be aware of if you need that startup overhead depending upon what you are doing 👍🏻

[@Ardalis]

I don’t know shortcuts for add/remove breakpoint but I rarely do so - maybe once a week at most? But yes it’s way faster to run your app with a shortcut than moving the mouse. And dotnet watch run often works well for that case, too.

[@carlosirias4474]

I'm starting to use run now, thanks!

[@Ardalis]

Great!

[@alexvanheerden5702]

Agree, wording is unnecessarily verbose. Does visual studio allow you to customize the toolbar? The default definitely encourages debug over run. What about hot keys? F5 is (marginally) quicker / simpler than ctrl + F5.

[@Ardalis]

Yes, you can assign whatever keys you want, but in my experience it's a pain doing so because you have to redo it when you reinstall (yes, you can export/import) and it won't work whenever you work at someone else's machine (common if you pair or are a teacher/trainer)...

[@matthiasjost]

Great video! Definietly agree on that it should be made more obvious on Run vs Debug.

[@Ardalis]

Glad you think so!

[@deepakbhanushali1]

Sir, In visual foxpro 9 debug watch window i have added getdir() now the thing is when ever i start debuging it ask me to select directory and even if i press cancelled it goes on asking me to select directory. I have tried several option to 1. uninstall VFP9 clear all the registry entry . even after reinstalling VFP9 same problem presist. CAN YOU HELP ME ?

[@Ardalis]

Sorry, I've never actually used Visual FoxPro myself.

[@unskeptable]

How is your experience with Visual Studio 22 Hot Reload feature ? It seems very slow and buggy to me. Sometimes it detects code changes even though i didnt change anything.

[@Ardalis]

It varies. Most of my work is on backend and APIs, not client apps, so I don't use it that often. But when I have, my experience has definitely been... mixed.

[@BicTic]

why would they change it how do you go back to old update?

[@Ardalis]

Why would who change what? Visual Studio hasn't changed anything, yet, although it might be good if they did so.

[@BicTic]

@@Ardalis yes they have, they changed the layout and moved stuff around update or re-download it and see for your self

[@AK-vx4dy]

SImply running somewhat undermines using VS as whole ;) Do you know it is with hot reload in this option ? Is it available ?

[@Ardalis]

How so? Do you ever "simply compile" or "simply run tests"? It's a Studio because it has a ton of different functionality at your fingertips. But you don't have to use bits of it that you don't need, all the time, if it slows you down. Hot reload is an option for some kinds of apps some of the time. I've had mixed results using it, so most of the time I just update code, run or update code, run tests.

[@AK-vx4dy]

@@Ardalis Yes i do ;) I wrote "somewhat" because if you stubborn you can simply compile from command line, not even bother to load this "ton of functionality" behemoth. This what i was try to write about. Yes results are mixed, but some times you can update code "on the fly" and/or move execution few lines back or change some variable and redirect execution to diffrent path. It is very useful in large projects when you must test from UI level or replay conditions of problem manualy. It saved me much time.

[@moeinsamarehshafeei2884]

How about VS Code Ardalis?

[@Ardalis]

I usually just use the CLI when I'm in VS Code, so `dotnet run` or `dotnet watch run` works fine. I think I've used the VS Code debugger maybe 2 times, ever. I'm open to others' thoughts on this, though, especially from those who do debug vs. run in VS Code frequently.

[@ksantacruz]

Awesome thanks for sharing

[@Ardalis]

Thanks for watching!