A question that keeps coming up is whether or not Blend should be integrated into Visual Studio. The current thought is that it is still better to have separate tools, one focused on UI design tasks and one focused on application development. But that doesn’t mean both can’t be improved.
Blend 2015
To start with, Blend will be adopting several features from Visual Studio such as its solution explorer and code editors. These are time-tested features of VS and there is no reason for Blend to have its own alternatives.
By bringing in the Visual Studio code editor, Blend also inherits features such as the Peek Definition popup. This even works in XAML when looking at event handlers in the code-behind files.
Like Visual Studio, Blend will be picking up a “dark theme” that reduces the visual distraction caused by the IDE itself. The plan is to make this even darker than the Visual Studio dark theme to reinforce this idea of distraction free, design-centric work.
Today, if you make a change in Visual Studio then Blend will display a prompt asking you if you want to reload the affected files. With Blend 2015, that prompt can finally be dismissed permanently. It seems like a trivial change on their part, but this kind of frequent annoyance can have a serious impact on moral and productivity.
Visual Tree Debugging
Both Blend and Visual Studio will support visual tree debugging. Currently this is only available via third party products such as Snoop and XAML Spy. As the application runs, you get a tree view showing all of the elements in the active window. This is a live view, you don’t need to pause the application or hit a refresh button to see the current visual tree.
A selection tool allows you to point to an element in the application and have it automatically selected in the IDE. After selecting an element via the tree view or visual selection tool, you can edit the properties of the element just as you would the values of an object in a watch window.
As part of .NET 4.6, it is now possible to track line numbers in XAML. This allows you to easily find the code you need to modify by selecting an element in the tree view and seeing the file that originally defined the element.
Visual Studio Editing Experience
As the name implies, Visual Studio has been focused around visually designing UIs. This made sense back in the days of WinForms and Web Forms, as they both emphasized a drag-and-drop style experience. But with XAML, developers tend to prefer working with just the raw XAML code. On the rare occasions they want to work visually, they switch to Blend.
Visual Studio 2015 will enable this workflow by allowing developers to completely turn off the visual editing components for WPF/XAML. When the designer is turned off, the design/XAML tabs disappear, the toolbox isn’t loaded with controls, and the design time host isn’t loaded. This leaves the developer with the purely code-focused experience they desire.
This is an option; developers who prefer to use the visual designers inside Visual Studio continue to do so.
XAML Timeline Tool
The timeline tool is a resource monitor that tells you what happened during an application run. A key part of the report is the UI thread usage. This tells you when the UI thread was in use and what it was doing at the time: parsing, layout, rendering, I/O, app code, etc. It can also show you the framerate for the UI and composition threads. This is married to the CPU profiler, making it easier to find bottlenecks.
Once you find the region in code that you are looking for, a common practice is to set a pair of breakpoints before and after the code. Visual Studio now recognizes this pattern and assists you by automatically displaying the time it took to get from the current and previous breakpoint.
