New Features in Visual Studio 2017

Microsoft has recently released Visual Studio 2017, adding a significant number of features on top of what’s been available in prior versions. This release has a particular emphasis on Visual Studio’s performance and its ability to make developers more productive. Since the best developers always suggest to stay up to date on new tools and technologies, it is worth spending some time to gain an understanding of these new features. Doing so helps developers who use Visual Studio assess whether an upgrade to this newest version is worth their time. Note that this post does not cover all of the new features that have been or will be added.

Following are the new features which will be discussed in this post:

  • Lightweight Solution Load
  • Live Unit Testing
  • Navigation and Debugging Updates
  • Javascript Debugging
  • Structure Visualizer
  • Window Layouts

Lightweight solution load

This feature is most useful when trying to load up solutions with a large number of projects. When this feature is disabled, you have to wait for every single project inside the solution to load up before you can start working in any of them. Conversely, when you enable the lightweight solution load, large solutions will load much more quickly. I have observed a 40%-50% reduction in the load time when using the lightweight solution load on a solution with 70 projects.

Turning this feature on does not come without a tradeoff. When you turn it on, projects in the solution are lazy loaded. In other words, there is a loading time when you first open a project, regardless of how long ago you opened the solution. Note that this loading only occurs the first time you open a given project. So the tradeoff here is that your solution as a whole will load up significantly faster, but you will still have small loading times when opening an individual project.

In my experience, the benefits of the fast solution load far outweigh the cost of having to lazy load each project. The loading time for an individual project is very fast, so there’s really not much of a wait time. Additionally, Visual Studio uses much less memory when the lightweight solution load is enabled, since you aren’t loading up every project in the solution every time you open it.

This feature is easy to begin using. To enable it for an individual solution, simply right click on the solution inside Visual Studio 2017 and click Enable Lightweight Solution Load. You can enable this feature for all solutions opened in Visual Studio 2017 by going to Tools > Options > Projects and Solutions > General > Enable Lightweight Solution Load for All Solutions. Note that as of this writing, this feature is disabled by default due to known compatibility issues with some of the IDE features and extensions. Keep this in mind if you choose to begin using this feature.

Live unit testing

This feature is very similar to NCrunch, which is a tool that runs unit tests continuously as you modify and change your code. The two major benefits of such a tool are: one, to give you live feedback on whether the changes you’re making are affecting your unit tests; and two, to give you an understanding of your code’s coverage, helping you to identify areas where you might need to add more unit tests. Do not underestimate the usefulness of this type of feature. It provides a significant performance boost both for unit testing and for modifying code in your code base.

When you first start the Live Unit Testing process in a large solution, you will receive a pop-up telling you that large solutions might have slower performance if you enable the feature for all unit tests in the solution. With Live Unit Testing you have the option to choose only a subset of your tests to participate. Doing this will increase the performance of the process (note that this is no different with NCrunch). If you select No in this pop-up, all tests in the solution will be excluded by default, and you will need to manually include each of the ones that you want to run. You have 3 options for including your tests: the first option is to include an entire test project by right clicking on the project, selecting Live Tests, then clicking Include. The second option is to include all tests within a given test class by right clicking within the class and clicking Include. Finally,the third and most granular option is to include an individual test method by right clicking within the method and clicking Include.

As mentioned above, the Live Unit Testing feature is very similar in many ways to NCrunch. Both of these tools use the margin space within Visual Studio to show you code coverage and unit test pass/fail status. Both tools also allow you to easily transition between a line of code and the unit tests that cover it – or vice versa – by clicking on the icons within the margin. Neither of these tools are free; NCrunch requires a subscription to use it, and Live Unit Testing requires you to have Visual Studio 2017 Enterprise.

Now, there are a few key differences between NCrunch and Live Unit Testing. For one, NCrunch has been around for a lot longer, so it’s quite likely that its features are more stable and developed. It probably even has some features which are simply not available in Live Unit Testing at all yet. In terms of performance, I have not noticed a significant difference between the two tools. The most significant difference I have noticed lies in how the tools are configured. With NCrunch, I have experienced very frequent occurrences of projects within a solution not running the test process because of a configuration issue. Often these configuration issues are difficult and annoying to track down and fix. Conversely, Live Unit Testing is built directly within Visual Studio 2017, so I have not noticed any configuration issues using it. Because it’s built directly into Visual Studio, Live Unit Testing has been less of a hassle to configure than NCrunch. Finally, the last benefit of Live Unit Testing over NCrunch I have noticed is that it does not add configuration files to your project, whereas NCrunch will add them. These files are often a source of clutter which are simply not present when using this new Live Unit Testing feature.

One important thing to note is that if you choose to start using Live Unit Testing within a solution created in an earlier version of Visual Studio, you will need to modify your test projects to remove the reference to Microsoft.VisualStudio.QualityTools.UnitTestFramework and then add NuGet packages for your given test framework. The necessary packages to install can be found here.

Navigation and debugging

Navigation via the Quick Find (Ctrl + F) and Find In Files (Ctrl + Shift + F) has been significantly improved upon. All navigation is now consolidated under the Edit tab in Visual Studio 2017. However, probably the most significant new feature is the addition of Go To All (Ctrl + T) which behaves almost identically to Resharper’s navigation tool. When you use the Go To All feature, a window will be docked on the side of your Visual Studio window. As you begin typing, you will get a dropdown of all items matching your search. You can navigate through the results by simply scrolling up and down with the arrow keys, and the files will be temporarily opened in your window as you scroll through them. What this means is that you can see the contents of each file in your search results without having to explicitly open it up, and more importantly, without having to close your search window. If you click Enter on the file you want, it will open it up and close your search window. If you click Esc you will be taken back to the file you were originally viewing.

