Last time I discussed writing .NET applications I also discussed writing them with terminal and code editors like Visual Studio Code.
On the other end of the spectrum you have the IDE experience, the “one tool that does it all” approach. While Visual Studio Code really is designed for code editing, the full Visual Studio IDE takes things further by providing database tooling, performance analytics, a built-in testing suite, and more.
Although commands like dotnet new console are easy enough to remember, when you are doing something infrequently or for the first time it can be hard to remember what commands you need. This use case is ideal for an IDE.
Let’s say you want to make a new project using the XNA framework. From the terminal side, how exactly would you create an XNA templated project? You could type dotnet new console and put together the application from scratch, but that’s not a great use of time since you’d be recreating something that will almost always follow the same base setup. You could go online to search for existing templates and fork then clone a repo, or install a templating package before looking up the command to create the XNA application for the package. Those still aren’t great solutions because you’re spending more time figuring out your tools than making something with your tools.
If we already installed XNA in the Visual Studio IDE’s GUI, then its template will be there under “new project.” But let’s say we didn’t install XNA and instead of searching about the internet via our favorite search engine, we are using Visual Studio’s UI that lets us search for specific templates and know immediately if a template exists. We’ve now saved time and pain!
As an added bonus, Visual Studio has deployment capabilities built in for the application itself and for the database. So when you decide it’s time to deploy you can just right click on the project and choose “deploy.” You can then configure it once to deploy to whatever environment you want, be that a web application, Windows Store Application, Mobile App, etc.
Visual Studio truly shines on the discovery and investigation areas of code. While debugging in VS, you can see the amount of CPU, memory, and network traffic your application is using. When you have an error, Visual Studio will take you to the exact line of code that threw the error, provide you the ability to drill into the application state at that given moment, provide you with error details, and even provide links so you can research common causes of the error and ways to troubleshoot it.
So what if an error is actually a logical one, and not something the program sees as an error? In those cases we can either set breakpoints at spots we want to investigate further, or step through the code line by line until we spot where the problem is. Ideally we use both; using the breakpoint to stop execution at the point we think the error occurred, then stepping through it to find the cause of the error.
Does the Visual Studio IDE really make that much of a difference?
The point is your tools are meant to assist you in making difficult and repetitive tasks easier. If you are spending more time figuring out your tools, or getting them to play nice, than you are “fighting your tooling” and it’s a hinderance, not a benefit.
In development, there tends to always be more to do and never enough time to do it. We depend on our tools to provide us the functionality we need to code efficiently, quickly find and correct problems, and write better code.
Of all the stacks out there, .NET has some of the best tooling in the industry. You can learn ASP.NET using the MVC design pattern in our Try ASP.NET Core course and our upcoming Forging Ahead With ASP.NET Core course. You can also watch us create an entire ASP.NET MVC application using Visual Studio in our Watch Us Build screencast: Build a .NET MVC App.