Embedded Player

Supporting The Show

If this episode was interesting or useful to you, please consider supporting the show with one of the above options.

Episode Transcription

Hello everyone and welcome to THE .NET Core podcast - the only podcast which is devoted to:

  • .NET Core
  • ASP.NET Core
  • EF Core
  • SignalR

and not forgetting The .NET Core community, itself.

I am your host, Jamie "GaProgMan" Taylor, and this is episode 33: .NET Core 3.0, MSIX and The Windows Store James Montemagno. In this episode of The .NET Core podcast we In this episode I interviewed James about his work dog fooding most of the technologies we’ve all used, from Xamarin to .NET Core. We also talked about releasing apps using preview bits, MSIX, and the Windows Store. Some of you may know James from his work at Xamarin, Microsoft, or from his podcasts: Merge Conflict and Nintendo Dispatch

So lets sit back, open up a terminal, type in dotnet new podcast and let the show begin.

James' Introduction


Thank you ever so much for being on the show. James, I really appreciate you taking the time to come and chat with me today, because obviously, you know, we're all really busy and, you've got 1,200,000 podcasts or something.


That's a pretty accurate number, I would say roughly roughly. And they seem to grow once a week or so.


Hey, yeah, I can totally understand that. Yeah, I don't know how professional you are when you're recording, but you certainly sound incredibly professional when it's edited together and I just, I can't even imagine how long it takes to get that sort of feel for the show. So editing all of those podcasts must take forever.


Yeah, it's strange. When I got started of podcasting, probably a decade ago or so, I really toyed around with it. I never really took it super serious. And then when Frank and I started doing Merge Conflicts, I guess almost three years ago now, I had just started working at Microsoft or just about to get started working at Microsoft's through the acquisition of Xamarin, and I knew that with all the travel that I did and all of the development and all the program management, I had all the other. "All the things". Basically, I knew there's gonna be no way that I could sit down for hours to edit a podcast.

Additionally, I'm sure you're aware, like there's a lot of things that go into podcast production, and if you want to pay somebody to edit a podcast, that costs a lot of money overall. I mean it's not crazy amounts of money, but it's money. And when you record 52 shows, even if that's $100 an episode. That's $5000 like it's just really expensive and I don't have $5000 sitting around to do podcast editing. So I told Frank, "There's a few different ways that we can record this podcast," because I've been on ones that take, you know, three or four or five or six hours to edit it. I said, We're gonna do this podcast. You know, I know the beginning. It'll be rough, but we're going to do "live to tape" and live to tape just means when we record it, if it's in the recording, it's in the podcast.

My mentality is, "how do I spend the same amount of time that we recorded it on editing?" So if we do a podcast that's 40 minutes, that episode will take me 40 minutes from start to finish, including uploading, show notes, everything. So that's sort of how I've done it. So normally, what you hear on the podcast is actually what we recorded in real time, with very minimal, I mean there's very minimal tweaks and every once in a while. But after 156 episodes with the same person That's the key, right? It's hard with guests, and I'm sure you're aware because you have guests on all the time. That's the hard part, guests and multiple people. But when you're doing it with the same person for 150 episodes, it's sort of like clockwork.


Yeah. I can totally imagine that you get into sort of like a flow and you know, roughly, what the other person is going to talk about before you talk about it.

Yeah, you kind of start to get their cadence a little bit and they get your cadence and it's something that ends up becoming very natural. And there's a few other podcasts I do where it takes a little bit more time because every person is a little bit different overall, but we're starting to do some live streaming now, and that's going very well. When you see the person you can really tell when they've finished talking and when you can kind of take over and things like that, so it's quite quite enjoyable. I still love doing it after 3 years and so many episodes, so it's going well.

Why I got started podcasting, I know this isn't the topic that your asked me to come on (for), but I really did it because, especially after moving to Seattle there's a thing called the Seattle freeze. Where people stop talking to people, and we're all kind of in our own little igloo and just our own little bubble, especially when it gets cold. A lot of my friends live in Arizona. New York. Even Frank; he lives two miles away from me, and I'll never see him. Like, hardly ever. Now that we don't like seeing people just like we just naturally stay indoors to ourselves or with our own, your significant other. So why do the podcast? Half the reason is, of course, that I love doing it. Talking about technology, but it's also like two hours that I get to talk to one of my best friends in the entire world and get to catch up more than anything. So it's that nice, enjoyable, part of the week. It's like me hopping on a phone call and talking to my parents for an hour. So I kind of get that same joy out of it.


Yeah, that's cool. I totally appreciate that. I know that a large percentage of my friends live miles away from me. And if I could do the same thing, I would. But I don't think we can recreate the feeling of going down to the pub, having loads of drinks, eating lots of food, and then falling home in audio format.


I mean, you could. It would not be probably one of the best podcast productions ever, but yeah, it's definitely not the same.


Okay, so thanks for that at the top. SOME top advice for budding podcasters, I guess.


Yeah, for sure!

