 Hi, my name is Hari Krishnamayanan and I'm a Program Manager in the Visual Studio team. Windows Presentation Foundation, or WPF, is a rich presentation system for building Windows desktop applications. You can build visually stunning user experiences that incorporate UI, media, and complex business models. You can rapidly develop enterprise class line of business applications with a comprehensive set of features like controls, data binding, animation, and styles. In this video, let's take a quick look at the authoring, debugging, and diagnostic capabilities for WPF applications in Visual Studio 2015. We redesigned Blend for Visual Studio 2015 to provide you with a great user interface development experiences. You can use Blend to create beautiful XAML apps. Blend has a sleek new look consistent with Visual Studio for improved workflow between the two products. Now, let's take a quick look at the new and improved Blend. The first thing that you notice when you open Blend for Visual Studio 2015 is a theme. It is much darker than Visual Studio's dark theme. It helps pop the content out. That means it's easier for you to visualize and design your content in Blend. We have also made a couple of other design changes like your tool strip is now much closer to the artboard. It allows you to easily manipulate and design your content. VS features like Solution Explorer and the Team Explorer have made its way into Blend. With the support that we offer in Solution Explorer, you can now use Solution Folders and be benefited by the awesome performance that Visual Studio offers for large-scale solutions. Blend favorites like the Asset Spane, States, Triggers and Data have also made its way into new Blend. Blend still remains the tool of choice to create complex animations. We also have support for full-fledged IntelliSense in Blend. The same language service that is used in Visual Studio now powers the IntelliSense in Blend as well. In Visual Studio 2015, we have rebuilt the XAML Language Service on top of the .NET Compiler Platform or Roslin to provide an improved XAML editing experience with rich IntelliSense that is faster and more reliable. This is the first step in enabling a number of new powerful features in the XAML Language Service. On the docket are features such as cross-language refactoring operations, improved IntelliSense filtering and better data-binding IntelliSense. In addition to this fundamental change, we have enabled a couple of new features like in-place editing in Visual Studio, support for peak and the ability to add regions in XAML code. Let's take a look at peak first. I'm going to select this border and I really want to change its background. Traditionally, I would have to go to that particular style by going to Definition and Edit it. No longer do I have to do that. All I have to do is right-click, peak definition and this brings my style from a different resource dictionary in the same view that I'm editing. That is super cool. Now I'm going to change the value gray to red, hit enter and save. And when I go back to the design surface, you can see the change is instantly reflected. Now you might be wondering, will this work for code? Absolutely. Let me go find an event. So here you can see that I have a projects loaded event. I'm going to right-click on projects loaded and do peak definition. You can see that we now allow you to edit your C sharp code within the view you're editing in XAML. So that is very useful. In Visual Studio 2015, we have also introduced a new feature called in-place editing. In-place editing was generally available in Blend, but now it is available in Visual Studio as well. Let me show you what I mean by in-place editing. I have this button here and I really would like to change its template. And I'm going to right-click, do an edit template and edit current. What you can notice is that we bring in the template of the button inside your current view. You no longer have to go to a different document to edit the template of that button. I'm going to go change the background. So half year the background is set to button link color. I'm going to delete that and change to red. And hit save. You can see that we instantly update every single instance of that button into red. Now for the final demo. We got a lot of feedback from users saying that they really wanted to annotate parts of their XAML code. Unfortunately, annotation is not really something we had supported before. But what if you want to demarcate or split your XAML code into logical chunks? You can now do that by using the region feature in XAML editor. So I'm going to start typing. Select region. Name my region. Now I'm going to add an end region tag. And you can see that we instantly allow you to collapse that region. And once collapsed, it just shows the name of the region. This makes it super easy for you to logically differentiate chunks of your large visual trees. One of the top requests from developers has been tools for inspecting the XAML at runtime. With Visual Studio 2015, we are pleased to introduce the new UI debugging tools for XAML. These tools enable you to inspect the visual tree of your running WPF application, as well as the properties on any element in the tree. Visual Studio integrates these UI debugging tools directly into the debugging experience so they fit seamlessly into the development cycle. As soon as the app is launched by the debugger, when I switch back to Visual Studio, I can see two new panes. The first one is called the live visual tree and the second one is called the live property explorer. The live visual tree shows all the elements in the visual tree of the running application. And when I select an element, you can see the live property explorer is updated in real time with the values of the properties of the element selected. The live visual tree updates in real time. That means if when new elements are added or removed from the visual tree, this tree will update automatically. To demonstrate that, let's take a look at the element count now. It is 6,700 elements. I'm going to switch to the running application and scroll towards right. Now let's switch back to Visual Studio. You can see the element count has now increased from 6,000 art elements to 8,000. So this makes it super easy for you to visualize your ever changing visual tree. Let's go back to the app. I don't really like the fact that this date text block is actually center aligned. I want to move all this to its left. Let's go back to VS and see how we can make that happen in a running application. I'm going to use the selection button, which enables me to select elements on the running app. I'm going to switch back to the application and select the date text block. Now I'm going to switch back to Visual Studio and you can see that we have instantly synchronized the live visual tree to the element that we had selected on the app, as well as the properties have also been updated. I'm going to travel up the tree to select the data grid column header and you can see the horizontal content alignment is set to center. I'm going to change this to left. As soon as it changes this, we update the running application with this value. One thing you can notice on the live property explorer is how the attributes are categorized based on where the value is coming from. For example, local values that you said in XAML are shown here. Values that are coming from styles are shown here, etc. So this makes it very easy for you to understand what property wins in your running application. Now let's go back to the app to see the change that we have made. You can see that both column headers are now aligned to the left, which is pretty awesome. In the future, we will even enable you to persist these changes into your source code while you're making the changes to your running application, a true XAML edit and continue experience. Performance is a critical aspect of any application. Customers expect applications to load fast as well as interactions with them to be jitter-free and fluid. The application timeline tool helps you improve the performance of your WPF applications by providing a semantically rich, scenario-centric view of your application's resource consumption. You can analyze the time spent by your application, preparing UI frames, servicing network requests and much more in the context of scenarios like application startup and page load. I have here a simple stock ticker application that shows the value of shares for a specified set of stocks over the last one year. Right off the bat, you can notice that the startup is super slow, and I'm going to use the new application timeline tool to figure out what could be wrong in my application. I'm going to close this app, switch back to Visual Studio, and open the Performance and Diagnostics Hub. I can do that by going to the Debug menu and clicking on Start Diagnostic Tools Without Debugging. This opens up the Performance and Diagnostics Hub in Visual Studio. You can see the new application timeline tool and the CPU usage tool is already selected. I'm going to now launch the application under the Profiler. The application is launched, and if I switch back to VS, you can see that a live CPU utilization graph is shown that shows the amount of CPU that's being consumed by your application. It looks like the application is completed loading. I'm going to switch back to VS and hit Stop Collection. As Collection might take some time, I'm going to switch back to my pre-prepared session file. When the session report comes up, you can see that we show you three graphs. The first graph is a UI thread utilization graph. The UI thread utilization breaks down the utilization of your UI thread into its components that is understandable to users. For example, we tell you the time taken by parsing, layout, render, IO, and application code. You can see that there is a lot of application code running during application startup. The second graph is the visual throughput graph. It tells you the frame rate of your application in the desktop window manager in the composition thread and on the UI thread. You can see the frame rate was pretty much zero for the UI thread during application startup. That means it was completely busy. Now let's take a look at the details view. In the details view, you can see we have created a top-level event called application startup. This event measures the time between the application is launched by the operating system and the time taken for your application to show its first frame. This is super interesting. I'm going to right-click on this event and do a filter to event time range. When I do that, my view is filtered by the time taken for application startup and I can view all the events that happened during startup. I can see my application spent 170 milliseconds in parsing when I open that, it shows me all the files that were parsed as a result of parsing app.zaml. The parsing cost is inclusive of the time taken to parse the file and the time taken to create the object. It also shows me layout cost of each individual element. It tells me what the cost was for each element to layout during the layout pass. This is very interesting since it'll help me troubleshoot complex custom panels and their logic if they take too much time during layout. We also support a number of filters and sort functions to make it easier for you to slice and dice your data. They also allow you to group by frames and there are a number of search functionalities available as well. Let's take a look at the CPU usage tool since none of these events can explain why it took so much time from application startup. I'm going to shift to the CPU usage tool and you can see that the main is taking almost 95% of the time. I'm going to keep drilling down to see which function is responsible for this and here I can see that model.getData is a function that's responsible for spending so much time on the CPU during application startup. Let me take a look at that code. This getData function looks like it's doing a lot of computation and network requests on the UI thread. And let's see how much time this is taking. I'm going to put a breakpoint at the start of the function and I'm going to put a breakpoint at the end of the function. Now I'm going to start debugging. You can see that the first breakpoint gets hit. Now I'm going to continue execution. As you can see it's taking quite a lot of time to execute this function and you can see here the new feature called pref tips tells me the time taken between these two breakpoints and it's a good 8 seconds which is not that great. But I know I can quickly fix this by running all this logic on a different thread. So I'm going to stop debugging. Go to my toolbox. I already have a snippet created to optimize this function. I'm going to delete this and drag my snippet over here. And you can see that it's pretty easy for me to run this code on a separate thread. This is how you can use the new diagnostic experiences in Visual Studio to successfully troubleshoot your XAML applications. I would like to thank you for taking the time today to learn about WPF application development. The Visual Studio and WPF team blog has more details around the capabilities of the platform and the tooling available in Visual Studio. You should download Visual Studio 2015 today and try out the new features available for WPF application developers. Thank you.