The second most significant change to navigation is with the Find All References view. This view now will group references to a particular item by project and class. This gives you much greater insight into exactly where in your code base this item is being referenced. Additionally, the same color coding that is used within your code is now displayed within the Find All References view, giving you an even greater understanding of how the item is being used in each reference. Finally, hovering over any given reference will given you a pop-up window with a small snippet of the code where the reference is being used, which gives you a third layer of context around an individual reference without having to open the file (and subsequently lose your view).

In terms of debugging, a new feature called Run To Click has been added which allows you to run your code to a specific line of code without having to add a temporary break point on that line of code. While running Visual Studio in debug mode, if you have currently paused your code’s execution and you hover over a given line of code, a glyph will show up which you can click. Clicking this will run your code until it hits the line of code that you clicked on. This prevents you from having to add a large number of temporary breakpoints throughout your code while debugging.

Javascript debugging

Debugging javascript within Visual Studio has now been added with Visual Studio 2017. As of this writing it is currently limited to being used with Google Chrome, since it actually attaches to the Google Chrome debugger. When using it, you can put breakpoints within your javascript code in the same way as you would with .NET code, and when you hit the javascript through the browser you will hit your breakpoints in Visual Studio. The rest of the debugging process is the same as you would expect with other kinds of debugging in Visual Studio, showing you current values of local variables and objects and allowing you to step through the code line by line.

Now, the task of getting this javascript debugging to work can be non-trivial depending on how your project is set up. Consider the example of a project that is set up to process the javascript via bundling, minification, etc before it is served on your site. This is the case with many – if not most – projects. In cases like this, setting breakpoints within your source code won’t work because your site won’t even be using the source code directly; it’ll be using the processed files.

Even if you find a way to use your source files for local development, another issue arises if your source code is not pure javascript. This can happen, for example, if you are using Node and writing your Javascript as Node modules. In this case, you might successfully be able to reach your code with the debugger, but the browser won’t be able to understand the code so you’ll just get errors.

Because there’s likely to be a non-trivial amount of work in order to get this feature working properly for many projects, it is not as simple to start implementing within your workflow as some of the other new features. Still, there is little reason to doubt that being able to debug your javascript directly alongside your .NET code has great potential for a significant productivity boost.

Structure visualizer

This is a small but very useful feature which has been added in Visual Studio 2017. It is a way of enhancing your navigation within an individual document. What it does is to draw vertical gradient lines from the opening brace of a block of code to its closing brace. In other words, it provides a very visual way of distinguishing between different scopes within your code. Additionally, when you hover over these gradient lines with your cursor, you’ll see a visual popup of the opening lines of code for that scope (for example, method signatures and class headers) and its parent scopes. This prevents you from having to scroll to see what scope you’re currently located in within your document.

This feature is surprisingly useful, particularly within javascript code which can have a tendency to become very nested. One great example of its usefulness is within Jasmine unit tests, which can have some complicated nested of describe blocks within other describe blocks. Finally, this feature has the added benefit of simply helping to ensure that you’re indenting your code consistently, which ends up having a readability benefit in the longer term. 

There is no effort required to begin using this feature, and it is enabled by default in Visual Studio 2017.

Window layouts

The last feature I’ll mention is window layouts. This is another productivity feature which allows you to set up and save different views for Visual Studio. For example, when you first start up Visual Studio you might want to have the Team Explorer window pinned to one side of the window and the Solution Explorer pinned to the other. Now that you have the ability to save window layouts, you can simply save this setup and then use a keyboard shortcut or go to Window > Apply Window Layout and select your layout. This immediately puts Visual Studio in the setup that you want it to be in. Before this feature, Visual Studio would simply open up with the windows wherever you left them last, requiring you to re-order them manually to the way you need them. This was particularly annoying when you went from a multiple-monitor layout to working on a single monitor, which would inevitably cause the layout to be incorrect from how you wanted it.

Ultimately, the biggest benefit of this feature is that it helps to accommodate transitions between working on different areas of your project within Visual Studio. For example, the way you want Visual Studio to behave is very likely to be different when you’re working on client-side code (javascript, html, and css files) versus working on C# or database code. In the case of working with client-side, you might want to have the task runner explorer opened and have everything else closed. In the case of working on your database code, you might want to have the server explorer and the solution explorer opened. Whatever the differences actually are, having different window layouts allows you to quickly transition between your different workflows by simply being able to select the appropriate window layout. This mitigates any time you otherwise would have had to spend on trying to reorganize your working Visual Studio session.

This feature is very easy to use as it’s simply a matter of saving your Visual Studio instance in a desired state and then using a hotkey to open it up later.

Final words

As mentioned at the beginning, this post does not attempt to cover all features, so it’s definitely worth looking into what else is offered in this new release. Overall, the features discussed offer a compelling reason to upgrade to Visual Studio 2017, particularly if you already are working with Visual Studio Enterprise but are not utilizing tools such as NCrunch and Resharper. The additions of Live Unit Testing and the upgraded navigation alone are sufficient justification for upgrading in these cases, as they will significantly improve productivity for yourself and your team.

Leave a comment

Your email address will not be published. Required fields are marked *