Review: Visual Studio 2013 reaches beyond the IDE

Microsoft delivers editing, debugging, deployment, project architecture, and ALM improvements stretching from Windows to Web development, from mobile devices to clouds

What do you do when you have a market-dominating product built from more than 50 million lines of code with a loyal customer base of subscribers who use it all day, every day, and you want to keep them happy? You upgrade it for free at incremental releases to address the pain points, and at a nominal charge at a full release to address new technologies and to make major enhancements. That's exactly what Microsoft has done with service packs to Visual Studio 2012 and now with the release of Visual Studio 2013.

Visual Studio users can fall into a range of categories (developers, testers, architects, and so on) and use a range of technologies (desktop, Web, cloud, Windows store, services, databases, and more). While there are competitors for almost every area where Visual Studio provides a solution, no single product competes with Visual Studio in all fields. The closest I can think of would be Embarcadero All-Access XE, which is more of a suite than a unified product.

[ Work smarter, not harder -- InfoWorld has tips and trends programmers need to know in the Developers' Survival Guide. Download the PDF today! | Stay abreast of key Microsoft technologies in our Technology: Microsoft newsletter. ]

The new release sports big improvements in application lifecycle management (ALM), including the ability to build, test, and deploy in the cloud via the new Team Foundation Service and integration with Windows Azure. You'll also find significantly better tooling for Web development with ASP.Net, as well as better support for JavaScript, HTML, CSS, and Python editing and debugging.

In short, Visual Studio 2013 brings not only a number of big improvements tailored to development teams, but also many smaller ones that will actually matter to working developers.

Team Foundation ServiceLet's start with the new ALM features in Visual Studio 2013, which is where we thought we'd see the focus of this release back in June. The biggest ALM win from my point of view is that Visual Studio now supports Git in addition to Team Foundation Server's native version control. (Clearly, the Microsoft that added Git support to Visual Studio is not your father's Microsoft; ditto for support of Python, JavaScript, and jQuery. What's next, open sourcing the .Net Framework? Oh, wait -- that happened years ago, at least for the base libraries.)

One thing I don't like about Team Foundation Server is setting it up for a geographically distributed group. Performance can be a big issue, especially when the group spans the globe, as outsourced projects often do. There's an all-Microsoft solution for that: Team Foundation Service. As you might expect, it runs in the Azure cloud. As you might not expect, it's free for teams of five or fewer, and larger installations are included in the higher-end Visual Studio with MSDN subscriptions at no additional charge.

By the way, Microsoft maintains a release archive for Team Foundation Service that shows when certain updates appeared in the Service and the Server. From here on, when I refer to TFS, I mean both Team Foundation Server and Team Foundation Service. The capabilities are available in both the product and the service.

Build and test in the cloudYou can set up TFS to automatically build and test periodically or after every check-in. This is a big convenience and productivity enhancement, even compared to other commercial code-quality services, which usually make you check in separately after the acceptance criteria have been met and all tests are green. In addition, you can deploy successful builds to Windows Azure automatically using the InRelease component discussed below.

Speaking of Windows Azure, you can now create Azure sites and databases directly from Visual Studio once you've installed the current Azure SDK. It couldn't be much easier. When you create an Azure site from Visual Studio 2013, you get a placeholder site even before you deploy what you're building. Visual Studio remembers the Azure connection you create to make later deployment simple.

One hugely useful integration between the Visual Studio editor and TFS (including Git) is Codelens, which shows you version history comments in your code. Codelens also lets you know if you're working with code for which there has been a check-in since you last pulled from the repository. That eliminates a whole class of problems and duplications of effort that commonly crop up in areas of active development. I can't tell you how many times I've gone to check in a bug fix only to find that someone else has taken care of it.

Team Explorer, the client interface to TFS, is much more useful than it was before. Admittedly, that wasn't a high mark to beat, but Team Explorer now shows you what you need to know fairly quickly.

Using Team Room, an integrated chat capability in Team Explorer, can help keep your desktop clutter down, although many development teams will undoubtedly continue to use Skype, Google Hangouts, or their favorite chat program, despite any advantages of Team Room. Never underestimate the power of habits.

Microsoft acquired InRelease, a release management product built specifically for Team Foundation Server by InCycle Software, last July. InRelease, now integrated with Visual Studio 2013, Team Foundation Service, Microsoft Test Manager, and Team Build, enables a number of common release scenarios, including releasing on demand to a local or hosted VM, daily release for smoke testing, and continuous deployment. If you don't already have this kind of capability set up for your products with other tools, you might want to consider using the new release management features in Visual Studio 2013.

Smarter code editingCode editing in Visual Studio 2013 has picked up a number of what might seem like minor improvements, but in the aggregate can make a huge difference in developer productivity. For example, the Go to Definition feature does a better job of maintaining your editing state, so you can go back to where you were using the back arrow. For languages that have the support, such as C# (but not JavaScript), the Peek Definition feature pops up a window with the definition you requested without disturbing your underlying edit window. And Code Map does a great job of giving you a big picture of where you are in your code, again for those languages with the support.

Given the amount of JavaScript I've been writing the last few years, I might resent the fact that Visual Studio's JavaScript editor has yet to receive these whizzy new features. Nevertheless, I'm thankful that the JavaScript support in Visual Studio 2013 has improved to the point where I don't feel the urgent need to switch to a different editor (say, Sublime Text) every time I work with a large JavaScript file. I'm also thankful for the JavaScript features added to Visual Studio by the free Web Essentials plug-in.

Codelens shows you version history comments in your code. It will also tell you if there's been a check-in for the code since you last pulled it from the repository.

The ability to add Python support to Visual Studio 2013 with a simple install from within the IDE is also nice. While the Python support doesn't seem to be as good as, say, the C# support, it works -- both for IronPython and CPython, although not JPython. Django is supported as well, and a Django project is one of the New Project options for Python.

My real Visual Studio workspaces (unlike the toy projects I used for screenshots in this article) tend to be enormous, multipronged extravaganzas set up so that I can build and edit everything I care about from one solution. With Visual Studio 2010, my morning routine was to log in, start Visual Studio, boil a quart of water, brew tea, let the tea steep, pour the tea, add honey, and return to my machine around the time all the projects became usable -- a multiminute delay despite the fact I had an automatic task set to update from source control and rebuild all my projects very early every morning. I would typically try to keep Visual Studio 2010 open all day rather than incur the startup overhead again, but sometimes my application bug would hose the IDE.

In Visual Studio 2012, asynchronous startup of the IDE improved the situation noticeably. In Visual Studio 2013 it's not going to be a problem if I forget to start the IDE before preparing the tea. As long as the tabs I opened the night before are the ones I now want, I should be up and running in less than a minute.

One ASP.Net project Web development tooling has taken a giant leap forward in Visual Studio 2013. Visual Studio 2012 had seven different ASP.Net project types, and if you started with what turned out to be the wrong one you were in for painful editing chores. Visual Studio 2013 has one ASP.Net project to rule them all, and it's a huge improvement over its predecessors, letting you mix and match Web technologies using a wizard.

If you forget to add everything you need to an ASP.Net project when you create it, you can now easily add it later via scaffolding. Scaffolds include generators of controllers with all combinations of available Web technologies, generators of views, and generators of areas. Areas are a way of partitioning MVC applications, added in MVC 2, that solves the problem of having an unwieldy number of models, views, and controllers in a large website.

MVC Web projects strongly remind me of Ruby on Rails, with the same strengths, weaknesses, and pitfalls. If you put the model-related code in the model, the view-related code in the view, and the controller-related code in the controller, then avoid crossing the lines, you can build a robust website that automatically implements RESTful actions and cleanly separates and decouples the database, UI, and event-handling functionality. If you forget the divisions and, for example, interrogate the database directly from the view, you'll wind up with a buggy application that needs to be refactored to become maintainable, just as you would in Rails.

Browser LinkWhen developing a Web application, it's very common to have multiple browsers open and pointing to the page under development. As you made changes, you used to have to update all the browser windows manually and test in them. In other cases, simple updating could be problematic, such as when JavaScript or CSS files changed.

Browser Link fixes that by creating a real-time, two-way connection using SignalR between Visual Studio 2013 and all the browsers you connect to your locally hosted debug-mode site. Again, this isn't your father's Microsoft: It works with any browser you wish to use, not just the latest version of IE, and it works with browsers running in device emulators/simulators. (You can download emulators from Microsoft's ASP.net site.)

Visual Studio 2013 makes it easy to add a new controller, view, or model to an MVC Web project.

With Browser Link set up, you can see all the browser windows reflect every edit or style update. You control the refresh from Visual Studio 2013 and it pushes the refresh to the browsers, so you don't have to touch all the browser windows manually. This can be a real timesaver. It's also a good case for having at least two monitors on your development computer.

Another new way to view Web pages from within Visual Studio 2013 is to use the Page Inspector, an internal browser that integrates with IntelliTrace, the debugger, and the code editor to help you understand the connection between your code and what is displayed.

True Web app monitoringUnfortunately, no matter how well you set up your tests and your debugging environment, some bugs will only show up on a production system. That's true of desktop programs in the field to some extent, but it's even more common to have this problem on multi-user Web applications that use many services.

We've had IntelliTrace logs for desktop applications for years. When an error occurs, the application generates the log and typically asks the user to send it to the developers. The developers then match up the log with the symbols from the correct build and open the IntelliTrace log in Visual Studio to identify the problem.

In the past, production ASP.Net applications didn't do this, for scalability and performance reasons. Finding a bug that only occurred in production meant taking a performance hit for as long as it took to reproduce the problem, then reverting to release code once the bug was thought to be fixed.

Microsoft Monitoring Agents (MMA) changed that. Now you can run MMA on production websites full time, at least according to Microsoft. (If your site runs above 80% of memory or CPU utilization, I'd say all bets are off.) When an error event happens, the application will generate an IntelliTrace log file. These let you go to the code that caused the problem when you open them in Visual Studio 2013, just like they would for desktop applications.

1 2 Page
Free Course: JavaScript: The Good Parts
View Comments
You Might Like
Join the discussion
Be the first to comment on this article. Our Commenting Policies