Debugging - The Basics
When you first start programming commercially you're unlikely to have been taught how to debug using tools such as Visual Studio.
Visual Studio has one of the most seamless debugging experiences for web development, but it's something you'll end up picking up on the job, not something you're taught.
In this series of blog posts I'm going to demonstrate how to debug using Visual Studio and some of the more useful debugging features found inside Visual Studio.
Before we get into debugging via Visual Studio, I'll run through when to use debug mode in Visual Studio and how to interpret ASP.NET error messages.
Running in debug mode
As a rule of thumb, only run in debug mode when you want to debug. Don't run in debug mode all of the time.
Your code will run much slower in debug mode, so if you're just running your site to check something or make content changes etc, you shouldn't run in debug mode. Save debug mode for when you're debugging.
I did a quick bit of benchmarking of an Umbraco v11 site to illustrate the point:
Spin up times of an Umbraco v11 site: | |
Debug mode: | 33s |
Non-debug mode: | 17s |
Average page load time: | |
Debug mode: | 43ms |
Non-debug mode: | 24ms |
If you're using IIS Express, Start Debugging (F5) will by default run in debug mode. Debug mode is slow, don't run in debug mode unless you need to debug.
Start without debugging (Ctrl+F5) when running an application, you can always use Debug > Attach to Process... and select IISExpress afterwards if you want to start debugging without restarting the site.
Conclusion
In the next post I'll talk about interpreting ASP.NET Core error messages to help you debug a problem without having to even launch the debugger.