Excellent. So I guess we're a couple of minutes in already and unless people have looked at the title of the episode, they may not know who I'm actually talking to. So I was wondering, could you give us a brief introduction so that the listeners know sort of who you are, the work you do.


Sure. Yeah, and I love it when a podcast opens and you don't even know the other person or like starting us. I like to start presentations that I do. I will not even mention my name like through the entire day because I'm just a person. You just came to hear me talk, right? Um, I'm just just a voice.

I'm James Montermagno. So I'm, a principal program manager over at Microsoft, and I overlook all of our mobile tools in the Xamarin space. So what that means is a few things. My focus is on community initiatives first and foremost and an oversight on the product.

So I worked with a lot of the different development teams that are working on SDKs and toolings. Same with our program managers that are interacting with our customers, also with our community members that are running user groups doing events. Um, you know, go out. And I present at conferences, do workshops, all around Xamarin. so mobile development with C sharp for ios and android.

And I'm a long time Microsoft developer, so not only when we talk about Xamarin, we talk about all the other things you can build .Net. So WinForms, WPF, ASP .Net.6, you know, Mac applications, server applications, things like that. And I came to Microsoft through working at Xamarin, where I was a developer advocate focusing on technology. I was there for three and 1/2 years, have now been at Microsoft for three years. And before that, I was a customer of Xamarin, so I moved to Seattle eight years ago went to go work at a startup building, all their mobile apps with Xamarin. Went to Xamarin and now at Microsoft. And now I'm here.


just hearing that trajectory. I mean you dog fooded in the product that you're helping to innovate, I guess.


Yeah, the reason I wanted to work at Xamarin was because I've been, like I said, a long time .Net developer and used to work at Cannon working on printer software. That was my first job out of college, which I loved. I did that for four years and it was all .Net. Um, I got to do a lot of WinForms, but I got to move into WPF, Silverlight. Um, WCF services, more advanced scenarios. And then I found mobile and I fell in love. And I got lucky that the startup I worked for out in Seattle right after I left Cannon let me pick whatever technology I wanted. I really fell in love with Xamarin because I was a C# developer, .Net developer and I now can build mobile apps for the android phone in my pocket, which I thought was so cool.

Yeah, I really fell in love with the product so much that when the opportunity came up, I got lucky. A recruiter randomly I don't know if they read a blog or I emailed them sometime, had reached out to me, and it was sort of this dream opportunity to go and not necessarily work on the product that I love, but still use the product and help other people be successful with the product. So it was like combining all those passions all into one type of job while still being able, to if I wanted to contribute to the product because it's open source and you can do whatever you want so.

Being at the Forefront


I do know from preparing for these kinds of interviews, I look into, guests kind of online presence. you know what They're what they're about and some of the projects they've worked on. I have to say that, looking at some of your projects, it looks like you've used a lot of New technology's just as they've been sort of coming to the forefront. I mean, you mentioned that you got to he's Xamarin and then stay in that sort of .Net, C# space pretty early on to create these app for your mobile devices. I see that you've produced a one or two xbox 360 games. And you know, most recently, I think you've been working on something with .Net Core preview three and releasing it to the store as well, which is interesting. You know, this preview level stuff. Let's just get it out there and and show people how to use it and get it out in the store. That's interesting to me.


yeah, I guess I got really lucky going into mobile as early as I did 8-9 years ago, I started mobile development with the very first Windows phone, So phone 7. and that really took off. And then I obviously spiraled into ios and android did all the windows stuff along the way. I guess maybe mobile trained me, to Always be on the forefront.

Frank and I, We always joke. We have literally the same podcast every year, which is around May June timeframe, which is when Google IO an WWDC comes out, at Google and Apple's developer conferences and BUILD too, it's in there. So it's all three of them is. We call it the Beta Summers because you need to spend the entire summer. Updating all of your machines to the Beta OS's to the beta versions of Visual Studio, Xcode and Xamarin and Android studio and all these things and update and prep your applications to be on the latest. You're always sort of having to keep up with the platform as things air grinding away because, you know, our phones are just updating all the time. You have to stay on there and coming to Microsoft. We have a really great internal dog fooding, um, it's not a policy, but it's highly encouraged, to dog food. By dog fooding, I mean, just you're testing your own product that you're building while in development, and for a long time that was really hard for me because I couldn't dog food a lot of the products because I was out there presenting the product. So it's really hard for me to be using internal bits that aren't maybe 120% stable because, you know, I need to present it in and often I can't show those features.

So what I do a lot in the advocacy space is attempt to stay up to date with whatever is happening. But as soon as there's a public preview of anything available, I want to take advantage of it. I just wanna go to town and really try to give that early feedback from the user's perspective because as you're getting hands on the bits and starting to give feedback, I want to be there to go through the same things that the developers that are using our products go through.

And I think that's a theme that I see with all of our development teams and all of our PM teams at Microsoft. They're really actively involved, not only in building the product but using the product from the the customer perspective, if you will.

So, yeah, I've been, recently heavily, working in and around .Net Core 3 and, of course, very excited about .Net Core 5 as you go into 2020.

