 On today's toolbox, we're going to show you how you can take advantage of the latest Windows 10 features in your existing desktop apps. Hi, welcome to Visual Studio Toolbox. I'm your host, Robert Green, and joining me today is Adam Brayden. Hey, Adam. Hello, Robert. Welcome on the show. Thank you for having me. Adam and I go way back, back to our VB days. Yes. Time on the VB team, and you are now a PM in Windows Land. Yes, on the Windows Developer Platform. Cool. We're going to do a two-parter here. Two-parts. On modernizing desktop apps. Exactly. And this is a topic that we've talked about several times on this show or in conferences. You know, they've been talks at TechEd and Build, et cetera, on how you take your existing apps, which, you know, they're legacy apps because they actually run the business. They work, and you need to maintain them. And how do you move them forward to take advantage of platform changes, whether it's the cloud or new versions of Windows or what have you? Yeah. And it's a topic that always seems to be relevant. Right, right. What we've realized is that our thinking around modernizing apps has evolved. You know, we introduced with Windows 8, Windows 10, the Universal Windows Platform, and we realized that a lot of times people just couldn't write these big monolithic applications to take advantage of all of our cool new features. And so we've really kind of come to this learning that we need to make it more incremental and opt-in so that people can take advantage of the great new features in Windows, but opt-in to their existing applications. That divide was just too hard to cross. And so I kind of got a little bit of graphic here that kind of goes over that. We've spent, you know, the last five, six years building the modern desktop platform. And one of the things it gives you really is kind of that trusted, robust, and secure type functionality that you typically expect on a phone or mobile device. You don't want things, you know, messing with that. At the same time, a lot of these apps are, you know, 10, 20 years old and they have all power and they can do whatever they want. And a lot of enterprises, you own the code, you trust it, you still want to have that kind of power. And so we've been really trying to break that, break down those barriers between the Universal or Windows 10 platform and the legacy of your Win32.NET type platform. So how do you take advantage of new features in the platform without having to throw away an app and start from scratch? Right. And so we're trying to really make that an opt-in model. There's a few things that we tend to talk about in terms of modernizing an application. One of the main things is packaging. How do you actually deploy and build and test your applications? With the introduction of the desktop bridge, which was almost two, two and a half years ago now, we've expanded on that and evolved to what's called MSIx packaging. And that really gives you a trusted clean installation experience. But it also allows abilities to integrate well with Windows 10. And so your apps really can have that full power. We also talk about enhancing your existing app by calling into those Windows 10 APIs. A lot of folks that are in the Win32 or .NET world have kind of been stuck in that set of APIs for the last eight years. It hasn't really changed. I'm going to show you ways that you can call into those Windows 10 APIs really easily. There's ways that you could have done it in the past. And there's ways that Visual Studio sort of doesn't help you if you're a .NET application. And I'm going to show you ways that we're thinking about improving that experience to make it much easier for you to opt into those new APIs. OK, cool. The third area we talk about is .NET Core, .NET Core 3. As you know, .NET Core 3 introduced support for Winforms and WPF on top of Windows desktop. And so now we're seeing a lot of enterprise or interest in folks moving their applications on top of .NET Core 3 because of the performance benefits and packaging benefits. And that's also really where the investment for the .NET team is moving toward. Right. So that's what we're going to cover in part one? Yes. And then part two? Part two will cover some more information around how you can update the UI of your application to take advantage of all the Windows 10 controls that we've offered and built over the last five years. Right now, if your Winforms or WPF dev, you've kind of been stuck for the last 10 years. And you see all the nice, wonderful transitions and animations and fluent design for the controls we've built. And we've introduced some new ways you can interop with those. OK, cool. The second thing we talk about in terms of modernization is integrating with the cloud, specifically Microsoft Graph, and how you can start accessing the graph from your existing client applications. You don't always have to start with just a blank web app. Typically, with Microsoft 365, those that are into an Azure AD environment and SharePoint, you have a ton of context and information up there. And the Graph API makes it easy to access that. OK, cool. That's a little peek into part two. Yep. All right. So part one, let's talk a little bit about packaging and MSIX. OK. I don't know how much you know about the theory of what's going on there, but we have all these different packaging types that we've built up over the last 20 years. ClickOnce, MSI, AppV, and even hand-based scripts and stuff like that. MSIX is really trying to pull all that together into one packaging format and expand upon that. And so they really close the gaps in terms of ClickOnce functionality and some other things. The couple of the key benefits is that it works. Oh, I messed up my dialogue there. It's designed to work for your entire app catalog, whether you're an X copy deployment, ClickOnce deployment, or if you actually want to go to the store, you can also leverage going to the store. The main functionality for MSIX is so that you never regret installing an application. Have you or one of your family members gone to download.com, installed some tool that you thought was really cool and that you wanted? And of course, along comes with it all kinds of spyware or worse. I don't know about you, but my kid is into the game mods. And so that's where the vector for infesting my machine is coming from these days is the game mods. And so MSIX really allows the accountability for managing those applications. Mostly because when you run MSIX, there's no third-party code that's executed. Everything about your app is declared in the OS, validates, and installs it. And that's where it gives it identity. A couple of things it expands on in terms of functionality over other technologies is that it does do automatic updates for you when you publish an app to the server or up to the store or one of your local shares. The MSIX packaging will allow automatic updates. And it also does differential updates. So if you build a package with just a bitmap change, that's the only thing that gets downloaded. So we have a lot of optimizations there. The team is also working on moving it to Windows 7, the packaging format itself. And so we're a lot of functionality that's a blocker for enterprises. And the other last thing is it's integrated with Visual Studio 2017. And so we'll get to some information there to show you. Let me bust out of this. All right. And let's go to Visual Studio and show you what it looks like. So in this application, I have a coupon demo application. This was a demo application for the dev intersection back in December. And what this is is just a simple WinForms app that a registered person may want to sign off on a coupon or register use of a coupon. So I'll show what it does right now. When I run it, I must have touched some code before here. So now it's rebuilding. Apologies for that. And if I enter a code and hit Scan, it brings up the coupon. And it also shows who actually used that coupon. So a very simple application for right now for our purposes. Couple of things you'll notice. It's version 2021. Wow. Don't feel like you need to go rush. Couple of things you'll notice is that there's an icon associated with it down here in the taskbar. And if I bring up the task manager, you'll see coupon.forms.exe. And in Task Manager, I've enabled this column here called package name. And a package name signifies that the app is managing the installation of this app. So I mentioned that Visual Studio has made this really easy to add support for packaging your application. You might have done something similar with desktop bridge episodes. But essentially, you're going to add a new project type under the Windows Universal heading. You'll see there's a Windows application packaging project. And we'll give this a name. I'll call it coupon.package. And now it's asking me, what version of Windows 10 do you want to target this package for? Because later in the demo, I'm going to do something that requires a little bit newer version. I'll just kind of keep it to the latest 1809 version. But I could go back all the way to 1709 and 1703. All right, so now in this packaging project, you'll notice that there's this application node. This is kind of the key here. It really tells you what applications you want to package. I could have packaged more than one if I had multiple executables. So out of reference, it obviously looks at all the outputs in my solution. You only can choose the executable types and add those. And step one, I could hit F5 right now, and it would work. One of the things, though, with the packaging project, in order to get all these great tile assets for the task bar or your start menu, you can generate visual assets to have a deeper integrated experience. And you do that through the manifest designer. So if I open up this manifest designer, you'll see the visual assets. And I can generate visual assets based on an image in my solution. And I hit Generate. It's going to replace some default assets, which are just some simple Xs type of thing. And we can see that it generated a bunch of assets here. So this whole concept is familiar to anybody. It's written a UWP app, right? Right, right. This is the same thing as what you'd see for UWP. Couple of things, if you want to view the code of the package designer, got to say that. You'll see that here's the identity of my application. And so that's how the OS knows to manage it. I've given my app identity. The other thing to call out here is that it has this full trust capability. I mean, I'm going to run a Win32 application. So what I can do now is set this as the startup project. And if I hit F5, it's going to build that application, the Win32 app. It's going to package it up into an MSIX package. It'll deploy that application and install it locally here for my machine, and then launch it. And you'll see it looks pretty much like the same application. You'll notice that the tile down low is a little bit different based on the visual assets. And it should behave exactly the same. And I get it loaded there. And remember, I mentioned about package name. If I go back to Task Manager, you'll see that it's now packaged. So that's kind of step one. Now I have this clean and trusted install and uninstall experience. The user's easily in control. So that makes it easier to uninstall, right? Because you can just go into this. It's on the start menu, presumably. Yep, you'll see it here under Recently Outed Packaged. And then you can right click and uninstall from there. Exactly, I could right click and uninstall. As well as pin to start. Yep, cool. And so that's an example of packaging and application and how easy it is to do inside of Visual Studio. Cool, cool. And then I could, what would I give somebody to install that on their machine? Is there just a single file for the setup? Right, what you do next is it's a little buried under this store menu. We're thinking of updating that experience down the future. But you create an app package. What I showed is the F5 experience. Here is where you would want to either create a package for side loading or upload to the store, choose Next. You can choose what type of architectures you want to do. And it'll build an MSIX package. That takes a little bit of time to go rebuild everything and then package it up. So I think for the purposes of this, we'll leave that to the next step. But there's also a choice there to send it up to the store. Yes, okay. You can associate the app with the store and then be able to upload the AppX upload package to the store. Cool. And that's what if you, previously with folks with the desktop bridge or Project Centennial, this is kind of the evolution of that. Okay, nice. So that's step one is packaging in terms of moving your app forward to a modern packaging and deployment pipeline. And then there's still the concept of the internal store, right? Yeah, internal or business store. Enterprises may use that and they can publish to that internal store. You can also publish with the new features. You can publish to just a share if your company just has a file share location that all the apps go check and phone home or whatever to download the latest updates. Okay, cool. Very cool. The next thing we talked about was really the calling the Windows 10 APIs. Some of the features that a lot of apps are interested in doing or highlight for Windows 10 applications is typically things like toast notifications or maybe Windows timeline if you wanted to provide a deep link experience on Windows timeline. A third area we see is Windows Hello. Windows Hello does the biometric verification or pin verification for you so you can confirm that the person at the keyboard is the same as the person that originally logged into the machine to prevent those situations where somebody important steps away to go get coffee or the bathroom and then they go approve an expense report. Okay. Right? Or someone else comes in to approve the expense report. Or sends an email to Satya. Exactly. So we don't want to allow that in our application. So what I've done in this example here, the first thing you have to do is reference the Windows 10 APIs. And there's currently an existing way and then we're working on an improved method. Where you might typically find it is through the ad reference dialogue, right? And browse. However, look at this, Windows.WinMD is the metadata for all the new Windows APIs. But there's not an easy way to reference it inside Visual Studio. You actually have to go into this folder, into this union metadata folder and the version and go pick the Windows.WinMD there. I've already done this before so it shows up in my most recently used list. But you can see if your first time using this it's kind of hard and it's a pain in the butt to always go and find things. And know which one to find. And know which one to find. How do you know it's the WinMD as opposed to the Runtime DLL? Okay, so the WinMD is the metadata for the APIs. The system.Runtime.WindowsRuntime, this is the interop assemblies. Because Windows 10 has a new set of APIs, the concept, and it's based on .NET Core, an early version of .NET Core, how that interops with .NET Framework, specifically around things like async patterns and various other APIs. It kind of, this interop assembly sort of manages that interop between those two different frameworks, the framework and .NET Core. And so typically whenever you call a Windows API, you'd need the Windows reference and the system.Runtime.WindowsRuntime reference. So for now, I'll add those references manually this way and then later I'll show you an improved way. But to get to the point of like, let's call some APIs and see what they do. Remember I mentioned, let's work with Windows Hello. Right? So there's this, let me uncomment some code here. There's an API called the user consent verifier. And I need to fix my credentials. I might as well just do all those for next. Ah, for the following APIs. So the user consent verifier is what pops up either the biometric or the pin code. And what this API says, does this, first you have to check and see if the device supports this behavior. So that's why I'm checking the availability of the user consent verifier. And then I create a dialogue saying what we wanna do. And then that dialogue returns a result. My app doesn't control anything that happens in that dialogue. That's all the OS. So it's brokered by the OS. We just get the result of whether it passed or failed. And so I'll call that and we'll display the results in the UI. Now you notice two things here. Oh, I should show this, could show this to it. Right now it's actually building the Win32.NET application and then it's repackaging it in the package. I could show this application running without packaging as well. But you see, it's popped up the security dialogue that's brokered by the OS. And I gotta enter my pin and I'm verified. Nice. So you might do that if you had a workflow where you were approving purchase orders or something really important on the machine. Yep. That's an API that'll actually work without packaging. Many APIs in Windows 10 actually work just fine without packaging. They're typically attributed with a default attribute or sorry, dual API partition attribute. And that's what signifies whether or not it can be called from .NET or has to be called from UWP. Okay. There are certain APIs that require certain concepts to be available on the system to call them. And there are certain APIs that require identity as one of those concepts and core window or the UWP windowing is the other concept. For, we're in luck because packaging actually provides identity for APIs that require identity. And an example of that would be the toast notifications. Right, when you pop up a toast that shows up in the action center down here. Yep. There's some Chrome around that that says this toast is popped by this application. And I think the idea there is to prevent spoofing so that some app can't pretend to be Bank of America and get you to enter in some credentials. Okay. And so let's go through and show you how to call those APIs. I will comment out the user consent verifier just cause it gets a little bit annoying to do that every time we come in. But let's call showing toast and integrating with Windows Timeline. So if I do the toast notifications, let me go ahead and uncomment this code. But a toast notification is really just an XML blob, right? With some pointers to some information like a URL to load a picture. And then you create that toast or that XML blob and then this call register it with the toast notification manager which is the brokering with the OS. So that's the toast part of it. If we look at Windows Timeline, Windows Timeline has something similar where you create a channel to the timeline essentially. You write some information that says what my timeline activity is. And here is gonna be the caption or the title for that timeline activity. And then you create this session which registers the timeline activity. So it's all fairly straightforward. Both of them usually you register some information and then hand off to the manager or the brokering APIs. But in order for that app to trust you and show that information, that's where you need identity. So I'm gonna actually show the unregistered or the non-packaged app first and show you that it fails. So if I hit F5, it's gonna build and when I scan a code, we'll get a runtime error. You'll typically see this element not found is a common error you'll get when you call an API that requires identity. So we'll cancel that. And this time I'll set my package as a startup project and build that. Let's see, I see the icons different. So it's the right one and choose scan. Ah, darn it, I'm presenting. And so notification is the popup part is turned off. But if I actually open it up, you'll see that it showed up in the activity center. Nice, cool. So this was kind of registering that a coupon was scanned. Yep. Now I promised you a second thing I have Windows Timeline. Windows Timeline, if you hit Windows Tab, you bring up the Timeline dialog and if you scroll down and show all the activities, you'll see here in the middle that I have my application registered with Windows Timeline. Nice. And if I click that, then it would launch my application into the foreground. Okay. So you can kind of pick up where you left off based on that time in your Timeline. So. So it stores the state or it just goes back to the app, which is already open. If the app was shut down, oh sorry, in the, you register a URI. Okay. Right, this code right here. To register with Timeline. And then what your app does with that is up to you. Usually you put information as to where you were or what you were doing at that point in time. And then you can kind of pick up with that activation and run your app appropriately. Okay. So that's similar to what we originally learned how to do. I think in Windows 8 apps, where you'd put code in, I think it was on suspend to save the state. Yes. And then when you started the app, you could check to see if it had started because it was resuming. Resumed. From a suspended state. A new word. And then you could go read state. So you'd have a similar event model here even in a win form that you could tap into. Exactly. So now we brought a lot of that power to win 32. There's still work to do on the long-term roadmap for suspended resume behavior from a win 32 app. There's some power challenges around that. But integrating with some of these Windows 10 features like notifications and toasts and Windows Timeline, you can now easily do. And if you got really good at it, you could roam the state, right? Yeah. Well, your Timeline settings roam? Your Timeline settings will roam. I'm not showing that part of the graph integration, but you can do graph notifications as well. And they've done some improvements in the graph notifications where if you dismiss on say your phone or mobile device, it dismisses everywhere. That's one of the frustrating things is like you dismiss on your mobile and then you open up your laptop or Mac or something and you see more notifications there. Right. So, cool. But yeah, I think we're happy and glad to be able to provide some of this power now to the win 32 and .NET applications. Right, very nice. So for part one, we've talked about so far packaging for trusted deployment. We've also talked about calling various Windows 10 APIs. And there's like over 6,000 classes you can call and it's everything from Bluetooth, lots of device APIs, lots of machine learning, and then some of these deep windows shell integration features like notifications and whatnot. You can do the live tiles and the basic stuff. Yeah, live tiles, yeah. So you can kind of explore and now use those from your win 32 apps. The third thing we mentioned on here though is kind of the newness of .NET Core 3 and bringing these apps to WinForm, or bringing WinForms and WPF apps to .NET Core 3. So, what I'm going to show is the, or what I have here is Visual Studio 2019 preview. Okay. Preview 2, because it has better support for .NET Core 3 applications. And what I've done is taken the existing .NET or coupon app and essentially copied it over into a .NET Core 3 project. One of the things I'll show you about the project system is that it's a lot simpler than the existing .NET framework project system. Essentially, you just have some, a very simple property groups. This here tells you that you're targeting .NET Core 3 instead of say .NET Core 2.0 or something like that. And it uses package references. Package references is something we're exploring for the Windows SDK. And we have kind of an internal prototype, which I'm sort of showing here, but we hope to have that come up with a plan to release that publicly soon. Okay. And we'd love feedback on this. This is not something that we're, you know, hush-hush, lots of people have asked for a better way to get access to the Windows SDK. There's obviously many gigabytes of data and binaries and files in the SDK. And so we got to figure out the right way to break that up. But a starting point is the Windows 10 API metadata for managed apps. And I'll show a little bit more about that here in a second. Yeah, and so then I have some other item groups about some images in this application. But this, the CS project file being able to easily open and edit that and simplifying that is one of the big benefits of .NET Core 3 going forward. And the other thing it promises is to integrate better with the Windows 10 APIs. So let me show you my NuGet packages. Yeah, and so we've experimented with this Windows, we're experimenting with the windows.sdk.contracts, which is the metadata so I can easily just have a NuGet experience based on this contract. And that'll save me from having to search my file system for the correct APIs right now. It's just right there in NuGet. I have a private feed so I can search for it and install it. When we're ready, we'll make it public and get some feedback from folks. Okay, APIs that require identity, I think we'll hold off on those. But at first I wanted to show you calling a Windows 10 API and the same app on .NET Core. The API that I'm doing this time is a little bit different. It's the geo locator API just to say what's my current position. It doesn't require identity. So you'll notice that I have just a non-packaged application here. And when I run this and scan a code, it says coupon redeemed at this location. So I've called a Windows 10 API. There is a curtain bug right now with loading bitmaps. I gotta go follow up with the .NET Core 3 team as to what happens, because .NET Core 3 is still in preview. But you can tell that I'm running on, or you can see that this is .NET Core app behaves the exact same. Did you have to change any of the code in there? Is it the exact same code? This was a pretty simple application. So it really was just copy and paste the forms into the app and set the startup to the appropriate form. Okay, and in terms of calling the Win 10 API, that code that you write would be the same? The code is exactly the same. It's just a lot easier to go find it and add it. You just are able to add it as a Nougat package as opposed to having to hunt down various MD files and whatnot on the machine. Exactly, exactly. You don't have to grovel through your file system to find the right references anymore. Yeah. The thing that Visual Studio Preview 2 supports is the packaging project. Earlier versions of Visual Studio did not support that for .NET Core 3, but now with the latest 2019 Preview 2, it does support the packaging project. So I can show that. We can add a new project to this solution. And I can go to, if you haven't seen this dialogue yet, it's easy to sort. And so I can add the packaging project there. I'll call this couponcore.package. And because I'm calling some Windows 10 APIs that require the same version, I'll go ahead and set that up. And we see we have the manifest designer as well. Yep. Or this is the project property state, but if I go down here to the package, add reference, select the output of my core application. I could generate the images as well, but for the sake of speed, we'll just go ahead and skip that part. Set this as the startup project and run it. And so now it's building the win32.NET Core 3 up. And, oh, I hit an error. Uh-oh. We need to rebuild all here. And I know that ASP core apps or web apps are faster. Do we find similar, do we find performance benefits with the desktop apps? Or is it more about the interoperability? What winds up being primary? There's various reasons as to why someone may want to move to.NET Core 3. They either want to be on top of the latest innovations in the.NET Core platform. Performance is a big part of it as well. .NET Core also adds support for a single file executable so they optimize in all the dependencies into a single file executable. So there are packaging improvements as well. Let's see here. I'm getting an error in my sample and I realize what it is, but there's a certain tag I gotta put in the project system. I can't remember what it is off the top of my head. Okay. So we'll have to go ahead and skip that part. That's fine. It would then work the same way the previous one did. Yeah, I think that's one of the rough edges we're still figuring out. I think it was like a run time targets for when x86 and x64, so. No worries. Yeah. But so yeah, so we have essentially shown the .NET Core 3 app, which is taking an existing application and running on top of the .NET Core 3 run time and calling Windows 10 APIs. Cool. So that brings us to the end of part one, is that right? Yes it is. All right. So we've seen some really cool things that you can do and I think the key thing here is that these are all things that you can add incrementally to your existing apps. The whole goal all along has been to make it easy for you to take advantage of enhancements and advances in the platform without assuming that you're going to rewrite the entire app from scratch. Correct. And I've seen Centennial and stuff before and this absolutely looks much easier, more seamless with really good support inside the product. Yep, this is really kind of incrementally moving and adopting new functionality in your existing apps and we're really trying to break down those barriers. You know, if people run into something that they can't use that they want to use, let us know and we'll figure out how to work on a solution there. Cool. All right, hope you guys enjoyed that and we'll be back for part two. All right, thank you. See you next time on Visual Studio Toolbox.