 Hello, and welcome to another episode of Visual Studio Toolbox. I'm your host, Dimitri Lailand, and I'm excited to have somebody from the.NET team with me, Richard Lander. Richard, welcome to the show. Thanks. This is great. Yeah. We'd love to have you here, and we're going to talk today about.NET Core, and specifically.NET Core 2.0 preview to release. So Richard, why don't you tell us a little bit about what.NET Core is, because as much as we want to talk about the newest preview, that's why you're on the show today, there's probably somebody out there who doesn't know what.NET Core even is all about. Okay. Definitely. So we started this project, the.NET Core project maybe three years ago, something like that. It's been a while. Yeah. This is version two, we're talking about of that. Yeah. We did two versions before that, 1.0 and 1.1. Obviously, there was a development period, and for those of you who are familiar with the project, we had kind of an elongated development period and had a few different names. So it's been about a three-year project. If I think about what it was we tried to build, we wanted a cross-platform project, we wanted to have side-by-side installs, we wanted a project where we could move quickly and innovate and deliver a lot of value to customers. Yeah. And I think we've done that. Yeah. We've done those three things. This doesn't seem quite as relevant now as it once was, but projects all open source as well. We've said that a million times now. Yeah. I mean, that was one of the biggest things that people are surprised about. I think it was around the same time VS Code was announced as well. I don't remember who was first or second there, but two open source projects, two really big important projects to Microsoft and with Core, like you said, it's going to run on Linux, it's going to run on the Mac thing, it's going to be super optimized, it's going to run side-by-side, X file deployments, all of that was exciting stuff. Yeah. I mean, the open source thing we felt like if we're going to do a Linux-friendly and a Mac-friendly product, it has to be open source. There's just no other option. Yeah. You know, I said, we've said this a million times, like now that's just what we do every day. So every day everyone on the team is on GitHub doing pull requests, working on issues. Building in the open. I mean, that's the scariest, cool and scary thing at the same time. When we first started, it was just us talking to one another. For the most part, we definitely had a mix of community members right from the start. Yeah, some people were there from the beginning. Yeah, but now it's completely different. Now there's this extremely constant engagement with the community every single day. And a big part of my job and a number of other people on the team is answering their questions if they're having trouble, or there's a ton of people that are actually suggesting ways to change the product. Sometimes that looks like a good direction and we go there. Sometimes it has to be altered a little bit, so that's a big part of it now. I think the biggest thing that I would know when I talk to people about what.NET Core is all about, I tell them it's not just any longer being built just by Microsoft, right? We have community contributions. We're accepting those contributions. It is kind of a cool thing to think about that. Anybody out there, like you folks out there in the audience, right, as you're working with Core, you might realize, oh, this function really should have always been there, right? Let me put some helper thing in there and you could submit it as a pull request and see if the team accepts it or maybe gets inspired by it. You guys still decide what gets in or out, but it does work. Yeah, another part that's close to what we've just been discussing is we actually have daily builds as well. So, and each branch actually produces daily builds. So, for people who are really wanting to keep up on the bleeding edge of what we're doing, you can install one build yesterday, a different build today, and a different build tomorrow, and then, you know, if the issue that you posted finally got fixed, it got fixed today, then tomorrow morning when you wake up, you can try that build and validate that it actually was fixed. If it wasn't fixed, then you can reactivate that issue and say, you know, folks, I don't know what it was you fixed, but it wasn't my thing. And that level of engagement was definitely not available before at all. Yeah, and you can look, you know, as a customer, you can look behind the scenes how the code is actually running, so there's no more, there's no more secrets there. The whole library is up in the open, and so is a bunch of other stuff. So, ASP.net is up there, Entity Framework is up there. I mean, everything is part of this core initiative, right? This core family of product. Yeah, so maybe we could talk about something else, which is its relationship to .NET Framework. So in many ways, it's very, very similar to .NET Framework. Actually, most of the runtime implementation is shared between the two products, so that's very, very similar. And it's for the framework libraries, most of the code base itself isn't shared, but the behavior is very similar, the same APIs and all that kind of thing. I think the big difference is that we have like .NET Framework on over a billion machines, and so there's a ton of responsibility that comes with that to make sure that all those apps in, you know, hundreds of countries used by millions of people that they all work every day. With .NET Core, we have an opportunity to move much faster, try out new things, and see how they work. So in the .NET Core 2.0 project, we added a few new somewhat revolutionary features, span of T and memory of T, or maybe those are going into 2.1, I actually can't remember, but that's not the point. But it's part of the immediate role that you guys are able to evolve and add something really awesome to it. Yeah, and so we get to do, because A, there aren't nearly as many people using .NET Core today, and B, because of the side-by-side installs, it's really this one that's the important point. It means that we get to try out these new features, collect some information about feedback about how they're working, and then once they're tried and true, then we can bring them back to .NET Framework, where we have much more responsibility. Well, that's an important kind of thing to say to the audience, like .NET Framework is still the thing we work on. Oh, totally. It is not going anywhere, they don't have to worry about, you know, .NET Framework going away, or you having to move everything. It's just a parallel project that's designed for very specific things and able to take advantage of and optimize and do things that we just can't do it when it's installed on billions of machines with the framework. Oh, for sure, and I think actually the existence of Core will actually help us add value to .NET Framework more quickly, just because we have this testing ground that's a safer place for us to work as engineers. Whereas with .NET Framework, that's a little bit harder. Yeah, and also, you know, .NET Core, I don't want to scare people when I talk to them about it, and I often have to explain this part, which is, yes, it's open source, it's moving fast, but there is a point where you guys ship an MSI, right? There is a stable point to download. Absolutely. You don't have to worry, a daily build done by the team is going to break your Dev environment or something. No. That's up to you at that point if you adopt the newer bits, but there is a stable point that we're going to keep shipping. Oh yeah, and also these daily builds don't just magically end up on your machine. You have to really work to get them. Yeah, you have to really work to get them and to find them. Yeah. And yeah, so we ship preview releases back to the .NET Core 2.0 project. We ship preview one, we ship preview two. Yeah. We're about to ship another release relatively soon, and we tell people exactly what's in them. We actually publish detailed release notes. Yeah. Yeah, the release notes are good and there's a roadmap and it's all up on GitHub. Yeah, and so people can kind of make decisions about what it is they want to build, and then once it goes RTM or RTW, then we're just on like a servicing plan where we actually have an extremely high bar, somewhat similar actually to our .NET Framework bar for taking changes, and it's very hard to get servicing changes in place which is actually a good thing. Yeah. Those are just for reliability, security, and severe performance problems, and then most of the effort would go into two one at that point. Yeah, that makes sense. And as part of all of this, the last thing probably we should talk about is .NET Standard. Definitely. I think it's worth saying that .NET Core 2.0 and .NET Standard 2.0 come hand in hand, right? So we're shipping those together, and so what does .NET Standard mean for folks? Sure. So it's totally just a spec. So we have this. It's a promise. It's a promise, although I would say it's stronger than that because it's actually part of the Visual Studio experience. Like it has actual artifacts around it. But so we had portable class libraries before. That was a good-ish code sharing solution, but it didn't kind of make any forward-looking statements on what new .NET implementations needed to do. Whereas what .NET Standard does is it says, these are the minimum APIs that you need in your product in order to be a proper .NET implementation. Based on a certain version of the standard. Yeah. So we have multiple versions of the standard. So one analogy that people have been using is HTML. HTML is a spec. You can't use it for anything in and of itself. You have to implement it as a company or whatever. Yeah. So there's several versions of HTML, and then there are browsers. There are several of those. Microsoft even makes one or two, depending how you count. Yeah. Then those browser makers, there's like Chrome version 50 or something like that. It will say we support HTML5 plus these extensions, plus these CSS versions. So .NET Standard is very much like that. So .NET Core 2.0 will implement .NET Standard 2.0, .NET Framework 461, I believe and above also implement .NET Standard 2.0 and the Xamarin products. At the same time, we ship .NET Core 2.0. We'll also implement .NET Standard 2.0. Then the only other one to discuss is our UWP.NET implementation. Yeah. That will support .NET Standard 2.0 later in 2017. Yeah. So the thing though is that, it's like, okay, I see the versions match. So when you ship .NET Core 2.1, we'll ship a .NET Standard 2.1. The answer is probably not. .NET Standard is actually intended to be relatively slow-moving because it's completely for class libraries. Yeah. .NET Standard is not about the XAML, right? No. I mean, there's a XAML conversation we can have with XAML standard, but just the scope of our thing today is, it's about making sure that you can reuse code and therefore it's about the class library conversation. Yeah. So. Or then you get package. Yeah. Whatever you need to extend your application. Yeah. And those are mostly the same thing. Yeah. So we'll decide what are the next things that we want to put in .NET Standard, but I'm not seeing that in the next six months that we're going to put in a new .NET Standard version. So it'll be, .NET Standard 2.0 will be the thing for a while. Number two is the theme of this show because we're like, we're talking about .NET Core 2.0, it's the preview two release, and we're going to talk about .NET Standard 2.0, not to confuse you folks too much. Okay. I'm going to have two arms and legs. Yeah. We have two arms and legs and hopefully more fingers, but the reality is that this just coincidence that .NET Core 2.0, .NET Standard 2.0 line up, but that's not the shipping intent. Going forward, it'll just, whatever makes sense, we'll do that. Yeah. Some people actually asked us, so we had a set of Dynastandard 1.x versions all the way up to 1.6, and some people said, well, if you think about Semver, semantic versioning, you really use a major version number in case of a breaking change. As they said to us, like, is there a breaking change that's coming in Dynastandard? The answer is no, but we decided to create a major version for two main reasons. One was we're over doubling the number of APIs that are in .NET Standard from 1.6 to 2.0. I think it's like 130 percent increase. It's some crazy number. Yeah. So that's quite large. Then the other one is the way .NET Standard is structured under the hood is changing quite a bit. It's not anything that library developers have to worry about from a breaking change standpoint or anything like that. But we felt like those two things, the architectural change and the increase in APIs meant that a 2.0 was warranted. Yeah. Okay. That makes sense. All right. Yeah. Let's talk about what's new in 2.0. So that makes sense. So let's switch gears to the current release. Right? So now we're going to go talk about .NET Core 2.0, the preview 2.0 release of it, which enables a bunch of more capabilities. So why don't you go through it? Then we're going to talk through a blog post. So there is a blog post on the Visual Studio Team blog, and there's other supporting blog posts. We'll link all of those in the show notes. So let's go through what's in. Yeah. So this is actually the .NET Team blog. Oh, sorry. It's the .NET Team blog. Yeah. I have my blogs a little confused. They spent too much time reading them. So yeah, let's go through this. I have some other things that I think are maybe not covered in depth here, but we'll go through this first. Sure. So we care a lot about platforms on our team. So when we had .NET Framework, it was always Windows, Windows, Windows. With .NET Core, it's definitely a broader set of releases that we work on. So the first thing is Azure. It's quite important to our team. So we worked with the Azure App Services team to make sure that .NET Core 2.0 was supported. Yeah. Some people don't always realize that App Service is like the websites. So if you're deploying your websites to the managed infrastructure, you're not just doing your own VM and your own thing. But if you want to use App Service, website capability, you can deploy .NET Core 2.0 preview tune out there. Yeah. No, it's essentially a SaaS service. You don't have to do much. So one of the great scenarios that they have for websites is you can put all your code in a GitHub repository, public or private, or Visual Studio Team System. I think you know about that. Yes. And put that on Visual Studio Team System, you can either use Git or TFS. And then- Team services though. Sorry. Team services. Thank you. I was didn't catch it myself. Okay. Because you know, you say something that close. Yeah. It's a bit hard. Yeah. So you can check in your source code and then you can set up a trigger such that every time you commit at least to a particular branch, then you kind of have a CI CD flow and then your code gets pushed to production in your Azure website. So I actually do that on some of my sites and it's awesome. But when you do that, you're not the one who's shipping.NET Core. You're just effectively shipping source code. Yeah. And so.NET Core has to be in the Cloud, in Azure in order for that to all work. Because it's a SaaS. So we control what's in there, what's enabled. Yeah. And App Service, I believe, supports like Node.js and .NET, the standard version and now .NET Core is up to preview two for the two release. Yeah. So anyways, whenever we ship, we try and have same-day shipment to Azure. And so we have to work with that team. And they're awesome, actually, to make sure that if you want to host your preview two site in Azure, also on same-day, you can. Cool. Another one is we do a lot of work with Docker. We've had Docker images now for, I want to say like two years on Docker Hub and we've actually learned a lot in that timeframe and also Docker has changed a fair bit. And those are Linux images behind the scenes, right? No, both. We have Linux and Windows images there. That's actually, that was an awesome segue actually. So in the past, Docker was Linux only. And then the Windows team started talking to the Docker folks and said, we think Windows would be good here. And so many changes needed to be made to Docker, not just to make it Windows friendly, but just to enable it to support another operating system, no matter what that was. Docker started a small company. Linux was the thing that they started with, it made sense for them to do that. Yeah. So we've been working closely with the Docker team. The Windows team has, but so has the.NET team. And so there's been cases where something about Docker didn't work super well for us. And they've actually made changes to the public Docker implementation, which has been awesome. And their tools and Windows are getting much better. I mean, they didn't start there, but now it's beautiful. I can install it and it just works most of the time. Yeah. So one of the things we did is, there's this concept called Multi-Arch, which I'll maybe describe a little bit later. And it basically says what's the default Linux version that you'll use. And so Debian 8, also called Jesse, was the one that we've been using for the past two years. And so this new version called Stretch, Debian 9 came out and they're all named after Toy Story characters. That's cool. Yes. It came out like two weeks before we shipped Preview 2. And so we decided that that was the time to start making Stretch our default. There actually is a quicker path to security fixes, going into Stretch than Jesse. So that was actually the biggest motivator for us. We felt that for customers that are basically just trusting our default choice, which I think is probably a lot, of customers, we wanted to make sure that they were absolutely in the best spot. And we felt Debian Stretch was that because of this. It's the latest, so it's probably got all the goodness, but we also saw that they fix security issues that are the fastest. So that seemed like an easy choice. Yeah. That looks good. Suce Linux, we started to talk to the Suce company. They wanted us to support SLES 12 and we did. Cool. Mac OS Hi Sierra, so Apple puts out one or two Mac releases. So far, they always break us during their beta period and so we always have to make changes. Hi Sierra is turning out to be more work for us to support than Sierra was. Sierra was actually quite small, what the issue was. And so we don't have, in preview two, we don't have support for Mac OS. Hi Sierra, even though it says it here, it's limited. So we are working on that. I think we fixed an issue that was fine, but maybe there's more. There is. We're still in preview. Like that's one thing I want to tell the audience, like that in the Core 2.0, this is still a preview release. We're not here talking about something that's supported in production or ready for prime time. This is to get people ready for the newest thing. Yeah, so what happened is, in this timeframe, yeah, we fixed a bug which is, you couldn't even run the .NET command. Or you could run the .NET command, but you couldn't run .NET new or restore. Right, you couldn't do anything but it. You couldn't do anything useful. That was fixed in the preview two timeframe, but then we found another set of bugs that we I think didn't know about when I wrote this blog post. So we're very actively, it's actually the, if I think about what's left in the .NET Core 2.0 release, that is the most active effort right now. So we're putting a bunch of effort into it. We filed, I think, four bugs with Apple that they're looking into. So we're doing everything we can. That's cool. Then when we do support High Sierra, we'll do it for 2.0 and the 1.x releases. We're talking about the dev environment for people, right? So if you work on Windows today, you're fine if you deploy the Linux, you're fine in the sense that we don't know of anything that should block you in theory, right? This is the one dev environment where we're still working through some problems. Oh yeah. No, this is not every customer for sure is going to be affected by this and it will get fixed. It's just. We want the Mac developer to be happy. Yeah. I mean, this is mostly about right now, people who have already adopted it being successful. I completely believe that we'll have all of this fixed by the time High Sierra ships. So I imagine 99 percent of people using MacBooks are not on High Sierra. Yeah. It's not out there. Yeah. We're just looking to be sure we're there when they do ship. Yeah. I mean, actually, you need a developer account with Apple to even download this, which I actually have. I have another MacBook that has High Sierra on it, which I've actually lent to the dev team so they can fix this issue. Cool. A couple more things. .NET Restore is this command that people had to use all the time to restore their Nuke packages. Every time you changed your project file, it would invalidate the restore that you had run and you would have to run it again. I think that was annoying to a lot of people, certainly was to me. We've made that command implicit for all the other commands that require restore to have occurred. So build and run and publish and test are all good examples of those. Do you check for changes, I guess, and run it as needed or do you guys always run it? Yeah. No, it's smart. So that's huge. We've got a lot of people happy about that. Yeah. I think I saw that during build when I think Hanselman was demoing something or Damian, somebody was doing the demo. Yeah. Yeah. That was cool. It is cool. You can now reference .NET Framework libraries from .NET Standard. So this one's a little bit surprising and is not an alignment with some of our decision-making from the past. The way we used to do things and this is a little bit tongue-in-cheek, so hopefully no one is upset by this comment. But we used to think, dear developer, we know better than you, so we're going to set some policies that keep you safe. It's not like all of those decisions were bad. Clearly a ton of them helped people who wouldn't necessarily have known that they were supposed to go left instead of right. In this particular case, clearly not every single .NET Framework library that's been written will run on .NET Core on Linux, for example. Sure. Clearly, if you're newing up WPF buttons, then that's not going to work at all. Yeah. But we did this analysis and we found that over 70 percent of libraries on newget.org actually that, sorry, 70 percent of .NET Framework libraries on newget.org actually fit within the constraints of .NET Standard 2.0. So we said to ourselves, why would we, those libraries, not all of them are going to get converted to .NET Standard 2.0 on day one. Yeah. At day 365, a bunch of them won't have been converted. Anybody that's been through the cycle knows this is going to be like the point of like, oh, I can't move forward, right? .NET Core 2.0 gets released, it's great, it's in production, I can use it and then I need some library. Now I can't, that would have been really bad for people. Yeah. So we decided we're going to enable people to depend on any .NET Framework library they want. There actually is a warning in the product to tell you that this is a decision point that you need to make. Sure. So. You're taking out a dependency that's only going to work when the .NET Framework of whatever version or that component of whatever version that depends on the framework will now have to be there when you're running your application in your environment. So it won't work on Linux if you deploy it because there won't be .NET Framework. No, that's not quite how it works. Okay, so tell us. So you don't need .NET Framework in place. All it means is like inside a .NET Framework library, you know, it's just IL code, it's just a bunch of IL instructions. There's nothing, there's no windows-ness per se that's in there. So in the best case scenario, you have a .NET Framework library, the APIs that it uses fits within the spec of .NET Standard 2.0, and that will absolutely work on .NET Core on any one of the operating systems, and you don't need to install anything other than .NET Core in order to make that work. Makes sense, right? Because it's just code. It's super simple. Now, like I said, we put a there's a little warning there and you actually have to and we can show you this later, although it's not quite working yet. There's a little warning there that you have to put on each package reference to make it very clear that you've made a decision because it's kind of a buyer-beware scenario. But like I said, we didn't feel like we should be the ones putting this policy in front of people and preventing them from getting their jobs done. Right. We removed the inflexibility, right? So we made it flexible, you can do what you want, but then we tell you when you're paying a potential price for that. Okay. I guess the only other thing I'll mention is, we got teased actually a little bit. We've had these somewhat crazy file names. Now, you would think like, why do people care so much about file names? But so far, our MSIs, our Zips, our PKGs, not only did people not like them, I think they kind of thought we were insane. There was some reason for them to believe that. So in Dynacor 2.0, we did a complete revamp of all the file names and all the package names as it relates to AppGet on Linux. A group of us sat down months ago now, and we wrote up a spec, which is actually now on GitHub, and we said, we know you haven't liked our file names, here's our new proposal, where the file names are going to work, and we got a ton of thumbs up, and then we implemented that. Building that opened down to the file names back. Oh, yeah, down to the file names back. That's awesome. But people cared about that a lot, and I get it, so. Cool. I guess I'll just show one more. I know we probably want to get to demos. So this isn't really a .NET Core 2.0 thing per se, but C-Sharp 7 kind of landed in the same general timeframe as us. It shipped with VS 2017 RTM, and so I just want to remind people, so we're not going to go through this whole document, but I want to remind people that C-Sharp 7 is kind of like a sibling project to .NET Core 2.0. C-Sharp 7 is absolutely supported in .NET Core 2.0. So 1.1 before that didn't support it? No, you can use it there too. But if you're using VS 2017, C-Sharp 7 is there for you. If you're using .NET Core 2.0, it's definitely there for you, and you should take a look some of the cool things you've done with that spike. So it's just in the same timeframe. They're actually started work on C-Sharp 7.1. Already that's definitely not shipped yet, but it's definitely a sibling project that we work super closely with these folks. So I felt the need to mention it. Yeah. You guys also ship like Entity Framework, Core 2.0 also had a preview release at the same time. So again, we can cover everything in this episode, but we'll have links in the show notes for all of these things, and do I miss anything else? ASP.NET Core 2.0. ASP.NET Core 2.0. Yeah. When I think of .NET Core, I somehow think of ASP.NET, but it's not the only thing it is. Yeah. It's also the core library. Yeah, for sure. Just one other tab. So in GitHub, we created this repository called, .NET Slash Announcements. There's actually an ASP.NET Slash Announcements, so we copied that, and we've actually started posting announcements here on a fairly regular basis, and so you can watch this repository, and- So use the issues tab to post something that you're changing as you guys head towards RTM. Right. So one thing we do is whenever I post one, I'm not the only one who does this, but we actually lock the conversation right from day one, and the reason we do that isn't because we're trying to prevent discussion. It's that for people that watch the repository, all they get are our announcements. There's no additional conversation, which could be an immense set of traffic. Some change could be like a file name, I don't know. You guys say, oh, that's for a spec, we forget it and we're going back to the old file names. Yeah. So what we do is there's always this detail section, and then these are the actual issues on GitHub where this thing was discussed, and then you can click on those and have the discussion there if you would like. Cool. That makes sense. People should go to where you're actually working on the issue, because that's tracking that change, and this is just the summary for the high-level overview. This is what we change, why we change it. Yeah, that's exactly it. But I encourage people to go check out this repository and watch it so they can keep up. I miss this, so even I'm learning something today. Yes. Very cool. We'll link it as well. Okay. Awesome. Yeah, we have some notes here. I was wondering if there's anything that we missed that we wanted to talk about. We've got, I think we covered the majority of it. Okay. So we'll just go to some more demo-oriented stuff. Yeah. So let's look at some demos. I think the first one that you had on there was, you're going to use the Mac. We're going to show Visual Studio for Mac. So folks, maybe you missed this release. So we have GA, a product called Visual Studio for Mac, so that is available out there for you. Rich is about to show you how Visual Studio for Mac can be used not just for mobile development, but for web development with .NET Core 2. Yeah. So right now, .NET Core 2.0 is not supported in the stable channel. So right now, I'm in the beta channel. When VS 15.3 ships, then the bits that I'm using now will go to the stable channel. Sure. And everyone will be able to use this. This is actually almost identical to what's happening with Visual Studio for Windows, which is if you want to do .NET Core 2.0 development, you need 15.3. 15.3, which is also in preview. Which is also in preview. So it's basically the same. Yeah. I just wanted people, we've had a lot of people come to us and say, like, oh, I tried to use VS for Mac, or oh, I tried to use Visual Studio on Windows, and I couldn't do .NET Core 2.0 development. We're in this period where you need preview releases of these IDEs in order to play along. Right. Because there's a whole tooling experience that goes with it. So therefore, it has to evolve and get to a GA at some point. But I'm assuming VS code is a bit more straightforward because it's just a code editor. Yes. You can edit your code. Do you need to be, I guess, I'm just asking the question to be on some unstable version of code. No. That's right. You do not. Okay. So code is the only one you can just pick up our team version of. Yes. So code ships quite regularly? Yeah. Very regularly. Well, sorry. It actually has almost nothing to do with code per se. It's actually the C-sharp extension that is the thing that's giving you the .NET support. Yeah, the experience. The debugging, the IntelliSense. Yeah. So that also ships quite regularly. So as long as you're on the latest one, you'll be fine. So there's no preview version of that C-sharp extension? No. Well, there are preview versions as well. But then you require. Yeah. But you don't need them for this. Okay. Cool. Okay. So I'll just show the super basic experience. I'm just in full screen just so we don't have to look at all the stuff on my desktop. So yeah. If you haven't seen Visual Studio for Mac before, this is what it looks like. There's a set of different categories there. So naturally, we will go down to the .NET Core area. We have a console app and then ASP.NET Core app. So we might as well start with that. Sure. So the first screen that you see is a target framework. So for this demo, we're definitely going to use .NET Core 2.0. Pretty soon, that's what everyone is going to be using. Then toolbox and create a project. I would assume that this solution checked into your Git repo on VSTS or GitHub. Somebody with a PC and the Mac and work on the same project, that just works. Oh, for sure. By default, there is nothing OS specific that is added to your projects. You would have to do something in particular. Yeah. Your code will have to break the runtime for your Mac colleague, right? Yeah. Or vice versa. It's not about our tools. It's not about our framework. Definitely. I do that all the time. There's a personal project of mine that I work on, where sometimes I'm on my desktop PC at home, sometimes I'm on my desktop PC at work, and sometimes I'm on this MacBook on the plane, and I'm just always going back and forth. Cool. It all works. So we start here with this blank screen, and this is like solution explorer from VS, and all of this looks normal. Yeah. I mean, it's the solution. Yeah. You got the code. We have NuGet dependencies, and we're just dependent on .NET Core 2.0. So that all looks normal. If you want, you can, how do you do this? I can't quite see it. Anyway, I was going to say you can edit the project file, but I can't. This is the one time I'm not helpful. Yeah. Edit file there. That might do it. But I think that's edit the file. Okay, that is that. Okay. So you can look at your project file. You can see it's relatively small. Yeah, and you can edit here if you want. Anyway, I'm just going to run the app. This is where full screen is probably not going to be the best choice. Oops. Okay. Oh, wow. That was quick. So that opened up that application. So- Local, local run, local debug. Yeah. So here you'll see actually we're on localhost 5000, port 5000, which is the default. You can certainly change that. And if we go here and sort of break point in this controller, that's the home controller. Yeah, that all works. And you've got your friends, you've got your call stack, all, not everything from Visual Studio on the PC, but quite a bit of those capabilities are there in the Mac version. Yes. All the basic things that I would expect to be there are there. Yes, they're totally there. Yeah, so we're all kind of at home there. And like you said, you can move this project to your PC and it would all work. Every time I see this, I'm still blown away that we have a Mac IDE, that we have a code editor that can run on Linux, that you guys ship into Docker containers. I mean, it's just a whole new world. It is a- They also open sourcing this thing years ago would be the big thing. And now it's like, oh, open source, whatever. This is the really awesome part of it all. Because the productivity you get with an IDE sometimes is just much better than just a code editor and something like vice versa. So we give you the choice. And we have a community version, right? So it's a free version of VS4 for Mac. It is. Yeah, it's amazing. You can just go and download this and just start using it. And I mean, there are some rules about- Sure, there's a license. You should read the license. We are not lawyers, blah, blah, disclaimer. That's not our- Well, Richard might be a lawyer. I don't know. I'm asking that question. Yeah. Okay, I was trying to see if this one, this other demo actually might be on my other machine. I was wanting to show some stuff with unit tests. Yeah, that's the second demo that we wanted to do, the unit test one. Oh yeah, no, it's here. Cool. This label got on top of what I was trying to show. So we're switching to a different solution, different project. Yeah, this is actually one of my, it's not really a personal project as in when I work at home or for, it is actually a work project, but it's not really part of my main job. Sure. This isn't building that net for a living. Yes. Something related and you've got some unit tests in there. Yeah, so let's see. I've actually never seen how you do unit tests in VS from Mac. So it's new, similar. Yes, I have done this. Let's see. I hope so. I do, I have done this. Actually, quite recently. Where are the tests? Oh, run unit tests. There we go. So what we should see, so I have two projects here. Reader is the actual, Yeah, the project. Yeah, the project and reader tests. Yeah, there we go. Yeah, so you got like a test explorer or whatever it's called in the PC version nowadays. And you can see how they did once you run them. Yes. So you can click this run all button. And these are the, so I actually, I guess I have, I think I have 21 or 24 tests. It only seems to be finding 16. But. Yeah, but I guess the big fact here is that, what we're trying to demonstrate, we've got, you know, that net core, it's running in a Mac. We got an ID, it's running in a Mac. We're debugging, we're running locally to debug with a local, but not IAS. I almost said IAS. I don't think a Mac has IAS, but they have a web server where you guys brought something with it and you can actually unit test against that as well. So it's a full normal life cycle. Yeah, so you might actually not know this, but so we have this web server called Kestrel. Yes, Kestrel, right? Yeah, so that's our default web server in all cases. Yeah, even on Windows. Even on Windows. Even on Windows. And so with Dyna Framework, the way that it integrates with IAS in process. So it has a very kind of close relationship and they're kind of tied together at the hip. Whereas with Kestrel, we kind of went with this different model, which is actually more similar to the way other people build web frameworks in the world. And so Kestrel runs in its own process. It's actually not intended in this time frame to be a front facing web server. You actually put another web server in front of it like IAS, like InginX, like Apache. That is actually the thing that takes traffic and then it kind of proxies that traffic to Kestrel. And so there's a whole series of attacks for lack of a better term or challenges that Kestrel doesn't have to deal with because this front facing web server deals with that. It's not taking the traffic so the attack would hit that first, whatever the front of it. Exactly. Now, at some point we may decide to make Kestrel appropriate for those scenarios, but certainly in the .NET Core 2.0 time frame it's this behind front facing web server scenario. Cool. I think it is Kestrel open source. It is. Yeah. Awesome. It is. And under the hoods, something didn't work well with this test. I have no idea. It's almost like we're showing a preview release. It's almost like we're showing a preview release. And your machine, which might even for all your number have some bits that you didn't intend to. So actually the next thing was we were going to. Docker. Yeah. I want to, oh, I was on the wrong machine. I want to try. Oh, you want to try it on this so that people think that I was truthful about my, there we go. Actually, this project is, oh yeah, test explorers up. Yep. This project has, it's hosted in Git and it has that continuous deployment experience with Azure websites that I talked about before. Okay, cool. And so I know that when I'm working on it, when I check into master, then it does the auto deploy. Your tests have to pass first on the semantics. Yeah, exactly. And so we'll run all the tests. It has to build them all first. Unexpected error. Okay, there must be a problem with this. But. Yeah, but the tests pass. The tests all pass. It shows you that. And so that's good. Yeah, 21 tests passed. They're just a warning it seems like, but otherwise it's good. I think that probably fits into our, well actually the warning has to do with my code. That actually, there's nothing to add on the core. It's because there's an await I'm using in a non-standard way. I've seen these in my own life quite a few times. That exact warning. Okay, so I think I proved everyone that I have tests for that project. So let's talk about. Docker. Docker. So here's the experience. So you go underneath the web node and then there's a .NET Core web application on .NET Core scenario. I'll just quickly explain what the other two options are. So the very first one is .NET Framework ASP.NET web app that's gonna enable you to build a web forms or an MVC application on .NET Framework. That's not core, right? That's what was there before. Exactly. That's your web application. And core is the same thing, but we're using core so you don't have certain things like web forms. Yeah, and then the very last one is we enable a scenario where you can build, use the ASP.NET Core web framework, but run it on top of .NET Framework. And so that's a good choice if you want to opt in to the new web framework, but you have dependencies on components or APIs that are not in .NET Core. Or if you want to kind of do a, you don't want to do the whole migration at once to .NET Core. It's like, let's change our web framework to ASP.NET Core, get that in place and feel comfortable and then we'll move the base to .NET Core as a second step, so you could do that too. That makes sense. So are you pointing this out because you need to use the middle one, the core web application for the Docker scenario, right? Actually, yes. Docker might work in the, I think Docker works in the first one as well. I believe we don't yet support it for the third one, but we intend to. Okay. So what happens is you pick, you get this menu. It tells you which target frameworks are available. Obviously we'll use 2.0. And then there's a checkbox called enable Docker support. I have it checked and you get to decide whether you want to target Windows or Linux. Yeah, and basically just the Docker tools should be installed on the Dev Machine before that. That's a very good idea. Yeah, otherwise it won't work. Otherwise it won't work. And so it creates your project in the very bottom. You've got a whale. Yeah, I've got a whale. It doesn't seem to have any errors, which is also a good sign. Yeah. Because I learned the other day when I was cursing at my computer only slightly. Yes. That was on my fault it turned out. It's possible. So right now I'm on Windows containers. If you can see here it says switch to Linux containers. Yeah. So I use both. And so here's the Docker file. I actually write these Docker files all day long. This is actually, this piece here is the zoom. I always forget where that is. 200%. Yeah. That's the base image that you're using. It's actually going to be downloaded from Docker Hub. It actually isn't downloaded from Microsoft, although we push our images there ourselves. Yeah. Well, Docker has a repository of images. Yes. If anybody knew like me to the Docker world, I'm still ramping up and we publish our image with certain path over here. You can specify which one of those images you want to pull from us or from whoever. Yeah. So Docker file is the thing that tells Docker what's your intent? Yeah. So when you press the button here, that is normally the debug button. Here it says Docker. What it's doing is it's making sure you have all the right assets on your machine from Docker Hub. I did that ahead of time so we should be good. Is it going to show you what it's doing in the output window? Because it seems like you hit the button right and it's doing something. Is there some activity? Yes. Okay. So there you can actually see like, I as a developer love to know what's going on, call me paranoid. Yeah, actually we're going to do some more work in this experience so that people that don't know they're supposed to go to the output window to see progress will get some kind of a progress experience because some parts of Docker just can take a long time, particularly if you have a slow internet connection. And so what it does is it downloads all the right acquired assets from Docker Hub. It then builds a Docker image and then it runs it. And the first time takes longer than other times. So the usual rules apply at first run? Yeah. And then we get that same website because they were using the same template. And the great thing here is that now you could be sure that once you build it against your Dev environment using this Docker approach it's going to work when you push it to the next environment. The thing that Docker does for us, right? One of the biggest things and the cool thing from VS now that I've had time myself to play with it you can attach breakpoints, right? All that stuff. Your Dev experience works the way you expect it to basically. Right, so we can change this. Press save. And I believe that was the about one which is actually the one we're on. Cool. So actually. Then just stop debugging to change your HTML, that's cool. Yeah, so. I would have so stopped debugging that. I'm so used to that I call me person of habit. Yeah, so I did not, I didn't change anything. Yeah, so it's watching the file system as you change project files. Yeah, and I think, I think I can even change this. Change this razor syntax. It's probably going to say something not very useful now. But, okay, changes to nothing. But that still proves the point. Yeah. It did take the changes, it didn't compile, I guess, to read the page or. I don't know what actually was, what was in this. Actually, if we switch it back now, let's see. Yeah, that's a good test. Yeah, there you go. So, the main point is, we've had features, like I didn't continue to try and make people super productive. As we've adopted this fairly significant technology like Docker, we've actually tried to retain as many of those high productivity experiences. And I think I just demonstrated that. Yeah, yeah, it's very cool. Now I know we also had a multi-stage build. Sure. Did you want to show that? Yeah, so that one I'm going to show from the command line. It's very new. So, what is it, it's described because even I'm not sure. What are you going to demo? Yeah, so one of the things with Docker that on the face of it is actually there's two goals that are a little bit contradictory, meaning up until multi-stage build, it was hard to be green on both of them, even though you wanted to be. So, I'll tell you what the goals are. One is you want to be using Docker all the time, meaning I'd like to both build my application in Docker containers and then host my application in Docker containers and also do the thing in the middle which is test in Docker containers because the promise that you get from Docker of consistency and reproducibility is equally valuable at all three points. And then the second goal is that I want my prod, my runtime-based Docker container to be as small as possible. I don't really care nearly to the same degree about my dev time and my test time containers. The reason why this was, I won't say contradictory but there's friction in achieving both of these at the same time is because you had to write these scripts that ran, built your app with one Docker container, pulled out some assets and then put them into a test container and then took the results of that and then finally you build a runtime container. So this was all possible but not very easy so a lot of people didn't do it. So what multi-stage build is, you can build a single Docker file that describes this whole thing. There's no scripts. You can actually in a declarative way take the output of one Docker container and use it in another one. And even better yet, you can actually Docker run. So imagine you have like a four stage multi-stage build. You can actually Docker run to just the second or third stage if you want. So you don't even have to do the whole thing. That's cool. Let's show it over. Yeah, so we have, I'll take you to another GitHub thing, .NET slash, .NET slash Docker slash samples. And if you actually go down here to the readme, it actually says multi-stage build. I'm just going to summarize this. It says we've updated these samples to use multi-stage build, which is awesome. And so if I, oh, and I guess I'll show you one of them. So I would actually say we're probably one of the first developer platforms to adopt multi-stage builds. So here is the first from. And we're saying, this is my base image. And then I'm giving a name to this thing I'm about to build. I'm calling it build environment. And then this whole thing through here is build environment. And then I'm creating a new runtime image. So the from command is declaring the start of. Yeah, that's basically your demarcator. And so I'm using another base image. I don't have an as here because there's no need because you only really need an as if someone after you is going to use you. And in this case, there's no one else. This is only a two-stage one. But this second one is in the copyrights referencing that build environment from the provider. Exactly, so you followed the syntax. Yeah, I've never seen this before, but here. Yeah, it's simple enough. Yeah, so you're saying from this other guy, the first one, please grab this directory from that first image and then copy it to the working director. And then let's go. So all I'm gonna show you is, actually we can just do it right here because one of the cool things about Docker, oh no, I need to, nevermind. You need to get to where you're supposed to. Yes, sorry, yeah. That's the one trick you still have to follow. Yeah, let me just see, just make sure. Yeah, I tried it on this machine. So, actually we did Windows before. How about, this is probably a really bad idea for demoing. Oh, you mean something you didn't prepare to demo and you're just like, oh, I'm just gonna demo it. Yeah, let's go. This is toolbox. This isn't a build keynote, you should be all right. Okay, I think it worked. So, let's do. Famous last words, Richard. Yeah, Docker build minus T, we'll say toolbox demo. And then dot. So it means I'm gonna pick up the dot. Oh, I'm in the wrong directory. So that's. I was about to say it's not a. I typed an awesome command line. I'm gonna go into prod. That's the one I think we were looking at. So Docker build minus T toolbox demo dot. And so, oh, it's, I ran this before. Here. Okay, well, it was really fast. I'm not gonna undo the fact that I ran this before. It actually, maybe this is a good demo actually. It demonstrates that the Docker tools are really smart. So when there's, when it's already done the work. Yeah, and no changes I guess. Yeah, it knows that there were no changes. So it's like, I'm good. Cool. But then we can, whatever that spelled. So that was an awesome command that existed. I was like, how is it doing? I think it was toolbox demo, is that what we called it? Yeah, toolbox demo I believe. And so that was pretty fast. This is, I guess actually has .NET Core 1.1 in it. Yeah, and it's running on Linux, which is awesome. It doesn't really matter. And I'd say that startup time was pretty good. We're booting up a Linux container on Windows and then we're booting up .NET Core inside that container and running this app. And in case you can't tell what this is, this is our friend .NET bot saying. Yeah, I love this thing. Welcome to using .NET Core. Cool. Cool, was there anything else we were gonna show? We wanted to talk about .NET standard, but I think we've covered a lot today. So I'd love to have you or Emo or somebody come back and I think we can do a whole show just on that. I think so. We still need to deliver the .NET standard message to a lot of folks and clarify things and as it evolves to who knows. But I think this has been a good set of demos. Awesome, I love this. All right, well thank you so much Richard. I think our findings there appreciate it and we wanna thank you for being in Toolbox and thank you folks for watching. If you have questions, please post the questions down in the thread and we'll make sure all the links that we showed you are available and please come back to the next episode of Toolbox. Thank you very much. Thank you.