But to me, I started as a desktop developer, and I moved on to mobile development but always still had a strong passion for doing a lot of things on the desktop. And when I got into streaming, often I found that there was kind of a lack of desktop tools, or there were desktop tools to help streamers, like to do live code streaming on twitch, there was sort lack of desktop tools, or there were very complex things.

So as a developer, you go when you try to find things that will help you like "I need this countdown thing" or "I need this music thing" or whatnot and they either exist or they don't exist, and if they exist, they're probably not exactly what you want. So then you go and develop it yourself like this what I'm gonna make? And I started to develop a new application for the desktop and I said, I'm going to use WPF. And I'm gonna use .Net Core 3 and I'm gonna try to ship it to the store. And I did, and I was it was a journey. I would say.


That's amazing, because, like you were saying, you know, you are then dog fooding that entire process. Not just building an app, but also pushing it to the store and let's see what the experience is like with pushing it to the store. And then "I can give feedback", I guess, both in a wildly public whilst on your stream and a slightly more private nature. I mean, I'm presuming there'll be things that you will say to your colleagues in a 1-1 or in an email or something that you may not say on a live stream, But you were able to give that feedback. And I guess with the live stream nature, you can actually point your colleagues who work on those those applications of frameworks and tools and stuff at the video and say, "Actually, if you skip 25 minutes and you will see the actual problem that I have and you'll be able to recreate it",

I guess that's probably one of the greatest ways to log a bug report, I guess.

Actually, go watch me recreate the bug.


Yeah, it's very true. And the entire program management team and the development team to have gotten really into, um, the live streaming process for a lot of that reason. It's a lot of fun and great to interact with the amazing community around .Net.

David %Orton% now, for instance. He's one of our program managers. For all things Xamarin SDKs. He does a great job because he has community guests on all the time. And you realize really fast every developer is very different in the tools they use, the setup they use, the packages they use, and you get to see how people use the IDEs. How they use the tool, and you get to sort of live their struggles.

Sometimes there's none of those sort of things. It's super gravy, and it's all great, you know. But sometimes you see those struggles and yeah, you got immediately that feedback. You can ask them questions, and then at the same time you're you're learning a lot, the communities learning a lot. And you also get to highlight the awesome community members.

So it's been a lot of fun to learn those examples, and often I'll get developers like If I'm doing a ASP .Net Core work, often I'll see asp dot net team members in the twitch stream, and they want to see right? Because it's when you're doing, it's almost free research in a way. Being able to say, "Come watch me. I'm not an expert in this field, but I know dot net, and I'm going try to do this"

What's been cool about that process is the now being able to give that feedback to the team. But when I see something wrong, as I'm going through it, like in the documentation, I'll just do the pull request live and I just get the feedback out there as soon as possible. So it's quite enjoyable,


I can imagine that it is.

So I haven't, full disclosure, been able to watch your stream yet, but I have seen Jeff Fritz's streams, and they are amazing. You know, sometimes he'll say, "Okay, friends, we're gonna learn to do this today!" or sometimes he'll say, "So here I am building this thing. These are the git commands I'm going to issue to actually do this pull request." Or maybe he'll sit and look through issues.

Things like that and it's just it's amazing to see that coming out of such a big company that has such high standards. Knowing that there is this ultimately free resource to learn all of these techniques, being able to watch a stream with yourself or if I do one that is good. Or you know, Jeff or anyone who's doing these live streams of being to go, "Ah! That's how you do a pull request" and then being able to interact directly and go, "Okay, I don't quite get it what this is about. Can you just explain it?" and then having yourself or Jeff or whoever stop for a moment and go, "Right, OK, now we're gonna talk about this because, you know, someone has asked about it in the chat, and I'm gonna talk you %through% it."

It's kind of like a group tutorial, I guess. I don't know whether you had those back at your college where you could all sit together and learn something together.


Yeah. We kind of have them in. It was a limited, definitely not as interactive right?

It's almost like live pair programming. We have this team that Jeff helped curate together on Twitch called Live Coders. You can go to livecoders.dev And there's this team. Right now it's about 61 different live streamers that do development. Not necessarily all .Net development, like Brian Clark right now is streaming like Node.js and JavaScript. And later today I'll do some Xamarin and work. But there's all sorts of different types of development in that space. So you can go in and you can learn.

It's this nice little community of learning. Even yesterday, I was kind of bored, and I was in one of my colleagues, Kim Philpot's streams and he was working on some stuff, and I'm chatting to him live in the twitch stream and, I was like, "I would do it this way, right? I would do it this way," and I'm like, "You know what? Just send me a Visual Studio Live Share link, and I'll just hop on a slack call really quick and I'll just do it with you, live!"

It was crazy and it was fun to see the chat room. Like now all of a sudden, James is pair programming via this live stream and interacting with the chat room. These were technologies didn't exist, you know before.

So it's this really crazy, different, interactive way of learning. Like I just hopped on Kim's Stream randomly and taught him something. I think that the fun of it is getting people together and doing that pair programming. Even though Kim lives in Australia, you know, and I'm over here in Seattle. It's his morning and my night, and you could just hop in and do this stuff. It's quite a joy.


