 On today's Toolbox, Matt and Winnie are going to show us the latest goodness being sent the way of WPF and WinForms apps. Hi, welcome to Visual Studio Toolbox. I'm your host Robert Green and joining me today are Matt Corwell and Winnie Lee. Hey guys. Hey, how's it going? Good. Welcome to the show. Thanks for having us. Happy to be here. Matt and Winnie are in App Center land, and we're going to talk about App Center today. Now, App Center has been around for a while, and we've done an episode or two on this show, and of course, James has covered it on the Xamarin show. You think about App Center as DevOps for mobile apps. But it's expanding, and you guys are going to talk about App Center for WPF and WinForms. What? We are. Really, we're hoping to be App Center for distributed apps. Things that are not co-located where you are, and maybe multiple instances around the world. Cool. I guess that immediately brings to mind two questions. One is, how does that work? Which will show us. But two, why? Because we already have DevOps for WPF and WinForms. It's called Azure DevOps Services. So you don't have to answer that right now, but as we talk about it, those are the two questions I want to cover. How does it work and why? Then which one would I choose as a WPF or WinForms developer? Yeah, absolutely. So App Center is actually very different and is a great supplement to users already using Azure DevOps. So we've realized there's not a great tool in the space that allows Windows developers to easily manage their releases, look at their crash reports, and just better understand who's using their application and get the analytics that they need to really deliver the best user experience. So if you're already using Azure DevOps, fantastic. Continue using that, build your app in Azure DevOps, and App Center will help you release those apps that you build in Azure DevOps. So we really think about those two products as a complement to one another. So use one and then use the other, use them side-by-side basically? Yeah. They really, as we said, they fill different gaps and that really speaks to the why. As a Windows developer, there are lots of tools in my disposal, but I really believe there isn't a set of tools that brings this piece of the puzzle together in a comprehensive way. You can build things with Visual Studio, you can do your DevOps stuff on Azure DevOps, you can run it on Azure, but how do you manage your app when it's on a million devices in the wild? How do you see who's using it? How do you track logs? All these pieces are things that there really is not a turnkey solution for it, and we hope that's what we're bringing to folks. Okay, cool. Yeah. So I guess for those of you who don't know what App Center is, we are end-to-end solution for developers. So like you mentioned, James have talked about it probably on Xamarin, we support iOS, Android, and most recently we expanded our platforms to support desktop apps as well. So WPF and WinForm applications, targeting.NET framework as of today. So today we can go over the top three most requested services. So I'll be doing a quick overview of what these services actually look like in App Center, and then Matt will actually show how to get this up and running under five to 10 minutes. Cool. Yeah. All right. So cool. So you can see my screen here. This is a sample app that we have. The screen you're looking at is just an overview of how to get started with some SDK instructions that Matt will actually be going over in a bit. First off, we have Distribute. This is a service that allows you to easily manage how to release your apps to your end users. So over here, you can see the releases I've made to the beta testers and to myself in the past day. I'm able to see how many downloads I have, how many unique downloads I have, and I can also sort this table by what's most relevant to me. Under Groups, I can create a new distribution group. These can be your beta testers, your end users, really anyone you want to download your app. All I have to do is add their email address here, click Create Group, and then I'll see a group appear in this screen. In the Y section to keep sticking with that one, this is I think one of the fundamental pieces that is very different than what Azure DevOps would offer. Getting that app to either testers or end users, there's not a compelling story for that that I'm aware of elsewhere and so this starts to become super valuable. So putting setup.exe on a jump drive and walking it over to another computer and having somebody run that, you don't consider that compelling? I mean, it is totally compelling if you're co-located. But we've found it really interesting. Our team is actually, we've got 15 or so time zones around the world and people working on these things and so this centralized push model where I can control who sees what and when and let things go to customers. While we don't get supported for the Windows story, we do have in-app updates where you can basically help auto-update a user from within App Center. Really as a game changer, to be honest. So yeah, looking at distribution, I can click here for a new release and like Matt was saying, if you're using Azure DevOps, it's great. Build your app in Azure DevOps and then upload your app package here. So we support.zip, MSI, a lot of different package formats that can meet your need. So once you upload your package here, I just click Next, I specify some release notes who I want to distribute my app to, and then I'm done. Can I do the build in App Center as well? Not yet. So right now in Azure DevOps, you can build those apps. So we definitely encourage users to use Azure DevOps for that. If we decide there's a need to support that in App Center as well, that is something that we can look into as well. Over time eventually, the tools will probably coalesce into a single location. You'd have to ask someone with more knowledge of the future plan than I, but I don't think it would be unreasonable to picture a world where that happens. Yeah. So that's our distribution service. The next one we have is diagnostics. So this is a service that allows you to see when your apps are crashing. It gives you a good overview of the different types of crashes and errors. I can click into a crash group and get a little bit more details. I can look at my stack traces, look at the individual reports, see which devices are crashing, and get some other data that will help me understand what's actually going on once my app is being used by my end users. Right. In that world where you've walked that zip drive around to 100 people, and traditionally working through emails, asking people to send you logs, even if you've got your logs going to a central location, looking at logs as raw data is very different than looking at rich data that's been grouped and augmented and provided in a way to help you as a developer, figure out what's wrong. Right. And there are some other tools in this space that do this. I don't think any of them hit the mark with this kind of complete end-to-end picture. And so really at this point, you've got your ability to send your app out across the world. You've got your ability to get that data brought back to you and presented in, I hope, a really useful way. Yeah. And with features like events or attachments, we really allow you to customize what you need in a crash reporting tool to really understand what's going on with your app. So that's what we have for diagnostics. And last but not least, we have analytics. So all this data you see right here is out of the box. All you need to do is integrate our SDK and you'll start seeing these metrics flow in. So you see how many users you have, the daily sessions, where your users are, what devices they're using. A lot of really great stuff for you to understand who your user base is. And what features they're using and how you can really deliver the best experience for them. So all this nice data is here. And then you can go into our events tab and actually set specific events that you want to track. So if you care about a very specific set of features or you care what buttons users are clicking, those are things that you can track using our SDK as well. So, yeah, those are the three services that we decided to introduce WPF and WinForm support first. And that will go ahead and actually show us how to get started. Yeah, if we want to flip over to my machine for a minute. So, if all you did was use the distribution, it seems like that's pretty cool for starters. That's all you did to get the app onto other people's machines easily when they're ready to do it and you just push up the latest build. So if you then make a change to the app, anybody can go get it, they'll get notified if there's updates, right? So you just have a central location that's not sitting on a drive somewhere. Right, that's pretty cool. Yeah, I really do think it changes the way Windows developers can start thinking about shipping this stuff, right? I know we're talking about WinForms and WPF and so we're not necessarily talking about the store and they said there are other broader options out there but I don't think anything targets it with this kind of focus from a really developer-first mindset, right? Our goal is to make developers, as developers, we wanna make other developers' lives easy and this is I think a really good first step for the Windows base. Cool, and people can go to aka.msappcenterwindows to learn more about this. Yep, we'll have links to the documentation and I'm actually gonna just walk us through the initial documentation and just so people can see it, I know as a developer seeing that actually played out is a lot easier than reading the doc sometimes so hopefully this will all work and make sense. Yeah, cool. Cool, so the aka.ms link will take us, so I'm just gonna click everywhere, take us to the Getting Started page which essentially says create an app on App Center, follow a couple steps to integrate it, start making your AshCraft app crash and go from there. And so here I am over in App Center. I have a few apps ready. I'm going to create a brand new app and let's call this VS Toolbox and I'm gonna say it's a Windows app, WPF and add a new app. So UWP is already supported, I see. UWP is partially supported. And we'll actually talk about that at the end. We have plans to get UWP up and running all the way in. But I think right now WPF and WinForms are the furthest along. Okay. Yep, so I'm adding a new app, assuming the network and everything is working. There we go. And so it drops me into the same page we saw when he looking at a few minutes earlier and here on my machine I've got Visual Studio open and I'm just gonna go File, New, start fresh here. All right, I'm gonna create a new project and I wanna do WPF, App Targeting.NET Framework. As Winny said, right now we target.NET Framework standard. We do have changes coming. So in the wild in production today you can use WPF with.NET Framework. Our next SDK release, which I believe is mid to late August, we'll target.NET Core 3 for WPF and WinForms apps. That won't be cross-plat, it's still Windows because that's where the UI framework runs. But we are definitely moving to that kind of OS agnostic platform versions. Right, sweet. All right, so I'm gonna get this app up and running, toolbox, put it in there. And then to get this up and running, I think our main steps are going to be just following the guideline, which is gonna be adding a few new get packages as it says right here. I put this code into the start of my app to initialize the SDK with the information about my app. And that do it in there is your app secret. Yes, that's your actual value. So AppCenter knows which app data is coming from. Correct, where to route it on the back end. So is it actually a secret, or is it just an identifier? So, you know, it's a really good question. It is just an identifier that is named a secret. We don't, I don't think we publish it a lot of places in the UI. I don't think it's a common reference point, but it's a good question, but not a great answer. But if you don't treat it like a secret and people use your ID in their apps, or you use the same ID in multiple apps, then you lose the ability to really know what app caused the problem, right? Certainly, and I think the art... It's a unique identifier for the app. It is, and our intention would be that every time you create a new app here in AppCenter, you would get a new one of these, and you would see it through there. And so I think as you get in and use it, it becomes pretty clear that an app is a sandbox for all the data, the distribution, the diagnostics, the analytics, and so it's really up to you. I mean, theoretically, I suppose, you could have the same app secret in several different executables, but I'm not sure that pattern would make sense for the use cases we've thought of. Maybe there are other use cases out there. All right, so I wanna... You just wanna know how many users you have total and you're too lazy to do the math. Yep. That's one way to go about it. So I've included pre-release on our SDKs right now. The SDKs are in pre-release version, that will be changing. So we're gonna install these. Also, I wanna go ahead and change, I don't remember if I just picked or not wanna change the .NET version to 4.5 because that's what we found out this morning was on your machine. So we wanna make sure this runs as we do it. So I'm installing the crashes. And you'll see that Matt is installing two separate packages because their services are actually modular, meaning if you want a crash reporting tool, not analytics, that's fine. You can just import the crashes and you get package and everything will work just as well. But we do wanna put everything in one spot so it is easier if you do want distribution and diagnostics and analytics all in one. All right. And it would also seem like this would be a handy place to create an extension that just says, set up my app for App Center. Yeah. So it installs the packages, it adds that line of code and then you just copy the secret in and you're the unique identifier and you're ready to go. Yeah, yeah. That's a great idea. We would love to hear more ideas like that. Definitely drop us a feature request, any feedback that you have. We do keep our roadmap and our iteration plans on our public GitHub repo. Okay. So Microsoft slash app center under GitHub, I believe it is. We'll put the official link in the details but all we feature crests, like I said, the roadmap where we're going with things, what's coming when is all on there. Kinda keep that living in transparency. All right, so we've got our two packages installed. So I'm gonna go over to my main window and actually I'm gonna go to my app CS because that's where the start of the app is. And so I'm as developer here, I'm just going to find out which key works on my Mac. That's not it. Let's see. There you go, generate overrides. I don't need all of them. I just need on startup, okay. So I've overridden startup so I can put the app center specific code in there. I'm gonna go copy in the usings, even though we do it for me, I don't trust my keys, my fingers on these keys. And back one more time. Copy it in. Like you said, it's convenient that this is my data and everything is good there. Paste it. All right, I'm gonna go ahead and build real quick before I do anything else to make sure I didn't mess anything up this far that I'll hamstring this later. All right, build worked. So I've got that up and running. And if I run my app, we should see that it starts and it's just a blank window, right? So far nothing particularly noticeable. That's beautiful. I know, this looks like every UI I've ever designed in my life right here. All right. And so the next step, I'm gonna cheat just a little bit rather than trying to type this out from memory because I'm losing mine. Just go ahead and put this in. So let me go to the main windows ammo, bring in a couple of buttons. Now, I don't normally build apps with buttons that say crash them. You know, no judgment if that's your thing, but that makes this easy right here. So I've got the buttons. I've got the code behind. And there we go. Let's get those in there. All right, so we've got all those in and running. And as you can see these three buttons actually exhibit a couple different things in the app center world. So we have a concept of crashes and errors when your application crashes and has to restart, right? If you, I mean a divide by zero error and unhandled deception, right? There is also a concept of what we called handled errors. Think of it as a robust error.log. So rather than the user app crashing you might identify that there was no network connection or you couldn't find the right version of a file on a server, something that is manageable but you wanna know about. We allow you to track as handled errors and see those in that same diagnostics UI. And then they will actually give you the full stack trace and the other memory data at the same time so you can go a little bit deeper than a raw log. So these are up and running. I think I'm going to need to add the, yep. Using the crashes, right? Yep, and I'm just gonna copy it from over here. I'll be on, you can do it. Put that in there. All right, so let's go ahead and run this app. And so this would work from my machine into bug, this will work in release and as we'll see in a little bit we'll send it over to Winnie's machine and it should work over there. So if I come in here and I say throw handled error, I didn't put a new UI in there but we can validate if that did its thing. So when I go back to my app under diagnostics give it just a minute to work its way through the pipes of the internet. And obviously if you don't have connectivity they're all cached and then they get sent up when you're connected. Yes, I believe that's the case for handled errors. It's definitely for crashes. So as we'll see in a minute when an app crashes we actually send it on next restart, right? So what we've learned through our time in the mobile space is that trying to do any processing when something's gone fably wrong in an app is a good way to make things worse. And so we capture a text file actually of what happened. And then when the app next starts it sees if there's a thing there and we'll send that data back center then. When you're back in a healthy state. And so I'll click it a couple more times. It should show up relatively soon. You can do it. There we go, all right. So we see that today we had one error. If I come in here and look at that error that I just got like I said it's in this case this is all the stack trace that was there because that's what we put in there. I see the reports. I can go into this one. I can see this one. So it was running on a virtual machine. See the main thread. I didn't really give it much data here but this is the general idea. And also under analytics I'm gonna see that I had one unique user show up today. And I haven't gone in and done much of the other data, right? I'm just in English, right? There's not a lot of writing here but this is the basic feedback. So the other thing to show then is to see a crash. So in this case it's going to stop the app and when I restart it it will get sent off to App Center, right? Cool. All right, so that's the diagnostics piece but what I think takes this really to another level is being able to ship that over to somebody else. And so with just I hope a few clicks here we can do the same thing on Winnie's machine as in real life and user and see the diagnostics analytics come in. Let's see that. So let's do this. So the easiest way is to just go ahead and publish this app. I'm just publish it to my desktop for now. And let's get it in desktop. Let's make it new folder. Put it in there. Open that. Finish. Let it do its thing. All right, there I am. I'm going to add this folder to a zip file. I'm gonna click in it a couple of times. So it's the virtual thumb drive that we're using in this instance. So we do support MSI. We do support App Action, some other platforms for the sake of this demo. It's the easiest to go. So I'm gonna go over to distribute. If you build it in Azure DevOps can you just point App Center to that build? You can't as of yet. You have to download and bring it over. But that is definitely the flow in fact for a lot of the other platforms that are a little bit further down the road. It just happens automatically. If you build in either Azure DevOps or App Center there's nothing else to do. Right. So we'd like to get to that point here. So you see I haven't sent my app to anybody yet. I'm going to upload the zip. Do it over here. Let's just give it 1.0.0. And then YULI1 is your, this is my app. It doesn't crash. But it does. Works on my box. Yet. So it knows Winnie is engaged in App Center as a tester. I'm gonna send it over. And all right, so you can see this there. So if we can flip back over to Winnie's machine she should get an email in the next minute or two. Right here. It's already there. So I'm very excited to install this app that does not crash. So you'll see it takes me to the install screen. So, see Matt's very truthful comment here. It worked on my box. I'm gonna click download. I'm just going to open it. And then you'll see the app right here. So if I click here, let me just open up the executable. And I didn't bother to do it in any condition. Give me some warning. So yep, so do you trust this as Yahoo? Yeah. Yeah, sure, why not? I'm gonna install that. And now I have the app on my machine. So why don't you give us a handle there and then a crash maybe? All right, let's see. So we hit handle there. Let's do a Stack Overflow Crash. Takes a second because you know, it's gotta run out. And if you open the app back up. Let's see. And then we didn't give you access to the app as a collaborator. So as a tester I don't believe you're able to see all the diagnostics information, right? Because that's my business I've just asked for to test it. So we could flip back to my machine one last time. And I go back into diagnostics. We should see in a minute when they process through the pipeline. That we have a number of crashes and a number of handled errors coming from Winnie's machine. And there's the, you did the Stack Overflow Exception. I did the other one there. And under analytics, we should now see that I have two users coming in and let me know what's going on. So take that and extrapolate it out across tens, thousands. We have apps with millions of users, tens of millions of users. This starts to really just take that distributed debugging. You're talking about historical debugging. Like clearly we're not actually debugging, but we are providing information that will allow you to understand how to prioritize what to fix. And hopefully how to have enough information to know what to fix. Right. That is so cool. Yeah. Awesome. So this is in preview, available for anyone to use. It's out there in the wild today. ak.ms forward slash app center windows for more information. You guys got to check this out, give it a shot and let these guys know how you like it and what new things should go into it. And this is so, this is really cool. Awesome. I'm pretty excited about it as someone who spent a lot of years in this space before I got to App Center. We really are doing things that are not really brought together anywhere else, which is awesome. And with the coming support for Netcore 3, that's another step in the right direction. And we've got some future plans there to take that, I think a little bit further even outside of the UI section, but we're not quite officially there yet. So we'll do that for another day. Cool. Thanks so much for coming on the show. Thank you very much for having us. Thanks for having us. Enjoy this and we will see you next time on Visual Studio Toolbox.