 Hey, hey, hey. We're back. .NETConf 2018. I'm here with Kathleen Dollard. I am Beth Massey. I am the product marketing manager for the .NET platform and Kathleen. I am a program manager, I'm sorry, on the .NET Core team and I do CLI SDK. I do some languages stuff and some other things. But today, I'm just doing .NET Core SDK and CLI. That's amazing. Okay. So I just want to say Kathleen, I have been like, you've been my hero, my .NET hero. I've known Kathleen since I started .NET programming back in 2002. I bought a book of yours and it was Code Generation in .NET. Over the years, I met you, I remember meeting you and just being like, oh my God, this is Kathleen Dollard. Wow. And then we got to know each other, we became friends, we got our ears pierced together. We had piercings together. We had piercings together. I mean like, so and now you're here and you're at Microsoft. Now I work for Microsoft. So how's it? Has it been here for a year? Yeah, yeah. So it has been fantastic. I just can't say enough good things about the folks I work with. We've got so many smart, good people that have so many great ideas and we just try to find time to execute on enough of them. That's awesome. All right. So you're working on .NET Core tools? Is that what CLI is? Yeah, the CLI stands for command line interface. So it's the tools. It's when you're typing stuff and I've been around forever and it's like I would never have thought that I would be back doing this typing command line stuff, especially that I'd be working with you. The world comes full circle, doesn't it? Yeah, it does. It's amazing. Absolutely amazing. But it's because it's an efficient way to get things done and that's why we've come back to it after a long journey. There was decades where you could program without really hardly ever typing at a command line. You still can if you're working in Visual Studio, but it's really helpful to be able to drop down to the command line. Even if you're a Visual Studio developer and if you're a Visual Studio code, you generally will be dropping to the command line or if you use a different editor. Because you don't have to use one of our editors. Does Visual Studio use the command line at the core? Or is it directing it? Well, it depends a little bit on what you're doing, but in general not. Okay. Because in general what we've got is a wrapper inside Visual Studio for the things that are being done and then the CLI is another wrapper. And rather than having two wrappers, we sort of shortcut things. And then there's a few things like MSBuild that I'll talk about that are actually a little bit different. Okay. Depending on which direction you're using. So just a little bit different approach. But it's good to know what the CLI is doing so you really kind of know what Visual Studio kind of does and you know a little bit more about how things work. I think that's true, especially for things like a lot of it really parallels fairly closely what you do. Publish is a little bit different and then there's a little bit, you're a little bit clearer on when you're doing a pack and Restore can now be a little bit more explicit. So there's some things that are just more direct. Okay. But it's the same stuff. There's not new concepts, it's just new ways of exercising. Looks like the .NET bot uses the CLI actually. Give me some .NET bot people. I love the .NET bot. I like big bots and I cannot lie. Let's go people. Yeah, all right. We've got .NET bots on the Twitch streamer. It's smart if we have time to show you a bot. We might show a bot. Might show the bot. Okay, cool. Yeah, I might show a bot. All right, .NET bot. All right, let's get to your presentation there then. Why don't we get started, all right? Okay, so I'm gonna start out talking about, talking about how you pick your SDK and something called global.json that some people know a lot about and some people misunderstand and some people have never ever heard of. So let's start with global.json. So this is a file in your project in your repo that's gonna say what SDK you're gonna pick. So let's take a look at the command line. We'll jump down here for a minute and I'll start out by just saying .NET. And when you wanna know what's going on, dash dash help is always great. So then you can find out what's available. In this case, what we wanna do, because we wanna look at a global.json, is I'm gonna create, actually first let me just create a new directory. That seems like such a logical thing to do. And I'll just call it .NET Conf. And I'll just go into that directory. Now I'm gonna create a global.json file just to show you one quick way to create it, which is .NET new. And .NET new will always create whatever it is next if I wanted to do, I'm just gonna do dash H. I can get a list of the templates that are available. Cool. So right now what I'm gonna do- Oh, there's a lot of them. Yeah, there's a bunch of them. And there's a lot more available that are on NuGet. You can go to NuGet and search for templates. We are working on a better experience for being able to find both templates in the global tools I'll talk about later. Right now those are a little bit harder work than obviously would be great. So I'm gonna say .NET new global.json. I think I have to say global.json. Maybe it's supposed to just be one word. I'm looking under that second column near the bottom and it's this global.json. So I'll just make it one word. Okay, so it says it was successfully created. And based on that, and I'm just gonna, let me see if I can pull the bottom of that up just a little bit, it's not behaving itself very well. I just wanna bring that up a little bit so it's not sitting quite bottom of your screen just in case somebody's got, hey, you know, I can bring that up and show off .NET call for you. Okay, then we can put our pretty faces back there. Look at that, look at that and get the bot there for you. All right, so I have set code up so that I can just say code. And that's gonna let me take a look at the actual code of the global.json I just made. Okay, so all it does is say a version. And let me make that bigger, nobody can see that. So it's just gonna say the version that we're currently using. And that's the latest version on my machine. I can change that to a different version if I wanna run a different version. So the way I find out what's on my machine, and my machine, can you even imagine what happens when you list all the versions on my machine? Because you're testing every single one of them for 15 years ago, right? So I've always, it's gonna be a little carried away. Your machine's starting to look like this, right? Whoa, hello, okay. But .NET Info started right, I'm trying to find where it started, it started, right? There's just a case installed. Yeah, right here. Oh, there it is. There it is, okay, so it's, I'll just, no, I can't get that down, sorry. I'm not thinking on that one. Okay, so we'll just get it in there somewhere. Okay, so it tells you when it says version, that's gonna be the latest one, just the one that runs right now if I just say .NET something. Okay, now I can change which one runs by modifying the global.json, so I could make it 300 or a different version. So you rarely wanna do that. Don't you, what if you wanna just use the latest version? You don't do anything. Okay. Okay, this is why, this is why I said some people misunderstand global.json, because I think for most people just use the latest. Right. We have a pretty good track record. It was sort of added just in case we messed up, so that you could, Or if you really were relying on something in a specific version. So this is the way people use it, and for some people it's a really good idea. And that's if you're trying to do a deterministic build, which means today, tomorrow, the day after, the day after is exactly the same. And some people need that. And if that's what you need, you do wanna use the global.json, because it's gonna pin you down, and you're gonna keep running exactly the same version day after day after day, not when somebody updated the machine, we're running something different. I see. Okay. Now, because that wasn't really the driving force when it was created, it doesn't do exactly what I said. Ah! Okay. Aye, aye, aye. All right. And so we're aware that global.json, I mean, if people are out there going, oh, that's just messed up. We know global.json needs some attention. We just have a pile of things we're trying to get to, and it's- So what's the edge case then? It goes forward on patches. So this is good or bad, depending on your perspective. So if you think, yes, of course, I want those security patches, what are you talking about? Of course. So if I had 2.1.300, in my global.json, there is a 2.1.301, there might be a 302, I know there's a 301. So it would run the latest one, that it would run the one it found on the machine, if the one you specified is not there. I see. So if your whole system is locked down to never change, then you will get the same one every time. But if you had two- So you really can only control to the minor version, is that what you're saying? You can't, well, we have to be careful when we start saying minor. You're saying I get patches, right? Okay, yes. The only reason that I'm looking odd on this is because our... We're starting a version conversation. We are starting a version conversation. Earlier than we mentioned, but I'll just real quickly say this. You mentioned it. The major, the normal, what's normally considered the major and minor version position, 2.1, is locked to the runtime. And that's because programmers need to know that this SDK works with that runtime. It totally makes sense. Not what we initially did. We got them out of sync a few times. It was massively confusing. And then we had trouble on the... Trouble's not the right word. We had challenges on the conversion into the system we're using right now. So starting at 2.1.300, then the 2.1 part aligns between the SDK and the runtime. So this is gonna stay this way. So this is just like, we think we're there, okay? So 2.1 is actually the runtime major minor. And then the 3.0.1, the 300 and 3.0.1, that first position, that three, that four, okay? Those numbers are the SDK feature level. Okay. And so I wanna say feature level here because minor and so... I get it. Minor second position after the first stop. So in a way, like you're trying to make it the tools and the runtime makes sense to me. When I get, I'm new to .NET. I am like, I want, okay, I want, I want 2.2. So I should get 2.2.2 everything, right? And then the patch version numbers, I'm just like, whatever. Okay, all right. So what we generally think for most people, what we think is best to do is get, figure out what runtime you're running and 2.2 is still in preview. So today it would be 2.1. And get your 2.1. You can get the SDK and the runtime together, download them together. And that's gonna give you the latest SDK and it aligns with that runtime. Okay, does everybody got that? Yeah, we get a lot of questions. Everybody get that? Okay, cool. All right. I'll get to global tools. We'll get to global tools. Kathleen.NET global tools and templates are awesome. Using it in Bionic, very powerful. Nice job. Yeah, okay. All right. All right, what are we looking at again? What are we doing? Okay. So we've just done global.json. So, and I did, that was dash dash info. .NET dash dash info tells you everything you have. It gives you a lot of information and it's a place that if you don't know what operating system you're running, you probably know that else. I don't know. We'll tell you again. And we tell you what then says, which is a rental identifier, which is the way that .NET Core expresses what you're currently running. So, and we've got the base path and some other things in there. Okay, so let's come back over here. And this is just, my slide deck just kind of restates what I've already said. And that rolls forward only on the patch version. Okay. And that will otherwise give you an error. And there is another reason some people just came in in 2.1 that you may be using global.json and I'm not gonna go into this, but if you hear about custom tasks and targets or a custom SDK, it's new tasks and targets that are coming in and that's also defined in a global.json. Okay. And the way this works is it just starts at whatever it's, wherever you did the command and it walks up your directory tree until it either finds one or gets to the top. So that is, that's global.json. That seems like totally normal. Okay, so now you've got your SDK. Okay. So that was what this was about. And what I, I also, I didn't say that if you look for download.net core, you should be able to find that and get the latest SDK. .net core just go to www.dot.net. Yeah, do you want me to do that? Yeah, go there. All right, let's do it. Let's, I've got a couple of things up that I'll be looking at later. Yeah, we tried to make the experience super easy on the website here. .net core. Just say .dot.net. .net, bam. Yeah, that's it. The website, go there. .net. Well, they're okay. There you go. Is that it? Or, yeah, that's it. Or search for it. I just said DOT. That's it. It's a search. DOT. Wow. Are you kidding me? D-O-T in Ding brings up.net's website. Yeah, no, DOT.net. Oh, okay, yeah. DOT.net. Okay, in search. That's good, because that is the name of the website. It is. I'm on a Mac, I think. Yeah, there you go. We should be good from there. All right, and that's how you know it. And then if you do want an older one, you can scroll down and there's a lot of, there's a lot of versions available. Just get the latest. Oh, this is a good question. How do I purge all of my old SDK and runtime versions for my system? I think it's up. I know we're working on a docs. So Microsoft docs is docs.Microsoft.com is absolutely fantastic. And I believe that we are up. I know we've been working on an article that says how do you kill them? It depends on your, it... You throw the machine out. No. Buy a new one. No. You can say I haven't run a rest doing it. So if you're in Windows, it's an uninstall. Okay? All right. So you go and like program. Yeah, it's whatever it is. It's however you get rid of stuff on your machine. Can you just go delete stuff? Like right off the desk? Well, we have things if you place it, so you can. You can? I don't know if it's, you might be cleaner. So you can probably, you can only do it on in Boutu apparently. Yeah. Okay. So if you're on a Windows machine, you know you got the programs. Yeah. Got it, all right. Okay, so what I wanted to do today was to kind of walk through a little deeper and I should just actually make an application here because it's super easy to make an application, but then that's boring. There's nothing else to say about it. So I'm just gonna make a console app here. So I'll just do a quick, clear this out for you. And I'm gonna say .NET new console. Okay. And I'm gonna put that, I'm into .NET Conf, but I'm gonna go one level down and I can say dash O or I can say dash dash output. If you're from Windows, that's the POSIX standard that we adopted, which is part of Unix and it's just a little bit overall more consistent than what was going on in Windows. So we decided to go that route. Okay. .NET new console output, I need to call it something. So let's call it Hello World. Okay. Wait just a second. I'm gonna do some restore. Again, I'm just gonna say code dot and I'll come up there. Now in the, I'm one level up where I put the global.json. Here's the directory I just created. It's where I was when I typed code space dot. Okay. And now we look at the program file. Hey, isn't that exciting? We'll just close that. So there we go. I have a, it just needs to restore some things because it's new. Okay. There we go. That's it. Okay. So it creates like, it's a template for an application. That's a template. So now if you want a console application, you can go to town. There's other templates as you saw, but we're just gonna keep things super simple today. So I just wanted to have an application out there that we could play with. So creating an application is super simple. You've seen stuff here at .NET Conf about where we're going with ASP.NET Core and some of the other things we're doing. People probably heard that part of .NET Core 3 is gonna be WinForms and WPF. Yeah, we're bringing desktop. We're making desktop. So happy. Modern. It's all modern. It's great. It's coming to the new runtime. I like it. So all of those things have been discussed elsewhere and I'm gonna just let that sit and I'm not gonna try to make the app any more complicated than this. What I wanna do though, is just talk a little bit about how things run. A little bit more detail on CLI and SDK. Like what's happening? Yeah, but I also wanna say that just like global.json, for most people, most of the time, just ignore it. You don't need one. But the same thing goes here. I'm gonna go a little deeper than most people need to worry about just to show a little bit more about what's going on. Let's do it. Okay, so let's come back over here. So I'm gonna talk a little bit about the project system NMS build. So some of you may have heard that we changed the project system twice. Who heard that out there? Anybody? Yeah, so the old project system. OPS does not stand for old. Stands for original. So there's... Is that what OPS stands for? I believe so. We use way too many acronyms here. We do, we do. I was thinking OPS, is that a file? So I think part of the great thing here is that we internally, it's too easy to say old just because old and new. But it's not old and new. It's OGPS, the original gangsta project system. Right, let's do that, let's call it that. So the thing is that the original system is perfectly fine. It's just complicated, okay? So there was reasons to update it. Are you talking about the XML thing? Oh yeah, the XML thing. Like with the GUIDs and the things you're never ever ever supposed to touch that thing because no one could understand it anyways. Is that one? Yeah, except if you're a VB cutter you have to change your language version but we're working on that too. So yeah, it's big and it's ugly and you don't want to have to go in there. So back in the dot-it framework projects. Right, that's when it started and it was originally a file. You were never ever going to look at it so it could look horrible and it does. And so then project.js. It really just tells Visual Studio like what solutions are in there and projects and files and all that stuff, right? It was really for VS, right? Yes, just to correct you a little bit. It's mostly for MS build. Okay, sorry. So MS build runs by Visual Studio. Visual Studio accesses MS build to do that work. Visual Studio also uses it. But I just want to be a little bit precise on that. Very good point. So we have the original project system, okay? And then along came sp.net early versions of Core. We were playing with it, tried to get a cross-platform and we were trying to think of a better format. And one of the things that was done there is it's like we've got to make this thing simple. It is stupid complicated. So there's ideas about globbing that are very common now in the industry. Globbing just means you can use a star and get everything that matches instead of having to list every single file. So that was one of the things that really needed to go. So they came along with project.json, okay? But the problem was is that was a new project system that was only going to work in certain cases. It wasn't going to work for everybody everywhere. So we have like four million.net developers out there and they're like all of a sudden and they're like, and they're like, we want that globbing stuff. We want the good stuff. We want to be able to read our files. So we need the best of both worlds. We need the best of both worlds. So they got, so basically the project system was evolved to be a new project system, which is called, I had to write it down. CPS. The common project system, because I want to call it the current project system. And that sounds like there might be another one. CPS. I hope not. So it's called the common project system. And it's called common because them is filled that it works with actually can handle the original and the common. It can handle global performance. So you can hand edit this thing. It makes sense now. Okay. You shouldn't have to use a tool. Do you want to take a look at it? Yeah, let's take a look. Let's look at this thing. So I just built this so we could. So I'll go ahead and just give us a little bit more room here because we don't need to see the body anymore. Let's hide the body. I'm not killing it. That's it. That's all you need. Oh, okay. And in fact, it could be quite a complex project and that's still be all you need because it knows, well, you know, if you didn't tell me differently, we think you want to use star.cs. So everything in the folder. So you're going to use, yeah, all the files there. Right, okay. So we think that everything underneath this, you know, in this tree structure that is a.cs, if you don't tell us anything else, that's what you want because that's what you want. So yeah, that's the. So don't put anything you don't want in the project in the folder? Well, you can exclude it. You can exclude it. There is an exclude. Oh, that's nice. So there's things you can do. But yeah. Yeah, but kind of, okay, gotcha. So massively something, just not a little bit simpler, mass of the simpler. And so this new file, the new project system is just great all the way around when you can, you know, whenever you can use it, which is on.net. Core, okay. Right. So the. And Visual Studio actually lets us edit it too now, right? Yeah, it does. Without having to reload and reload and unload. And you don't have to do that anymore. It is still XML. But I am a huge fan of XML and for, you know, folks, I want to argue with you. It was the first book I read from you. Yeah, yeah, yeah. We won't talk about it. It's all too. XML allows comments and it allows a very clear two levels of information. It allows the actual node and it allows attributes on the node. And those two levels working together can make for very simple explanations of the importance and what things relate to. So it's a nice system for a project system for anything with some complexity to it. And, you know. Did we still need to change MS build a little bit to read this? Well, we haven't knew. It's a new MS build. We have two MS builds now. Okay, so. There's two. There's two. I was going to say like, we changed the format so we had to change the build system a little bit. Right, which is why there's the new, the new common project system can read both original files and common files. And the old one has no idea about the common file system. So it can't use them right. All right, all right. So because there's two built systems, you might need to access them both from the CLI. That could happen. You could do that. You can. And this was actually, I asked on Twitter for some people who could, you know, have some questions that maybe we'd want to answer today. And I hope you're keeping up with what we're getting asked here. Cause I don't want to. I'm totally keeping up. They're actually just saying how much they love XML up there. Ah, good. All right. So anyway, the question was when do you use .NET build and when do you MS build slash T? Okay. Sorry, I forgot what the slash T is for. What slash T mean? I'm sorry, I forgot. But that's the way you, on the command line with .NET CLI, you do MS build slash T and I don't remember what the slash T stands for. I'm sorry about that. Too legit. If somebody on the team's watching, you can jump in here and remind me what slash T stands for. But anyway, this just talks about the different, what each one of them does. So if you say .NET build, you're using the .NET core, which is that common project system, the newer system. You're using that build system. If you say MS build, you're using the older original system, the .NET for .NET framework. So that's the difference. Then there's some other things up there. There's some defaults that seem logical, like you actually don't want to forget the restore step because then your build isn't what you thought it was going to be. Automatically restores when you do a build. That makes sense. Which Visual Studio does. You may be quite used to doing. Because it didn't do that before, right? Yeah. For a while it didn't. Yeah. For a while it didn't. I remember like, why am I doing this? Yeah. It was a very easy mistake to make. So that's nice. So it does some things, minimizes the verbosity and it's parallel by default, and just various little things. The original file system doesn't do parallel builds which are particularly important when doing multi-targeting. Okay. Because you can spend several at once and that can really reduce the time. We are constantly trying to make that better. We know we will never be fast enough, but we're going to be fast. Well, we did speed up build time significantly in 2-1, right? Okay. 2-1. Someone actually says the T command can specify a target. A target. I'm using it right now actually. All right. Okay. Great. All right. Thank you for the education. So now I'm just not quite sure why you would need it. Why do you need it without specifying the target? Yeah. Next question. So it could have just been the way an email came to me and I may be confused. Okay. Sorry about that. Because I actually double-checked this one. I asked for this one. That would be the point. Yes. Okay. Totally good point. Target is also defined in the projects. All right. Well, the key point to the slide though is that .NET Build is doing some things for us by default. That makes sense. Right. You probably want .NET Build almost all the time. Okay. So that's probably what you want. Then any additional, you can pass a lot of extra stuff on down to the, there's quite a few switches you can put on that. Okay. Okay. Cool. So we just did that. Let's go forward. Before we go on, let me go ahead and build the thing we wrote. So I'm going to say .NET Build. Okay. Ta-da. It built. Okay. Actually, it didn't build. What is it? So you have an error? Yeah. I have an error. People at home probably figured out what it is. I'm not in the right place. So- You need a slash T? No. I'm kidding. I'm totally kidding. That's good. No. I decided to create this as Hello World, and I was not in the Hello World directory. So it's going, we had no idea. We do not see a project file. So would you mind telling us what we should do? And I could have done this a few other ways. I could have told it where the file was, but instead I just changed the directory. And now when I say build, it should come back and it's going to restore. And it says build succeeded. Got it. Which is what I wanted to see. Okay. So you either need to be in the directory, you need to specify where the project or solution file is to build. That totally makes sense. Yeah. Okay. Use your error. See? Got it. Do you want to do it? Should I change it and say hello.NET Conf or are you good? Yeah. Change it and say hello.NET Conf. Or we like bots. Where are the bots people? You want bots? We want bots. Do you need bots? We all love bots. You know, I can tell you where there's bots, so I can go get bots. How do you, is it like this? We like big bots. Is that the way you want me to open it? There you go. Let's do it. You can run this. Let's do it. All right. So you really want bots? Yeah. Let's go ahead and just say.NET Conf. Because you know, like honestly, you haven't actually written a line of code yet. I just, I changed the line of code. You just changed the line of code. I changed the line of code. So yeah, let me, that just is how I make sure that the save happened, is to leave it and go back. So this isn't a fake demo. We can do what? Oh, it is a fake demo. Hello, world. I mean, you've got to build this again, right? Awesome. Now run it. Oh, wait. What happened here? What? Did, oh. Oh, dear. Now we're in trouble. What happened? Did you save the file? I thought I did. It's, let's get rid of the release notes. It's looking safe. Are you in like a another directory possibly that you practiced? You're a practice directory. It certainly is possible since you, but I didn't think so. .NET Conf. Hello, world. Some may homesies are a problem. We're not going to stay on this too long, but I am a little bit confused right now. What directory is it? It looks, I am in .NET Conf. Hello, world. I've got those guys there. I don't know why. I can tell you why. Why? You are absolutely right. I messed myself up. You are in the wrong directory. You're like a tester. I'm not in the wrong directory, but I messed myself up with mine. This is not how you run an application. I just spaced on this. This is not how you run this application. I'm going to talk more about this. But this is a DLL. So if we actually, let's do something to make our life a little bit easier here. I'm going to go back to this build. And I'm going to say, I'm going to give it an output directory, which I'm going to call FDApp. I'll explain it or why I'm calling it that. And so now, I should be able to kill the bin in OBJ directories. And I want to show what's in that directory. So I just called it FDApp. And so now, this is where my output of the build just went. And I'll tell you why Hello World worked in just a minute. Because that is really the real question right now, is why did Hello World work? So if you see here, there's a couple of files. But you will see that there is no executable file. Right, OK. Because by default, .NET Core builds DLLs, not executables. So what I need to do to actually run this, and let's do that first, is to say .NET. And then I need to give it the from here, how do I find that executable? And I'm not in the FDApp directory. So I'll say that first, and then I'll say Hello World. And then I'll say DLL. And now, I should say Hello.NET Core, OK? Now, step one. OK, but wait. So what we've talked about is the build that it did. How did Hello World ever work, is the question you got. Yeah, that's exactly where I'm at. This is where I mess myself up from my practicing for my demo, OK? I happen to have, and I'll get back to what this means. You had a practice directory somewhere. No, I have a global tool, because I could never run a DLL based on that, OK? I have a global tool that is called Hello World. I see. Which was a best tool. It was overriding you just now. Basically, yeah. So we'll get back to more about what a global tool is. Global tool is something that it's a console app, that when we install it, we put a special shim on it so that it acts like an executable. And I'll talk more about that shim and what we're doing with that whole idea. So with the shim on that, and then we put it into your path, OK? So what a global tool is, is an executable that we help you create that goes onto your path, into a special location on your path. And then from any place on your machine, on that path, any show where that path is active, you're going to be able to run that global tool. So the community can create global tools and you install it right in. Absolutely. So it makes the CLA extensible. It absolutely makes the CLA extensible. And the install comes through Nougat. So we already have a good place to go with them so people can find them. We're definitely still working through Kinks on this, particularly they're hard to find right now. We don't yet have a good search, and that it's just because we have to coordinate a lot to make that happen. But if you go to Nougat and we're working on being able to search for tools. I think we need somebody in the community to create like globaltools.net. You know what? We've got a little bit help from that. Naming Masters has a GitHub site where people can add their tools. But yes, we've talked about a desire to download, and I mean, we can help somebody write that part to go to Nougat every day or every hour. Pull the tools. Pull them all down, you know. Oh, maybe we should do that, I don't know. Right, maybe we should. But then we need to run a website someplace that has that. I know, we got a few like.net. You know, honestly, I know this sounds a little insane, but it would be a great global tool to find global tools, okay? So. That's so meta, Kathleen. It's so meta. But if somebody wants to work on that, we just need a website someplace that has the ability to get back a list preferably with some stats and ownership that can give a list in a global tool that can then just display those. So we haven't written that yet. We know this is badly needed, but it's, you know, if somebody wants to write that, just tell us. I'll give it a shot. I got a lot of like, maybe time during Christmas. Do you? Yeah, all right. I was thinking of rewriting the .net cough site myself at Christmas, but I'm gonna add this to the list. This is definitely on our work item to have a more complete answer for this. We're kind of muddling along on that side of it. But that's what happened. It's why when I tell a world. Yeah, discover.net.net. This shouldn't have. Look, you put it there. You know, that guy's site is super awesome. Is it? Discover.net.net. Oh, yeah, we totally. Well, I'm getting in touch with me because I'm all over time to solve this one. Absolutely. So I have an executable in my path called Hello World. That's the only reason that this worked. Should I make that even bigger? Yeah, you can make it a little bigger. So that's the reason Hello World worked. To actually run this, what I need to do is .net. Then I need to give the path to the DLL, which is FD app, and then Hello World, and then I need to give the DLL as well. And now the .net is an application, of course, and that application can do several different things, one of which is act as an app host to run, as it is right now, to run a DLL. All right, so. There we go. All right. I'm actually glad we made that mistake. Because we could explain. It sounds good. Our mistakes. Yeah, glad we made it. Okay, so let's talk about that. And this really should not be executable because I should have named this section a little bit more like running stuff. And you just saw one way, the common way to run stuff. And so it's like, I wanna go fix my slide here. It's really annoying me that much. Are you gonna let me fix my slide? Oh, you're gonna do live edits to our point now? I'm gonna do live edits to our point. Whoa, hold on. Okay, because that's just, it was a terrible name. And it's just, oh, I don't wanna go to my big camp. Okay, come on, start that, come on. Did it work? Did it work? It's black, it's black. Build PowerPoint. Oh my gosh, oh my gosh. See, I don't think we should have tried that. I think we did the wrong thing. Oh my gosh, it's like, it's flipping out. I've got two different things on the two different screens. Oh my, all right. Okay, it released it out on my screen. Well, you got it there. Okay, well, we'll see how it goes. Okay, so. Told you, live editing. Live editing was a bad idea. It's a live show, people. Yeah, I do not sing this on my, on my, I might have it really seriously. It is my boot camp. It's, I've got my, my parallels partition. Oops. Okay, unfortunately, I'm not. Oh gosh. I think we just locked it up. No, it's not that bad. Okay. Okay, I'm just like the presenter. You're back. I think I'm back. All right, whoo. What you just saw was a framework-dependent app and it was absolutely not. It's a framework-dependent app. It's a Friday afternoon. So, I have no idea what's in that bottle. Um, all right. Me neither. Okay, it was a framework-dependent app. That's what you just saw. Okay, so it's got a simple publish directory. It was small. You have to type the name of it. And all apps share the same copy of the framework. This is super important because it's gonna go and run the runtime now. We talked about how to get the right SDK earlier. Now we're talking about what runtime is gonna be in place. Okay. Every app on the machine can use the same version of the framework. So, I'm saying that a little bit too generally because you will normally- It can, but it doesn't have to, right? It can because the project file normally lists what your target framework is. So, what version of the framework you wanna run against. So, one app might be running gets two O and one might be running gets two one, all good. Okay. So, in ASP.NET in particular, this is good because you may have many apps on one machine. It also means that your operations team determines when you have an updated version of the runtime. So, if a patch comes out, then the operations team decides whether or not you're gonna apply that, okay? So, the next thing that we've got is called a self-contained app, okay? A self-contained app is an executable and I'm gonna build one in just a second. It's got a rather large public directory. We can take a look at that. It does create an executable. It does create a very big hello world. I think it's about 250 megabytes. It's great for a standalone deploy. So, if what you want is to create an application and it's gonna go run off on just like, it's gonna run someplace and you don't wanna ever have to worry about putting the runtime there separately. It carries it along with it. So, it's like an entire folder though of stuff, isn't it? Right? It's not a single exe. I'll show you that in just a second. And one thing I wanna point out here is that you see that it says dash R and that stands for the runtime that you're, the framework that you're running against. It's actually the platform, I'm sorry that you're running on. And so, with .NET Publish then, if you say dash R, then it's gonna go for that specific platform. So, let's take a look and see what that's gonna look like. Is this gonna come up? It didn't come up. Let's kill, I need to kill, I'm up in... Can you go into presentation mode? I'm trying to get out of presentation mode. So, if you, well, you're, oh, you're in future. Yeah. Yeah, there's no where I wanna be. You're on a Mac, so it's usually Windows P, but I don't know. Yeah, the problem is I don't have a, there I have it. We're gonna end the show again and we're going to... Yeah, maybe that was it. Try to find, there we go. Hey, I see your screen now. And then I'll start back up in just a minute after we do this. Yeah, right. Oh, right, okay. So, what I wanna do is .NET publish. And the publish only puts things into the right output directory when you're just doing a framework dependent app because there's not that much to it. But now we're gonna say dash R and I'm on OSX64. Trying to remember what the RID is. I'll tell you what you do when you can't remember. RID, runtime ID. Runtime identifier, right. And there's a list, runtime identifier list. So, you can go here and say there's the windows, there's Linux. And if we scroll down, we're gonna see the mac ones. So, it's OSX-X64. That looked like a lot of X's in my head. So, I tried to take one out. There you go. And now we're gonna do an output to, and we're gonna just call this self-contained app. So, we'll create a new directory and that way we're gonna be able to compare the two. All right? So, we get another successful build. And, I was a publish. That's why we didn't get build succeeded. Oh, publish. Right, okay, so I'm gonna say. So now we have a folder of stuff. Right, so this is again the framework dependent app. Okay, and this is the self-contained app. Okay, so we have, we take that whole folder and we can put it on another Mac that doesn't have any .NET on it and it'll run. That looks. Is that what you're saying? Yes, we absolutely can, but look. It's a lot of stuff. Yeah, yeah. All right, so this is great for some situations. Okay, but these two together really aren't everything that we should have. We have some more things coming and that's why that next slide says future. I want one exe, Kathleen. Can we do that? We're working on it, but that's not where we're gonna go next. Oh, come on, please behave. This is just so. All right, we got a question while you're figuring that out. What if we want to make a JIT compiler interpreter for .NET Core? The goal is to run, I'm thinking ASP.NET apps without recompiling all the app every time we save a file, probably ASP.NET. Instead, we compile in the run time only what we need to run, just like PHP. Is that applicable? If so, what do we need to know to accomplish that? So they basically want to save an ASP.NET app and have it come out automatically. I will tell you that I have kind of a knee-jerk reaction that that's gonna be super hard, but I also know that some of the folks that work on the compiler team blow me away sometimes. They're pretty smart, huh? Yeah, oh yeah. So basically, we have an incremental compiler. It builds this big syntax, semantic trees, and then they normally outputs and we run from there. You'd have to hold that, basically, because the way that this strong type language works is you've got to kind of have all your references. You have to be able to get the whole nine yards there to completely interpret the semantics of it. And so it's gonna be, I'm not gonna say it's impossible, but it would more or less be a way that we, because browsing, we just have to kind of keep being there. When are you gonna be able to like, maybe like, I don't know, when you save the file, like do background compile? Well, some of the background, so you could do something like that. Like that, I don't know, maybe, or maybe that would help the scenario at least. Right, right, and I don't know if that's an area, the CLI scenario. Right now, we do spin up the process and kill it, spin up the process and kill it, and we've done a little bit of work with some background stuff to get some of the jit to speed things up, but sometimes I do wake up at night and wonder whether we should actually be keeping something running in the background for the purpose of performance and some other things. Let's just talk to Rodrigo Compera. All right. Hey, we are working on it. Awesome, awesome. Can't wait to check it out. Great, fantastic. So let's go back to my slides for a second. So I want to talk about framework dependent executable. And so this is, it has a simple publish directory. The executable gets created and apps share a framework, okay, and it rolls forward. So it's got the best of these two worlds together. What we basically do is that an executable has to be specific to the platform it's running on, and executable can't be just like anything. The DLLs we're creating, they can run anywhere, but an executable has to be created for this particular platform. And so when it's happening, and we put it out first with global tools because it just happened, we could control the creation very carefully there because we're in charge of that process. So we created the shim that we use for global tools. That was the first place we saw this. And now this is going to be coming out in either 2.2 or 3.0. I don't know what milestone we're hitting it on. But this is the way you get to that. And I'm actually going to skip showing you what's in the directory, but it's almost like the first directory where we just had the DLL and a couple of the other things. There's a DLL and an executable because we're creating that shim for you that still calls in, but you have to be read specific now. I'm a platform specific now because you have to say where you're going to run it. So the DLL can still run anywhere, but you need to create the exe piece has to be for the platform you're running on because that's what brings in the right, the framework for that, for that current platform. Gotcha. So you have automated builds, you probably are building all this like ch-ch-ch-ch. That's if you like, so there's two ways to think about it, right? Like I could say, well, maybe I just give them a DLL and have it JIT. Or maybe I want to like pre-compile it all together and it's for a specific platform. Is that like the kind of two options things? All of this is pre-JIT. Okay, so this is just going to be how do we get the IL bits to the right machine. All right, got it. So we're just, because we have to point out the app host, that shim that we created as it's executable, this new thing, and that's go out and get the right copy of the runtime. That wasn't a problem with self-contained because it's just use the one that's already in the directory. Use everything that's already in the directory. And so that was the challenge of getting that done and that work is now it's done. And if you have nightly builds, you can take a look at it and it's just going to be a little tiny bit bigger than the, and we know this is something people have been waiting for so we're very excited that we've got it at a point that we're comfortable releasing it because we know it's, it means that you can start looking at, well we have to do some work to do things like in Windows, being able to put an icon on and stuff like that. That's not really. I see, I got you. It's just kind of simple and executable. Okay, awesome. So let's see what else we've got here today. I'm going to, oh also. Oh, the future. Yeah, this is another future. We have an in-preview or linker. So this is another way you can work with self-contained apps. That's what I was really wondering. Yeah, what's going on with the linker? The linker. So the linker is, we're still, it's still in preview. Okay, it's still on my get and you can get, that you can find out about it at that link. Okay. And then it removes unused assemblies which means it might break your code. All right, so use this carefully. It's the reason that we are moving carefully is because there are scenarios, absolutely you will break in production and we can't guarantee that's not down some side path that doesn't happen until your vice president is running the application. Well, I mean that's why it's a preview. But you could try it on a copy of your production and let us know if it works or not. Absolutely, and test it and look at it. There's certain areas we know is broken. If you have something that it's broken on that you think it should work on but we're not ready to make this a default because we don't want to break anybody. So we'll be working on this and figuring out the best way to introduce it. I think that the technology, the guys that's fantastic, the teams have worked very well on that. I think that the technology is good but we don't quite have the right way to incorporate it. We need more feedback. That's right. Great. We just actually did a survey on that. So you know, I'm gonna like really vote the CEO out. Like that's a comment. All right. I'm gonna be kind of light on tools because we're just gonna talk about how this works and because I'm a little afraid of having my machine go. We have a little slide problem there but that's okay. All right, so global tools. Let's talk about global tools. Global tools are available right now. You get them by saying .NET tool, install slash g, my tool. Slash g stands for global and yes, the implication is we will do local tools and that's consistent with NPM. We don't want you to have to think two different ways. One when you're doing NPM package management and one when you're doing .NET package management. So we use NuGet with all the NuGet things including NuGet config so you can go to your own feeds. You can go to whatever your own feeds are. You can go locally if you like. So this is installed in your path. I talked about this earlier. It's a framework dependent app that we build a shim for and that which provides the app host so that you can just run it. Which is why I could just run Hello World. So we've already seen this. Right, accidentally. Yeah, so we got that, okay. We're just a little ahead there. So we're coming, we're working on the, still working on the details, but we're working on details of what will be local tools. For a while we call this repo tools, but we honestly don't know where your repo is so we can't, it sounds like we know and we don't so we're just gonna call it local tools. And this works differently. So it won't have a g, it might have a local but we're leaning right now to just like npm. If you don't have g, it's local. So that's where we're leaning right now. Again, we don't want you to have to think differently when you come to .NET land. Also from NuGet and there's a repo manifest now. And so what we expect to have happen is that from whatever you run a command it will start looking if you say, and you'll say .NET for this because you have to be in our world. We have to have code running. So .NET space and then if it's Hello World, .NET space, Hello World and then it would look up the directory stack for a repo manifest. We're still working on what to call that. And then when it finds one, it will find out where to go get it which will be in the NuGet cache so that you can control how things are on your machine. You can share it, you don't have one for every copy. So the manifest will be repo based is what we expect and then we'll store it in NuGet. And it will still be a framework-dependent app with a shim. So all that will be the same. Oops. Version numbers, we already talked about that. We already kind of talked about that one. We can skip that. Okay, so this just gives you a way. We're making it better. But you can talk about it more. Yeah, yeah. Read more about it. Read more about it. You can talk about it if you want to. Fixing it all. And it's, we don't need that. We already did that. We did that, didn't we? Okay, I'm just trying to get to our last slide. Oh my gosh. There it is. There's my last slide. Last slide, all right. All right. This is a lot. Fantastic, actually. So, all right. Looks like we have people just talking amongst themselves right now, helping each other out, actually. So, anybody, any questions out there? Somebody's searching for some monopr numbers, so hopefully they can figure that out themselves. I'm not really sure what they're talking about. It sounds like maybe somebody had mentioned it earlier. I did not mention a monopr number. Sounds like somebody has an available tool there, too. It's the linker. That might be about the linker, because it is. But we've taken the mono linker, and then we kind of dot-netified it. So, it is- The mono's not on that, too, right? It is, it is. But we just, it was just brought more into .NET Core, and it was created, it's a NuGet package on my get. And .NET-core.linker is what I think, aka.ms, do you want me to try it out? To go find that, I can maybe find that right here. I think, yeah, maybe. Hang on just a second. If it's handy, it's a question. Well, if I can find my mouse, it'll be handy, but my mouse- Measure mouse, it's flying on the screen there. My mouse keeps just being whacked. All right, so I just- Here's a question. Does the .EXE file still included on the 2.2 publish? Or is the .EXE file still included on the 2.2 publish? I would assume 2.2 preview? The linker was, I'm sorry, I just went past the linker again. Just a second, I'm getting the linker for you. The linker is on this slide. There you go. There's the link. Ah, there's the linker. Okay, that's the one you want. So yeah, the question is- Sorry, does the .EXE file still, is the .EXE file still included in the 2.2 publish? So, in the preview? Is it still, if it was, it should be. I said I wasn't sure whether that was in 2.2 or 3. If it is in 2.2 already, it won't, I don't think it'll be pulled out. I don't think that would happen. Yeah, we just released preview 2 on Wednesday, so do you know offhand if that's on preview 2? I do not know. I just didn't track down which version that's in. I apologize for that, give it a shot. And yes. Okay, all right, well, all right. So I guess we are done. I just want to like give it a big hug. Oh, it's so good to see you. I miss you. I love you so much. All right guys, thank you so much for a great show, a great conference, and we have coming up. I think we got some game development coming up. We did, it's fantastic. All right guys, whoop, whoop, see ya.