It is amazing. And like you say when you pair it with things like Visual Studio live share where you can just jump into someone else's session and sort of %move% the character around on make changes. And then I believe you can hit F5 five and set up A SSH tunnel between the machines and send the debug symbols down and Breakpoints on the remote machine whilst running it on your machine.

It's just this magic is wizardry is what it is.


It surely is. Yeah, it's pretty crazy.

Using Preview Bits in Production


I'm just wondering if we could talk a little bit about .Net Core 3, then the previews that you've been playing with, and maybe some of the features that are your most favorite features that you've been playing with that are coming to .Net Core 3 that may not have bean in .Net Core 2.



Well, let me set up the scenario here because part of what people actually came to listen in about, not me streaming and podcasting. But it all goes together because the stream is the reason I did this right?

So allow me to paint a picture. There's a program that everyone uses to stream. It's called OBS, Open Broadcast Software, and there's different flavors of it. But, it's a very complex, amazing application, and when people start their stream, you'll start sending a stream out to Twitch or YouTube or mixer. But it takes a few minutes to propagate that stream now onto the servers, and out to any of your notifications to subscribers, and what most streamers do is they'll start the stream and they have a countdown timer or some sort of starting soon.

And there are tons of countdown timers that are out there. But nothing was in the store. Nothing was super elegant or beautiful, and nothing did exactly what I wanted it to do. I wanted to integrate it into my entire setup process. So when I go live, I press a button and it does like 20 things. It launches the software, it starts the stream, it does the tweets. It starts my music. It does everything for me. So I wanted to be able to use that in my applications. I wanted command line arguments to pass into my application so I could boot it from anywhere and I knew I wasn't going %to% be able to do that via, like, a website or or things like that. So I wanted to be shared, but I didn't have a server, I'm already on the desktop. So a desktop application makes sense to me.

So I had a few thoughts going into this one I could create a UWP app. Or maybe a UWP app with Xamarin forms as a UI layer so if I wanted to, I could go to like, %um%, you know, Mac or something like that or another platform. Um and then I thought, "Well, I want this to be general purpose. I want this to run on Windows 7 and Windows 8." That was my goal, because I know there's probably some streamers, well I have already had requests come in to support older operating systems. Although everyone should just run Windows 10. And then everything would work a lot easier for developers, I guess. But I said, "I'm gonna build a WPF app because I haven't built a WPF app in a long time, and I was like, I'm just gonna I'm just gonna go to town. I've done a lot of WPF, and I know there is a great ecosystem out there of UI toolkits like I used MAH Apps, which gave me a great look and feel to the application. So I want to have some tabs %that% you could count up. You could count down, you could have a giveaway, you could add minutes. And the whole concept of the app is that while the countdown is happening, it says, you know, starting in and counts down every second. And that writes that information to disk. So just to a text file and then with OBS, you can have a label that reads from the text and updates and it has a file watcher, basically, whenever that file changes, it will reload that into you, I And then when the countdown is done, you display a message. So there's like, some things in there and again, you could launch this via some sort of URL.

So WPF sort of made sense for me at the time. I was like, "I can redistribute this. I %can% just give someone a .exe and boom good to go.

Just like most developers do, like I just started. And I said, I'll just, you know, use the latest and greatest technology and why not used .Net Core 3 because I know that somehow in the future I could distribute this to Windows 7 & 8 because that's what they told me I could do. That's what the vision was coming out with this new sort of bundling software called MSIX. And when I first started, I didn't even think about MSIX. I just didn't even know. I'll just package it up And you use something like an .exe that you download from the Internet, which is bad, right"? Here's a random .exe".

How do you do updates, right? I'm like, "Oh, man, how do you do updates?" Everyone's like, "Oh, just use squirrel." And I was like, "I'm going to have to have a server. It's going to get complicated, overall. I don't want to do .exe's. I don't want to manage updates. This is the (type of) things that you forget about When you first start doing development, you're like, "Oh, I how do I deliver updates to people?"

So the cool part is I watched this video on Channel9 and on YouTube it was one of the .Net shows that we have on MSIX, which is this new sort of at packaging format for Windows. And the whole idea of it is to give the very common sort of packaging appx format that you WP Apps have to deliver to the store for any win32 WPF or Winforms apps and that will be available via .Net Core 3. So, with .Net Core 3, you can either package with MSIX or you don't have to. You can just, like published to a folder like you would always do in WPF and for WinForms days. But then you don't have an update process there at all like you are just delivering .exe's. But the cool thing with MSIX is that it works with any application, and I believe regardless of if its .Net Core 3 or not, but you can have it create an entire website for you that does automatic updates and will deliver either every time the user launches the application, or nightly or whatever. It just shows up inside of your desktop app inside of it. And you can also, at the same time distribute to the store.

