 Welcome back. My name is Dante Garnier and I'm here to continue the Connect Learn series on the Universal Windows Platform Application Development. If you've been following along, you've got Visual Studio on your machine, you've created your Hello World application, and you've even played a little bit with the debugger to try to learn how to work with your application and make sure the logic underneath is working correctly. In this video, we're going to take a look at two of the more advanced tools that help you find the trickier problems to solve and those are the UI debugging tools and the diagnostic tools. Let's go ahead and jump in and take a look at how the Live Visual Tree and Live Property Editor can help you find the UI issues in your application. Now I'm going to go ahead and press play and launch my application. Now that my application is up on the left, you can see the Live Visual Tree. If you don't see the Live Visual Tree, that may be because it's unpinned right now, all you need to do is click on the Live Visual Tree tab on the left and pin it in place. Now what the Live Visual Tree is showing me is the entire set of UI elements anywhere in my application. It starts with the root scroll viewer, the scroll content presenter. These are controls that Windows puts in place to host your universal app. As you get further down, you're going to see the controls that you created, my categories, my root grid, and so on. Many of these have a document icon at the right, which when I mouse over will tell me which document that particular control is defined in, and if I click on it, it will open that document and take me right to where that particular XAML element is defined. Now, if you're still working with your Hello World and you've only got three or four controls, it may not be obvious how valuable this is, but as you start working with more and more sophisticated apps and you start working with item templates and data templates, this control is invaluable. Over on the right, you'll notice that it's showing me the descendant count of this element and all of its children. Again, if you're just working with your Hello World app, you may not see how valuable that is, but if you're working with a virtualizing control that adds and removes elements as the user scrolls it, this will help you find out if the virtualizing component is doing what it's actually doing, as well as many other issues that can lead to performance issues in your application. Now, I have a fairly sophisticated tree here, but if I want to find a specific control, I can click on the Enable Selection button here, and now as I mouse over my application, the live visual tree is giving me a highlight telling me, hey, is this the control you're interested in? So I can do this to pick any particular control, it will locate that control for me in the live visual tree on the left, and if I expand the live property explorer on the right, it will show me all of the properties that are being set on that control. This will even go so far, this particular example doesn't illustrate it, but if your properties are being set from styles or from themed resources and things like that, all of those values will be shown here to make it easier for you to figure out where a particular setter is coming from. The live visual tree and live property explorer work together to help you find the tricky UI issues that you might run into when you're working with universal Windows apps. Now, there's one more problem that we have and you may not be able to see it because of all the editing that we've been doing, but I seem to have a bit of a performance issue in this app. Specifically, it's startup, it's not starting up as quickly as I'd like, and I'd like to profile it to figure out exactly what's happening. I'm going to go to the debug window and I'm going to choose start diagnostic tools without debugging. Naturally, whenever you're doing performance evaluation, you don't want the debugger coming in because if you break on a breakpoint, it's going to think that that's time spent, it's just going to make a mess out of things. So in this case, I want to make sure I'm running without debugging, which is really the only option when you're doing profiling. I'm going to work with the application timeline and CPU usage, which I already have checked here, but as you're doing your application development, you'll know when to use the memory usage, GPU usage, and or networking tools. A quick note about memory usage, it must be run by itself. It's kind of hard to evaluate how much memory your application is using if while I'm measuring that, I also have performance going off and I have the timeline keeping track of everything that's going on. So if you want to do memory, you need to uncheck everything else and then you can't recheck anything, but for now I'm only working with the application timeline and the CPU, so everything should be fine. I'm going to go ahead and hit start and at this point, Visual Studio is building my application. It's putting all the performance markers in that I need. You can see already that the diagnostic window is showing me just how much time has passed. So over the first five seconds, I can see my CPU usage. My problem is it's startup, so that should be enough. I'm going to go ahead and stop collection at this point and now Visual Studio is taking everything that happened over that particular time span and building a report for me so I can figure out exactly what's going wrong. So there we go, we can see very quickly over the first five seconds, I've got a lot of code going on. I can use my mouse to drag over that area and say, hey, this is where I think my problem is. Show me what the CPU is doing during that time. All right, well my first command here is taking 71% of my CPU. Well, if I've got a performance issue during that first chunk, the one that's taking up almost three-quarter of the CPU, that's probably my issue. So it looks to be, get recipes from JSON. So let me figure out where that method is. Okay, here it is. Let's double-click that and I'm going to go ahead and set a breakpoint and now I want to run my application with full debugging because, well, I know the problem is here somewhere. Let's go ahead and track down the issue. So all right, my application is running. Let's scroll down just a little bit and I'm going to step over the command that I'm currently on. Now if you notice, as soon as I do that, over here on the right, it's showing less than or equal to one millisecond elapsed. That's what we call a perf tip. This is telling me how long that one command took to run and in this case, less than one millisecond. That's the lowest granularity the perf tips will ever give you. Now, why is it less than or equal to one millisecond? Well, there's a little tiny bit of overhead that comes from the performance tips overall. So it's telling you, you know, it might be slightly less than one, but it's somewhere in this area. When I step over the next command, you'll see that it's telling me that it's less than or equal to six milliseconds. Does that mean maybe it was five milliseconds somewhere in that area? Don't get hung up on the specific numbers. Look more at the relative time that it takes. So let me step over again. That one took six milliseconds. Now, if you're paying attention, this next method is long running calculation. Yeah, let's see. Do you think that might be the performance? Yeah, that's where the performance hit is. And if you notice, not only can I visually see how long that one took, but the perf tip is telling me that that was, you know, two and a half seconds long. So that's clearly where my performance issue happens to be. The perf tips can make it very easy for you to figure out and narrow it down to exactly which method is causing you the problems and then delve further into it to try to track down exactly which piece is your problem. Perhaps you've got a bunch of files that you're requesting from the internet on the UI thread. That'll slow down your startup time. You'll switch that to an asynchronous task and so on. There are plenty of other documents out there to help you learn how to debug performance issues, but this is the tools that are inside Visual Studio to at least help you figure out what neighborhood to be in to start fixing what's wrong. These tools should give you an introduction on how to start working with your applications and start going from your concept to something you can get out there in front of your customers. I hope you've enjoyed this very introductory look at the various tools inside Visual Studio and it's been my pleasure to walk along with you. My name is Dante Gagnier and from here, it's all up to you. Thank you.