So I'm thinking "All right. There's no way I'm going to do my own update server. I'm not gonna deliver to a folder and have to create a website. I want this thing to be is easy for people to get. So Microsoft store that makes so much sense Automatic updates. I love that. And the cool part here is that when you use this MSIX at least on Windows 10 you get special Windows 10 features like being able to launch your application via URI, which is really cool. So you sort of start to get some of the Windows 10 specific features inside of your application when you're bundling the app up into this. So that's a very long explanation of why I did it. What technologies I use and then how and why What I got out of it, I guess. Does that make sense?


It makes perfect sense. I do like that. you took the route off which tools can I use to make my whole release process more productive for it. Because as developers, we provide productivity to other people. We developed tools, we develop software, we developed websites, we develop apps, games, whatever it is that allow people to be more productive. So why spend all of your time, like you were saying, building a server and figuring out how to do auto-updates myself when there is something out there that that have rather large corporation, that has probably thought about it a lot more than I could. I mean, I'm speaking for myself here. They are people who collectively are a lot more intelligent than I am who have already figured this out? They've already solved this problem. So why not just leverage that and then in the future, maybe if I want to move it from the store, put it somewhere else or invent my own way, I can, but for now, it gets it, into the hands of people.

I keep saying this. I've said this on a lot of podcast episode so far. There's a quote in the Phoenix project that says "until the product you are working on is in the hands off the people who will use it, it's not generating any value".

Now obviously you could have your own definition for value. But until somebody is using it, there's no value to it,


You know, from a purely this thing that I'm creating will give someone joy will give someone productivity will give someone something. Well, it's not giving them that thing until they get it.


Yeah, it's true. Yeah, I think that for me, it was a great learning experience because I got to really, sort of dog food the product early. But I also got to look at the implications of it. Like I already know that if I was to build, you know, this application with standard WPF And not used .Net Core 3. I know that my application itself wouldn't be able to take advantage of all of the performance improvements that come with .Net Core 3.

Actually I have a side-by-side of running and loading applications and doing file access. Scott Hunter did this this demo where there was a WinForms app more maybe a WPF folder, and it would look at all of the subdirectories, all of the things, and do a little pie chart of you know, what was taking the most size and we created that sample. So when he would run it, and you could run it with standard framework and then .Net Core 3. But it's the same code, right? Same UI, same code and just the file IO performance.

The performance of the app itself was like 4x faster, so he would be able to parse the file system instead of in five seconds in one second. You know, that's huge without doing any work. So for me, I wasn't necessarily "I'm going to get tons of new APIs and new crazy things .Net Core 3". For me, it was, oh I'm gonna get performance. I'm gonna get the ability, at least that I know that there's a roadmap that I can take this easily to have it this upgrade cycle and at the same time support older operating systems if I need to. So to me, that was was cool just to see in general and then learn through how do you actually take this thing that you developed, package it up and get it into the store? And what are the implications there? So when you do go through this process, you get some of those cool niceties, like I said, But also your app becomes sandbox. So some of the things that you were using now maybe put files in different places or you don't have access to certain areas or or things like that. So that's one implication that sort of comes with it. But it's it's something totally works and %work% for me.


I think I know the demo that you referenced there. The I'm sure it was one of the very first. Hey, look, we're bringing Windows Forms and WPF to .Net Core on Windows only. The version that I saw was both Scott Hunter and Scott Handselman on stage. Handselman is doing his of telling loads of jokes and being really entertaining and Hunter's going. "Look, this, is that this Look at this. Look at this. We could run this, you know, four or five times faster. Just look, look at this!"


Yes. Yeah!


Hansleman is telling all sorts of jokes and being really silly, but that's not to detract from it either. They both do a brilliant job while they do it. Just, you know, that's my memory of it. And that may not be 100% what actually happened.

But what I really like about that is that, I guess with with speed increases that .Net Core 3 brings, I guess if you wanted to because, abd I alluded to it a little bit there earlier on I feel like I need to bring it back up again, Now it's just that Windows forms and WPF are Supported in .Net Core 3. If you are on a Windows platform. That's my understanding of it.


huh? Yep.


I like the idea that if you were to use maybe solid principles on separating out your user interface correctly. Correctly is maybe not the correct term there. But you you know. Sort of don't have the user interface driven tightly coupled to the code behind it. You could potentially swap the user interface and maybe released the same or similar code for one of the many Linux's or for macOS. Just swap that user interface out for something else.

You'd have to maybe think about the Windows Store, I guess. But that's that same code, isn't it? Just running on a different UI.


Yeah. And that's how I developed this application, funnily enough. I sort of thought about where I could potentially take this application. So I structured it in a MVVM type of way. You know, XAML user interface and data bindings. I had a few interactions with the UI, and or the operating system. So I had the ability to access like the clipboard and to open URLs so I could launch the browser and other things like that.

Most of the other things that were doing was like a standard input/output countdown writing to disk. Those are all things that are available in .Net standard libraries. So the core application. What's fun is that I could have written the entirety of it inside of normal WPF and I could have converted it over to .Net Core probably in 20 minutes. I bet it would have been super fast. And I believe I actually started with normal WPF and then transferred it over to .Net Core 3. And it took, like, you know, five or ten minutes to do. And at that time, the reason why I had created a Shim framework project is I just wanted to edit the user interface inside of a designer where they didn't have a designer. Now they do for for it, and it's it's all new because the designer is now running on .Net Core. So, um, that's pretty impressive in itself and I believe of a process. So that's really cool.

And, yeah, I thought the cool part here is that I think of it, how I think of Xamarin applications too, and I just think of .Net applications, which is that you just have these head projects, right? And this head project is your WinForms app, your WPF app, your ASP .Net your Xamarin iOS app or Android app. And this is where just either your UI may live there. It may be using a cross-platform UI but it sort of just gives you the access to the core APIs. So, for instance, the clipboard and opening browsers like those are Windows APIs. If I want to do that on Mac or I want to go do that on iOS, I have to use iOS and Mac APIs to do that. Maybe use some helper libraries, things like that. But in general, the cool part here is I was able to first start with the WPF app had it running on .Net Core 3. I went through this packaging process. So the MSIX is the packaging process that allow me to put it into the store. Now the cool part here. What I really want to talk about is that I didn't have to put it in the store. I could have generated a website. In fact, I have a website. It's mystreamtimer.azurewebsites.net. You can download the app from there so it generates you a whole website. It does automatic-updates automatically and you can install it. The difference though, is that you know you need a certificate. You know, when you put it in an App store, it's signed for the app store that can allow to be installed everywhere. So in this scenario if you want to self deploy and install it magically like you need to have a digi-cert, basically, and I didn't want to pay for a digi-cert. So I said, I'll put it in the store.

And the funny part is, I've published UWP apps and Windows store applications before and literally, the packaging is exactly the same. Where if you were creating a UWP app, let's say in the past you would right click on that project and then you would say published a store. So what they did is they said for .Net Core 3 apps and things that are published with MSIX you create a packaging project, and that packaging project has applications that can be distributed. So you just, you know, add a little bit of project structure to say, Hey, I want to deploy this WPF app. You right click. You can associate it with your App Store ID. You can distribute the packages, create the at packages. You can install it on your own machine, test it out, and then with one click, you upload it to the Microsoft store and it just works. It's magical, right? It just it's out there.

And when you publish updates, you get the updates. And, the funny part is that even though I did a huge blog post and you asked me to come on, it's just like developing a normal WPF except for like now it's running on .Net Core 3. It's bundled up all special, and, ah, you get the performance. You get to light it up with some of the cool windows 10 features, and it just works like I was pretty blown away by the whole thing. There's some implications that I just talked about it there, but at that point I had the application, and I was in kind of that space that you just said, which was, Well, I have a desktop app. What if I bring it to other desktops and Xamarin supports macOS as a part of .Net. So I, literally in one livestream took the entire application and I ported it to macOS and I shipped it to the Apple App store for Mac OS. And now this application, which is running .Net Core 3 on Windows, is now running on the mono .Net runtime on macOS, but with a macOS user interface. But all sharing, you know, I would say 805% of the code, and logic is all shared between those two app.

It's cool to take it and then put it anywhere else that you want to.


That's really cool. I like that because that was gonna be my next question about how the process of sort of packaging it all up for MSIX and for the Windows Store actually went. %But% I mean, you preempted and said it for me. So that's brilliant. Thank you very much.


Yeah, and the funny part is, once I got to that step of "Okay, I want to distribute to the store." That's like the scary part, but it's really straightforward. You go into Visual Studio add a packaging project, and it has for, all intense and purpose, the same exact look and feel that packaging project as a UWP App. In fact, you have to have the Windows 10 UWP workload installed, so your application gets the visual assets. So you get different icons like you actually use real proper icons that a Windows 10 app would use. You get different capabilities declaration. So I added a protocol declaration to the application. That's all in this packaging project. So I can say, "my stream timer [colon]" and then pass it a stream coordinates launch, and that's how I have it tied in. So instead of having to parse command line arguments, I'm handling uri request for all intens and purpose to the app. And then from there it's all the same as a UWP or just right clicking store, associating it, publishing the files and then uploading it like normally.

You would not even know that it's a WPF application at all, because it's just a normal app in the store. And that's sort of the life we want to live here. I just want to publish apps and get them out there easily to our users.


That's like I mentioned earlier. Until the product is in the user's hands, it's not generating any use for them. At the very least, you know that the user can't get anything out of a nap that doesn't exist.


Yeah, that's true. Yeah, it's true.

And then you got Of course, once it's out there, you got to tell people about it and create a website and do all the things. And luckily, all mine is just open source on Github. I just have a very simple, like, get a page that tells people to download and set it up and go to town on it.

So, yeah, I've been I've been Really I was super happy with it. And I'm sure what I'll do is, you know, once .Net Core 3 launches again, or is released this fall. Not again, but releases out of preview this fall, I'll go through an upgrade process, right, And I will probably repack it up, and then get it out to the Windows 7 and Windows 8 once it's all finalized and things like that. So that'll be kind of my mission. This fall and. We'll see how that goes.

Sponsor Message

This episode is sponsored by Rider from JetBrains.

Have you heard about Rider, a cross-platform .NET IDE developed by JetBrains and based on IntelliJ Platform and ReSharper? If not, it's time to give it a try! Develop .NET, ASP.NET, .NET Core, Xamarin, or Unity applications on Windows, Mac, or Linux. Get Rider today at RiderIDE.net and try it free for 30 days!

Getting Support For Preview Bits


One potentially mean spirited question, since obviously you know you work for Microsoft. Let's say the .Net Core 3 release version. The final version, the out-of-preview version. The let's using everything that released, the manufacturer version. Comes out and on you go "Right. I want to then move this over to. You know, take my .Net Core 3 preview app and migrate it to .Net Core 3 proper. Do you get much of sort of inside help on that? Or is it just a case of I will look through the public documentation and I will follow the process that you know everyone else follows.


Yes, So for me, I like to follow. I think all of us, like what we do when we, when we're building applications, is always try to put ourselves in the shoes of the developers using our product. So some insight would be I go through the same steps. I use the same packages I go through the same process that everybody else would go through. Now if I run into issues the difference is that I can hop onto teams and I can complain to somebody really quick, but I use that as a last resort, you know, type of scenario.

But it's important to do these things. At least from my perspective and especially for the dev team and for the end product to do this testing early because you sort of get to live and find gotchas with it. So, for instance, I was working with Glenn Condron from the ASP .Net team, and we're working on bringing some of the ASP .Net style of dependency, injection and things to Xamarin app because they had some new packages and, you know, I got to use all the preview packs that were public. But there was some issues at time-of-release build, had some issues with some of the things that were missing from the Xamarin runtime. And in that instance, I actually went through the same process that you would go through. I went into Visual Studio. I said report an issue and then it I got my issue tracked and I gave the logs. The only difference was is I then went into our team's channel and I said, Hey, I just want to let everyone know that I reported this issue and let's try to figure it out and then have a dialogue to dive in a little bit deeper into it if I can.

But yeah, when it upgrades to .Net Core 3 I'll just through the same process. I'll probably do a live stream of it and see how it goes and you go from there.

So, yeah, I think that there's there's no special treatment at all. Really. Besides that, I can send someone... I mean, you can send in an email, too, I guess. But I guess maybe I could hop into the team's chat room, and that maybe pushes it along a little faster. But the nice thing is that the teams you know, being at Microsoft, it's great to see how the teams, rapidly progress and rapidly ship out products so fast, like Visual Studio updates at a much faster cadence. To get out those priority fixes Xamarin does the .Net Core team does.

I love sort of the cadence in which we're releasing. It doesn't feel like too much. Um, you know, like often you can update way too fast, But I feel like it's a good cadence in this world where we need fixes and we, you know, need new features here and there. And I don't want to wait five years for a new product to come out. So it's nice to follow along and update things as they go.


Definitely. I completely agree with you on that, and I think I'll try and reinforce that sentiment of when you hit an issue: Report it. Because otherwise how are the people making these products going to know.


This is true. Yeah.

That's usually the very first thing I say is people will say Like, you know, I have this issue. Like report a bug people!


People in Dev Teams and PM teams look at that every single day like all of the new reports. It is the single handedly best way to to help out.


I would second that in a heartbeat. I mean, you're right. If we were working on a product and we knew that someone was having trouble using it, we'd want that bug report to, you know, regardless of whether it's .Net Core, whether it's Node, whether it's C++, we would want that report.

just a couple of shorter questions if I may?




Would you recommend that folks use public previews of stuff to figure out what's coming up next in their personal project, or to figure out what's coming next in their business projects?

So I have an opinion on this. I'd love to hear yours and then maybe I can share mine. Maybe we have the same opinion. Maybe you have a different opinion.


Well, I am. I'm definitely a fan of dog fooding preview releases for people.

There's two factors to it, right? Let's say I'm using a NuGet library, and I'm just like, okay, I want it. Here's a NuGet library and I need a bug fix. If there's a bugfix and a preview NuGet, I just go and take that. And I think that's fine.

Companies and enterprises may have different policies against using preview software versus stable software for things like that. But I think that for the most part in general, I'm pretty much open, especially in personal projects, to try out new stuff and give it a whirl, especially if it's just libraries. Like when you're updating to Xamarin forms previews like I'm always on the previewing nonstop. So I'm always wanting to give the feedback and try because that preview will become the stable at some point, right? So if you're able to see if it works with your project or doesn't work with your project boom.

Just create a branch that's my best practice. Always be creating branches! and, um, go to town there. Basically, this is what I say there, But yeah, this is a James' thing it's not Microsofts, but I am perfectly comfortable shipping preview bits into production because and that's what I do with this app, right? Because I tested it. It works, you know, even though it's preview to me, it's indistinguishable between it. Right now. I could create another app, and maybe that's not the case. But as long as it's working, my tests are working. My unit tests are working. My UI tests are working, I'm a happy camper, and I'm getting to take advantage of the new hotness and take advantage of the things.

So that's kind of my thoughts. I don't know if that that actually answered your question at all.


That answered it perfectly. So my version of that would be say, If I'm learning .Net Core, I want to try and learn with the stable version because I'm coming to it new so that documentation will be. I don't use the word better, but I guess more mature for the stable versions. But if I already know .Net Core and I want to try and build something new, you know, I'd say quite happily, use the preview builds if you're brave enough, but know that the documentation isn't there or maybe not as mature as the stable version.


That's true.


Yeah, and that's just a fact of life. If someone is producing a preview build of something and releasing it at a relatively high cadence, then you know, us developers, we traditionally don't like to write documentation, so that's gonna fall to the wayside a little bit.




I said this to someone today at work. Essentially, if you are building something for the company that you work for and you are being paid to build it, maybe not use the preview version because you may get stuck and you may have to wait for the documentation to be fixed or wait for someone else to figure out the issue. And that will be time that is affect shipping the product. So maybe not for live products that you are being paid to build by your employer.




You don't want to fall into that route, and you don't get fired because you got stuck and no one has updated the documentation yet.


Gotcha. Yeah, that makes sense.


So just a couple of questions about how people can you and the kind of things that you're doing at the moment, if that's alright James? So where can people find you online? You know, is a twitter? Is it Github? What's the process for finding out what James is doing these days?


Yeah, I try to be everywhere all over the Internet, I guess and still not everywhere. The best place to find me is on Twitter, definitely at James Montamagno. That's mostly where I hang out. The only social media thing that I use out there. I don't really like any other platforms. I love to hate Twitter just like anything else. It's also hard to have a full conversation on Twitter, though, so I'm very open to people e-mailing me. It's just Motz [at] microsoft [dot] com, but that's really like those two ways, a really good or send me a DM. My DMs are open on Twitter, and I usually have conversations back and forth there. That's how we started chatting, right? I do read them as much as much as I humanly can stand with emails.

And then I have my website, which is just montamagno [dot] com. And that's where I do all my blogging. So that's where you can find my blog's on all things dot net and Xamarin, where I'll be speaking the, podcasts I produce, the apps that I've created things like that, but try to blog, like, once a week or, you know or something like that and pretty geeky topics. And they're not all Xamarin. There's a lot of Xamarin work, but also a lot of crazy things that I'm sort of hacking on, too. So, um, yeah, definitely those places. And if you want more podcasts, I've plenty of podcasts you can listen to, like, Merge Conflict and you can click on that, I'm sure you'll put stuff in the show notes. All those places.


Definitely. So could you give us a %ring% quick rundown of the podcasts that you create so that you know listeners can pick and choose which ones or maybe they're going to go to them all. I don't know.


Yes, I love podcasts. I have way too many of my device, but there's three that I do actively. So the main development ones that I do are Merge Conflict, which is myself and Frank Krueger. It's pretty heavily on .Net and mobile. I would say not all 100% Xamarin or work, but quite a lot of that, but also implications of Ios and Android. And we also talk a lot about IoT and machine learning and animations, all sorts of different things. It's super good. Just me and Frank. We don't had guests on too often, hardly ever. But we do that weekly every Monday. That's merge conflict

And then I do another podcast just on Xamarin with my colleague Matt Soucup, it's called The Xamarin Podcast. It's literally in the name. And that's monthly. We just kind of a recap of community. Everything that's happening in the world of Xamarin.

And then I also do a non-development podcast called The Nintendo Dispatch, which is at Nintendo Dispatch. This is with my good buddy Michael and my other friend Christina, and every week we talk about the happenings in the world of Nintendo and Nintendo switch and their mobile applications and theme parks and everything. And that one is sort of gives you like a recap of all the news for the week. And we talk about games that we're playing games that are coming out, and that one's been going strong for a while now. So, yeah, there's the three podcast that I do.


Fantastic. Plenty of choice for folks, depending on what their core interests. Or like I say, maybe they could subscribe to them all.


Yeah. There you go.

Yeah, fantastic. Well, all that really remains to say James is thank you ever so much for taking the time to chat with me. Today. It has been a real pleasure. I always loved getting to talk geeky and developer with someone, and it's made my Friday evening. If I'm honest.


Now. Awesome. Well, I'm glad I could help it. Thank you for having me. I really appreciate. It's fun to talk about all the cool stuff that I get to build and share with the world. And I hope other people get too build awesome stuff, too. And then get to share with the world too. I love seeing what people are building.


Brilliant, James thank you ever so much, James.



Wrapping Up

That was my interview with James Montemagno. Be sure to check out the show notes for a bunch of links to some of the stuff that we covered, and a full transcription of the interview. The show notes, as always, can be found at dotnetcore.show.

And don't forget to spread the word, leave me a rating or review on your podcatcher of choice, and to come back next time for more .NET Core goodness.

I will see you again real soon. See you later folks.

Episode transcription provided by Productivity in Tech - Helping Tech Folks Create Content for Other Tech Folks