So I am Damian Edwards, and this is Mr. Fowler. We work on the ASP.NET team, and we're here to talk to you about the great transition that is about to take place, where we are going to kill our baby that we spent the

last two and a half years building, and replace it with a new thing. You could just think of this as the 4-3 name, because it started out as, what, KRE, then XRE, and then DNX, and then now it's changing to this new thing called the .NET Core CLI. The last rename you promised. The last rename. Yeah, we totally promised.

Again. So everyone knows what DNX, anyone not know what DNX is? You're going to be really confused. One person. One person doesn't know what DNX is. Well... Doesn't matter. You'll be fine. Just enjoy the show. Ask someone next to you what DNX is. So why is this changing now? We just released an RC1, right? Like in November, we pushed out RC1, and generally when we do an RC, you kind of hope

that not much changes before the next RC or RTM. So for that, I apologize. But just the stars kind of aligned in a certain way, such that we're doing this now. DNX was built by the ASP.NET team. It was built by us. It wasn't built by the .NET team. They are two separate teams that work very well, very closely together.

And we built this while we were building ASP.NET 5, because we needed to make ASP.NET 5 run cross-platform, and such we needed to make it runtime-agnostic. We wanted ASP.NET 5 to be able to work on the core CLR, the new .NET core CLR, but we also wanted it to work on the .NET framework, the standard .NET that runs on Windows, and

also Mono, right? Which is kind of the .NET framework equivalent that runs in many, many more places. So we had to build this new technology to do that. And also in doing so, we invented essentially a new app model to do that, and DNX sort of codified and represented all those things.

And we built it for us before anything else. But because we kind of came up with a new app model, it did confuse a few people. So at one point, we had a template called ASP.NET console application. And people looked at us with tilted heads and said, what? What is an ASP.NET console? And so we really needed to take a step back and see if we could address this at this

point. We had people in Microsoft come to us and say, okay, so .NET core, cross-plat, that's good. How do I make my thing run cross-plat? And we go, well, you could use DNX. And they go, isn't that ASP.NET? And we go, well, yes, but it's also good for other stuff.

And then the .NET team were like, well, we want to be part of .NET cross-platform too, of course. And so we decided, well, this is a much better way. We need to build something better. We need to do something better that is built by both teams, suits all the use cases that we wanted to solve in ASP.NET 5, while also being the thing that represents the .NET core

application model cross-platform as well. And so that's what we're here to talk about. So let's revisit this term, because frankly, we haven't done a great job, I think, in coming up with a name for this thing. So .NET core has been used to describe lots of different things.

If I was to ask any of you what .NET core was, I doubt any of you would be able to give me a really good answer. In fact, I might get lots of different answers. And I think we've used two different versions to represent .NET core as well. Sometimes it has a version, sometimes it doesn't. We called it .NET core 5 at one point, which is confusing, because .NET in Windows

is .NET 4.6.1. And does that mean .NET core 5 is bigger and newer? It's just a little not great. So .NET core, this big blue box, there's really four things that you need to think about. The first one is core effects. And core effects represents the framework.

It represents the BCL. Think of this as the new BCL. These are the APIs that you will call, the libraries. And actually, up on GitHub now, of course, this is all open source. The repo is called core effects, which makes it kind of easy to remember. So we have core effects. This is system.collections, and system.numerics, and system.file.io, or whatever, right?

Then we have the core CLR. Now, the CLR is the traditionally native part of .NET. It's the thing that knows how to run your application. It includes the jitter, it includes the garbage collection stuff. It includes the native hosting APIs that can boot the CLR itself.

So there's a new one of those. It's called coreCLR, and it has a history that spans all the way back to Silverlight 2, when we had .NET running on a Mac, in a browser, if you remember. Silverlight 4, I think we had Silverlight on a Mac. And then we had Moonlight, which was the Linux port of that.

So coreCLR is smaller, faster, better, designed for cross-platform workloads. It's also the underpinnings of the universal Windows platform, UWP apps. And coreFX is used in that scenario as well. Then we have a really new thing, which a lot of you probably haven't heard of,

which is called coreRT. It stands for runtime, because why not have another runtime? We have the common language runtime, we have the core runtime. This one is used as part of the .NET native toolchain. This was also announced in November. Hanselman did that up in New York. And this supports the concept of compiling a .NET core application

all the way through to native, to a native image, to machine code. So that I build my app, I run it through this compile harder step, and then out the end, instead of IL, or intermediate language DLLs, I get a native image. And there's no runtime DLL, there's no anything else, there's nothing.

There's nothing installed in the machine, there's no redist, it's just an executable, it's just machine code. And it includes all the parts of coreFX, and all the parts of the coreCLR that your app used. Okay, so there's a little bit of overhead, it's about, I think the minimum overhead is what, about 900 kilobytes?

So hello world is like 903 kilobytes or something, at the moment, as it is right now. But this is the thing that runs your native .NET application. Okay, it's very, very early on. I'm not going to talk much more about native today, we're going to keep this in the context of DNx. And then we have the super new thing, which we also announced in November,

which is the CLI, the .NET Core CLI. And that's what we're going to focus on right now. So the .NET Core CLI is what we call a driver, it's a command line driver. And we'll have a look at this obviously later on. But you need to, the way to think about this is that it's a tool chain. It's a set of tools that you use that are command line based to build .NET Core applications.

Okay, so there's that word again, .NET Core. What does .NET Core mean now? So if we go back to this slide, I think the best way to think about .NET Core now is that it's the cross platform .NET stuff for Microsoft. And as a result, it is smaller than the .NET framework

in sense of API surface area because .NET framework has a lot of windows specific stuff in it. Has com interop and it has directory services and it has WCF, WPF, WinForms. .NET Core is a cross platform ecosystem or platform for .NET. So this is the command line that you use.

You could think of it as an SDK. You install it and you build .NET Core apps. You install this via a platform package. So in Windows, we generally use MSI or Exys to install stuff. On Mac, you would use a PKG or maybe Homebrew. We'll have a Homebrew available as well. On Linux, you would use AppGet or maybe a raw deb file.

And obviously, you'd probably just be able to get a zip as well. I think we have a build that's just a zip and you just download it and extract it and run it from there. Or you can just curl it down as well. That's pretty common today for SDKs. You just type a little bit of PowerShell or a little bit of Bash in, goes off to a URL, downloads the script, runs it, and then you have the thing installed and it's on your path. So easy to get installed via

what you would normally do on the platform that you're using. So one of the advantages of this over DNx is we now, as I said, have a single application model that represents how do I build and distribute .NET Core stuff, apps and libraries, cross-platform. And this will be the foundation moving forward

for doing those things, while still having some compatibility into the existing world. The important part from the context of what we work on is ASP.NET 5 is gonna re-platform on top of this new .NET CLI in RC2. So that's the big change between RC1 and RC2 and we'll go over what that means to your applications

a little further on in this talk. It's not as scary as it sounds and there are a lot of benefits in doing that. Xproj, so when you open an ASP.NET 5 application in Visual Studio 2015, the underlying project system is called Xproj. Okay, so we all know what a CSproj is or a VBproj, right?

It's the MSBuild based project system for C Sharp and Visual Basic in .NET, in Visual Studio, sorry. Xproj is the one for, it was DNx and now it's going to be for .NET Core. So if you're using .NET Core, the CLI, to build libraries or applications, either console apps or ASP.NET 5 applications,

you will be using Xproj. And so all the nice features that we added to that project system, like the multi-targeting, so you can compile for .NET Core and .NET Framework at the same time, or the nice NuGet package hierarchy, where in the dependency, you see the full hierarchy of packages all the way down,

the project JSON in Telesense, all that type of stuff, it's the same project system. That will now be the project system for .NET Core CLI. Also all the Gulp, you know, all that type of stuff, that's one of the stuff, that actually isn't tied directly to the Xproj system, so that will just continue to work. It actually works in other project systems too. Something else that's coming along in RC2

as part of this work is something we're calling the .NET Platform Standard. Who's ever heard of the concept of a standard library from other platforms? Anyone ever heard of that? Okay, it's pretty common in the native world, as far as I understand. I'm not a native developer, so I hadn't really heard of this before, but you can think of it as, well, I'll tell you what it is.

So it's a new way really to represent the API that is available to you as a .NET developer when you're building cross-platform, okay? When you're building .NET apps that have to work on more than one place, whether it's a Microsoft platform, Windows Phone, or Windows Store, or Xbox, .NET Framework on Windows, .NET Core on Windows, or something that runs on Mono,

or something that runs on .NET Core for Linux, or some new platform that we can't even dream of yet but comes out next year. I don't know, the secret Microsoft Watch or something. I don't know, I'm just gonna make it, oh, the fridge, that's a better example. The fridge. And everything is an internet fridge again. So think of this as your cross-platform BCL, okay? But it doesn't necessarily include

the actual implementations of things. It's more, think of it as a contract. Think of these are the APIs that I'm allowed to call. Yes, Mr. Hanselman? Mm-hmm. So the question was, Scott was doing some Android development recently, and there was a concept of API level,

which I'm assuming was a number. Yeah, and is this kind of like that? Yeah, it is kind of like that. And if you're from the Java world, it's very similar to the concept of Java 1.4, 1.5, 1.6, and then various platforms like Android would support, like Android 2 supports Java 1.3 or something like that. And so this is very, very similar,

except whereas Java, it's not just the API, it's kind of everything else that comes with it. In the .NET world, this is going to represent just the API that you can call. And then the runtime and the host, the XE you call or the Windows phone that boots you up will be somewhat separate to that. It's also the spiritual successor

to portable class libraries. Who's ever built a PCL? Who liked building a PCL? Yeah, all the hands go down. One person. One person liked their PCL. So PCL solved the problem. They've gone through a few generations. Technically, I think we're at the third generation of PCL technology now. And the concept of a PCL is I take my same C-sharp code,

I choose what platforms I want to run on. I want to run on .NET Framework 4.5, I want to run on Silverlight 4, and I want to run on Windows Phone 8. And then that kind of carves everything out into the common set of API that I'm allowed to call. And then when I compile my C-sharp against that API, I get a single DLL, an IL assembly out the other side.

And then that same DLL, the very same file, can be loaded on those three platforms that I chose. The problem we had with PCL was when it got more complicated than just I want those two platforms or those three platforms, it was very difficult to understand what you should choose. And the UI and the tooling that we built for that

was all designed to hide how the system really worked from you. And unfortunately, like most abstractions that attempt to do that, they end up leaking. Like you end up getting to a point where you really need to understand what's happening under the covers to do anything real. And so as a result, websites were built that helped you choose which things

to put in your NuGet package and what to put in your NuSpec in order to have your .NET library work on the most possible platforms. We didn't build that solution, the community did. And that's probably an indication that we didn't do a good enough job of making .NET run. Does anyone here know the actual profile numbers, like by heart, profile seven, profile 126?

One hand, 268, whatever they are. I don't know, I'm just gonna real off on this, 1496. 384, 285. So the .NET platform standard will be somewhat compatible with some of the later PCL profiles. So you'll be able to reference one way, but it is intended essentially to replace the PCL concept.

So when this comes out in our C2, which hopefully will land in about mid to late February, so a month or so from now, we will retroactively version this set of API. So the first day it comes out, you will actually get six versions, I think. It'll start at 1.0 and go all the way through to 1.5.

And I'll show you a table in a minute so you can see what those line up with. The very earliest one represents, 1.0, represents the very earliest system runtime or system.runtime based platform that we had, which was the Windows Phone 8.0 Silverlight apps. So if you target .NET platform standard 1.0,

you choose that from the dropdown, or you put that in your project JSON file, then you'll get just the API that was available to you when you were running .NET apps on Windows Phone 8.1 Silverlight. And then as that version goes higher, more API becomes available. So new versions add API.

Non-breaking changes, we hope, we will try. The whole idea here is that the .NET platform standard versions over time and we add API and expose a wider and wider set of functionality as new platforms come on board that want to do new things. Higher versions equals more API,

which equals runs on fewer platforms. And that might throw you off initially, but think about it. If Windows Phone 8 Silverlight represents 1.0, if I target 1.5, which represents the API that we're releasing in February, how can I run that on Windows Phone Silverlight 8.0

when it can't satisfy that API? Remember, it's just a contract. It's not actually the DLLs themselves all the time. There is more complexity on the covers, as always. It's kind of like JavaScript, how you can, you know, ES7 isn't there yet, ES6 isn't there yet, so you have to transpile from ES6 to ES5. It's the same in the model where if you use newer things that are on all boards as yet,

you have to kind of wait until they all catch up to use the new things that are on everything else. That's a good paradigm measure. So who's ever had to write some JavaScript that checks the browser version or checks for the existence of an API before they call it? Can I use .NET? Anyone done that? Of course you have. If you've ever developed, you have to do that. And so that's how you write JavaScript that runs on older browsers as well as newer browsers.

You use a new API when it's available. You will be able to do a similar thing, although generally in the .NET world that requires you to compile more than once. You'll compile a version of the DLL that works on this set of API a little further ago, and you'll compile another version of the DLL from the same source code using ifdefs

that runs on the newer set of API and perhaps utilizes a new feature or perhaps adds async support or, you know, et cetera, et cetera. OK? The highest one that we'll be releasing I think right now is 1.5. And 1.5 pretty much maps to what we had given you in DNX Core. So if you had written an ASP.NET 5 application, by default,

that ASP.NET 5 application was targeting something called DNX 4.5.1, which represented .NET Framework 4.5.1. And something called DNX Core 5, which was .NET Core 5, OK? What would run on Linux and Mac and Windows. So 1.5 will represent the furthest side of that spectrum, the most API for .NET Core,

which is equivalent to DNX Core. So here's the table. Quick poll. We're talking about back versioning. So we actually start at 0.5 and go to 1. Would that be better, you think, to release at 1 and then back version to 0.5? Or should we start at 1 and then go to 1.5? So this is what it will look like currently, but we could change this. So .NET platform standard is what we're talking about. That's the first row.

And there are the versions that we're talking about. Start at 1.0, if that's what we do, and we release. I dropped off 1.5. Imagine there's another one, right? What you look down is you go, OK, if I target 1.0 and I compile a DLL, that DLL will load and run successfully on every row, every platform,

because there's an arrow in every single one. There's either an arrow or a version number, OK? If there's something in the cell, it means it will run. Whether it's a number or an arrow is how you differentiate between whether it will run because that platform supports a higher version or whether it runs because that's the version that it supports. So if I then go to 1.1, I drop support

for Windows Phone Silverlight. Because 1.1 added new API that, if I call that, will throw platform not support exception or method missing exception or whatever on if I try to run that on Windows Phone Silverlight because those two cells are empty, OK? They're the oldest versions of the platform,

Windows Phone Silverlight 8.1 and 8.0, so they have the least API available. Then we keep going over on the versions of the .NET platform standard, you can see the number of cells with either an arrow or a number in them get less. Because as we add more API, we drop platforms because those platforms can't support that API, OK?

Make sense? So imagine that's a JavaScript version at the top, and these are browsers, right? Same difference, exactly the same thing, all right? So down the bottom, what we used to have is DNxCore 50 will be replaced with a new name that represents just a .NET Core application, right? One that runs everywhere.

One that runs on .NET Core on Linux, Mac, and Windows and anywhere else that .NET Core gets ported to. And that will be called net standard app. That's currently the working title. We'll see what happens in a month, but that's currently what we're going with. And that number will match the number of the .NET platform standard, so we'll have an app model that always matches,

maybe, certainly in the interim, matches the platform standard. So if this looks overwhelming at the beginning, I apologize. The reality is it is actually simpler than how PCLs work, and it is more future proof than how PCLs were. This is open-ended. We term it as open-ended, whereas PCLs were closed.

That means that when you build a PCL, we forced you to pick a platform, right? One or more platforms, and you go File New. It says choose the platforms you want to build for, right? You build it. Then say that you build it, you ship it, and the very next day, Microsoft releases a new platform. The chances of that DLL running on that platform are practically zero, OK?

Because there's no other standard that we can align that to. We built a profile, profile number 247 or whatever, and that's what your DLL lives in. But if the new platform has new API, maybe misses some others, it's going to be a different profile, so your DLL won't load. With this model, we can release a new platform and say, well, this platform maps to platform standard 1.4.

It has all the API required to run 1.4. So as long as your DLL was compiled against net standard 1.4, this platform will happily load it. So it allows us to add new platforms without invalidating all the DLLs that already exist. Who here, when we released WPA, Windows Phone App 8.1,

had to recompile their class libraries, and thus NuGet packages, to get them to load in the new app model? Was anyone here hit by that? No one? One person. One person. That's the easy part. What if your dependency hadn't updated yet? Then you actually couldn't move your library. You couldn't convert your application.

So it's never actually as simple as what I just said, because generally you have dependencies. You have other things that are stopping you moving, because you depend on Damien's great string reversing library or something. And I haven't updated to the new platform, so you can't update to the new platform. Hopefully this will create a system whereby that you aren't limited quite that way. There was a hand over here. Yes.

So the point this gentleman is making is that it seems difficult to understand how a single number could represent such a complex set of API,

especially when you compare it to something like caniuse.com, where you can't just have a single number. Now my answer to that is the difference is in caniuse, there's not one standard that you're trying to adhere to. The web and browser standards are split up. There's many, many, many, many standards. There's not just HTML5 anymore. CSS is even a bunch of modules now.

It's not just CSS3. So while JavaScript itself might have one number, ECMAScript 2016 or whatever they're going to call it this year, that just represents the language. It doesn't represent the API that you call. In the case of .NET, we own the standard. We are the .NET API, Microsoft. We don't have to worry about whether there's

a proprietary one that you won't be able to adhere to. So this one number will represent the API that's available on .NET Core, because we also ship .NET Core. And the Mono people ship Mono, and they can choose which one they align to, just like they do today. Mono chooses when they add new API when we add a new version of .NET framework.

So I think that's probably the answer there, because it's really just representing a single set of API that we control. Very similar to Android. It's just one set of API. We can represent this as a single monotonically increasing version number. That's one question right there. Yeah, what does the asterisk mean? So Mono kind of cheats. Their mantra is that you're supposed

to get the newest Mono every time. So they kind of don't want to have a hard version in there. It's hard for you to target Mono as a specific version. So Mono always works with the latest stuff. So that's kind of why it's in there, because they don't want to not. Mono doesn't want to be tied down. To a version, which kind of sucks sometimes, actually.

OK. Yeah, that's why. So again, this might be, at first glance, this looks a little difficult to understand. There is actually a complete document that explains it, because if you want to read more, generally that helps. And I can show you. So there's this document up on the CoreFX repo that explains this concept, everything I just talked about,

what it's supposed to solve. It goes through a bunch of terms. So what is a TFM? What is platform? What's a reference assembly? What's multi-targeting mean? So that you have a good way, hopefully, of understanding these things. A bunch of principles that we're trying to adhere to when building this. And in a few little more diagrams, there's that table that I just showed you.

And some nice observations, like you do after your scientific theory. You can now say, these statements hold true by the fact of everything that we've just explained to you. And so if you want to learn more about this, and if you build class libraries that run on more than one .NET platform, you will want to learn about this. Then jump up there and look at that.

If you just build ASP.NET 5 applications or ASP.NET applications, and the only class libraries you build are ones that you load into your ASP.NET 5 applications in order to help separate your code, you really don't need to worry about this. As soon as you want to share code between an ASP.NET application and a Windows Phone app, or an ASP.NET application and a UWP app,

then you will need to think about, well, how am I going to build that code? What type of project does it live in? And we are committing to building a much better developer experience, both in the command line via .NET CLI and in Visual Studio, to facilitating that today. So we did something a couple years ago, like the shared project model when we did the original Windows Store apps.

Anyone use that, the shared projects in Visual Studio? Which was an attempt at solving this problem, but we didn't have a standard set of API to link that to. So you still had to choose what your platform's for, and the code was basically duplicated in both places and then rebuilt. The new project system just lets you do all that in one project system.

All right, so if you are using DNx today from the command line in ASP.NET 5, there's a set of commands that you are used to using in your applications. They're on the left here, and this is how they'll map to the new commands at the command line now that we have the .NET core CLI. It's pretty straightforward. In fact, in some ways, it's a little more consistent because you're always going to start with the word .NET.

Remember I said that the style of command line is that .NET is a driver? We call it a driver. It's because you always got to say .NET something, and then .NET drives whatever you put after it. .NET restore actually doesn't do anything itself. It delegates or drives a call to NuGet restore, okay? Similar for .NET pack, it'll call NuGet pack,

and .NET publish will do something. It'll call .NET publish, .NET dash publish, I think. .NET compile eventually calls down to CSC, okay, the C-sharp compiler, or F-sharp, or VB, and so on and so forth. DNx watch was an example of what we called a DNx global tool, and so you would build a DNx app,

and then you would be able to install it using DNU commands add, I think it was. Install, blah, blah, blah. Now we have a new system in .NET for commands like that, or tools, and you'll just be able to add them in your project, you'll see this in a second, and then invoke them via .NET tool name, okay?

And they'll run in the context of your application, which is kind of nice. So if you've used the EF migrations support in a DNx application, you would have typed DNx EF space migration space add at the command line. That would just change to .NET EF, okay? So what actually changes in your projects?

So the first one, which you may have picked up on an RC1, because we did a very late change in RC1 to try and prepare for this, and in retrospect, we shouldn't have done it because we end up having to change it all anyway, but you might have noticed in your RC1 project that there's a static void main method in your startup CS class, okay? Just like you would see in a console app in .NET.

You'd have a program .CS, and inside that's a static void main. ASP.NET 5 applications will be true console applications. They'll just be a normal .NET console app. They're self-hosting, and then you will call an API, the ASP.NET hosting API, to build and start the application,

the ASP.NET part of your application, from your console app, okay? Now, that gives you incredible flexibility. So people have been wanting to self-host ASP.NET for a long time. By definition, ASP.NET 5 is now self-hosted all the time, okay, and you have full control over how it's built. You can configure it in code. You can read from config files. It's all up to you, and obviously, by default,

the template will omit the three or four lines of code required to do that, and we'll see that in just a second. That's what I just said. So our entry point, so where ASP.NET starts is now just an API. It's not Web Engine 4 in IIS, right, or an ISAPI filter, or something in Cassini, or some other XE that you have to call into.

It is just an API call. What does that mean? That means maybe we'll end up running in other places. I've had people ask me, can I host ASP.NET 5 in a Windows Store application? And the answer's always being, well, no, because DNX was its own app model. Like, it had its own XE. You had to call DNX.XE.

But technically, there's nothing preventing an ASP.NET 5 application running on a different platform, assuming that it supports the further, you know, the right-hand-most column there, because ASP.NET 5 itself is just programmed against the net standard library, all right? We are just a library that says, please compile against net standard library,

and any platform that can run net standard library 1.5 will be able to run an ASP.NET 5 app. Does that make sense? Very flexible. So we also get support for NuGet content via NuGet. Oh, yes, Mr. Hanselman. I'm sorry. Yes.

So that's a good question. The question is, why do we have something called net standard and then a separate name for something that represents the app that is targeting the net standard? This comes up all the time. The very short answer is we don't want to paint ourselves into a corner, whereby at some point, we need to add specific API that's really only applicable to the app model but doesn't apply to a library

that runs on a different platform that happens to adhere to the standard, OK? So by separating the app model from the contracts that you can call, we give ourselves that flexibility. In fact, there is already some API in the stack that will only run if you execute it via and compile it via the .net CLI using the new runtime.

But it won't work if you try and stick it in a .net framework application, even though .net framework will support .net standard library 1.4, OK? So we need to have that separation. Something that people were a little upset about in ASP.NET 5 is that we dropped support for NuGet content.

That's the ability to put non-DLLs into your project via NuGet. Well, I'm glad to say we're getting that back. It's a new NuGet content model. It's not the old one. It's a new, improved one that was actually thought out, rather than just sort of added in at the beginning. And that's part of NuGet 3.3, which will come out around the same time, or at the same time, basically,

as this. So that's good. So if you want to add views or content, JavaScript, or whatever it might be, there'll be a way to do that. We also get support for new languages. So we didn't support Visual Basic in ASP.NET 5 or F-sharp. The .NET command line can't say it's only one language. We want to support the full ecosystem of .NET languages.

And so we get that from the beginning. We'll support Visual Basic and F-sharp. Not saying you'll get Visual Studio tooling for all those things straight away, but at least the command line will work. And then we'll assess what tooling we add after that. We get support for incremental compilation. So one of the features, quote unquote, of DNx

was the concept of dynamic compilation. So you just run DNx over a folder full of source code, and it compiles it on the fly and starts your application. That sounds wonderful until you stop the application, because you made a code change, and then you have to start it again. And it just recompiles the entire application again and all of its dependencies.

You don't have this concept of incremental compilation. Just compile what changed. To do that, you really need to put stuff on disk with time stamps and stuff to know what's changed. So we get that back by being a little more traditional, just a standard compile like we were before. CS Proj's will be able to reference Xproj's, which you can't do right now with DNx. We are making that work.

So you can have an Xproj, build a class library with Xproj that targets two or three different platforms, and you can reference that from your Windows phone application or your Windows store application, which is built on CS Proj, and get that library to flow through correctly. The .NET tool chain itself will be .NET Core x64 only.

So when you type .NET, the thing running the .NET tools, not the application, but the tool itself will just be one runtime. Why is that significant? Well, today, DNx includes the tools and the runtime and the libraries in one thing,

which means we have to have a different DNx for each bitness and for each framework type, which is why when you install Visual Studio with DNx, you get four of them by default, x86, x64 for .NET framework, x86, x64 for .NET Core. That all goes away. Also, by compiling to disk by default,

just like normal .NET does, many more .NET tools that are already out there just work. Unlike when we were doing stuff that was magic in memory, they didn't know where to find stuff. There were no PDBs. There was no DLLs on disk. It was very hard for those tools to work. So those things will just work. So let's have a quick look at what a project JSON will look like.

So here we go. On the left is a DNx project JSON. And on the right is what the same project JSON in a .NET Core app, an ASP.NET app, may look like. It may look exactly like this, but there are some key changes in here that are worth highlighting. So up here, for example, we're

trying to clean up some of the options APIs. So you can set your compiler directly in your project JSON. And that will be fed into the .NET driver. So when you say .NET compile, it'll look in your project JSON to see if you've set a compiler. And if you have, it'll then call .NET compile blah, whatever your compiler name is.

So very, very easy extensibility of compilers. You can even pull that compiler in via the new tool section down here. That will make it available to your application. Ability to set some of the CLR settings that we didn't expose to you in DNx. So for example, the .NET runtime will probably default back to workstation GC.

For ASP.NET apps, you would want to use server GC. And because this is just a console app, you'll have to tell us that when you run. So that's in the template. Note that some differences here. Over here, I included some tooling things in my dependencies. Even though I didn't need them when I was running, I only needed them during development. They were in my normal dependency chain in NuGet.

And then we had this concept of commands, which was the ability for the DNx to start my application with a different entry point, one that I'd brought in via NuGet. Okay, which was kind of neat, but it also caused a few problems. So we've got a new design, which is this concept of tools. So I bring in tools via NuGet packages.

So there would be a package called .NET-EF, and it would contain the command line EF tools for the .NET command line. You bring them into your project, just like a NuGet reference, and then you would execute them at the command line with .NET space EF. Okay, simple as that. So now you can very easily bring in tools to use in your application via EF.

And then, yeah, find NuGet. And then lastly, down in the framework section, obviously in DNx, we had DNx 4.5.1 and DNx Core 50. That changes. To run on full framework, you just target full framework, NET 4.6. It's not DNx special, it's just .NET. Okay, .NET 4.6. And when that compiles, you will just get a standard .NET exe.

Normal console application, as if you'd built it with a CS Proj four years ago. And then the new thing, that standard app 1.5, which we talked about before. So what stays the same? Same project format to Project JSON. You have Xproj for Visual Studio, Omnisharp when you're doing non-Visual Studio IDE IntelliSense.

The ASP.NET APIs mostly stay the same. All the stuff that's above startup.cs, that pretty much all stays the same. Your MVC, your middlewares, middlesware, all those things stay the same. Your development workflow, the things that we really tried to work on, where you can just edit and save a CS file, go back over to the browser, hit F5 in the browser, and your controller has already been recompiled

and the app has been restarted. We can still make that stuff work. We will commit to still making all that stuff work. And if you come from the command line, you're using DNx watch, there'll be an equivalent in the .NET world. And we'll still have support for the core CLR and the full CLR. Okay, as you saw in the Project JSON there, I was building for both. And Mono will continue to work, but we don't officially support Mono.

You can't call us, pay us money, and we'll help you, but you can log bugs on GitHub and you can help us fix things. If you find issues, log a bug on Mono or log a bug on us and we'll do our best to fix them. And I have no more slides. All right, let's demo some stuff. Let's demo some stuff. Is it on? Awesome, can anyone see that?

Is it good? All right, so to get the CLI, you're supposed to go to .NET GitHub IO. And this guy has this new thing, getting started. And it will lead you through the steps to get the actual CLI on your machine. So there's Windows, Ubuntu, there's an MSI for Windows,

there's Ubuntu Debian package, so your app get installed. Zoom it in a bit, there we go. Max it. I can do the full screen over here. Yeah, there we go. All right, so app get install .NET, which is kind of nice, right? .NET new to create a project,

and then you do .NET restore, to restore and then you run. Let's try it. So I'm on OS X, I will not install it because I have it built from source already. Fancy pants. Ha, ha, ha. So I'll create a new project. Test two, go to test two. I'll run .NET new, LS,

and I'll get three things, a config file, a program CS and a project using. I'll open VS code. Take a look what it has. Can I zoom in VS code? Yeah, just control plus. Cause it's JavaScript. Cause it's a browser. All right, so I have this thing

called .NET standard library that has some weird version. So that's what we were talking about. That is basically the thing that represents the platform standard. Yep. And that's what you will reference. It will have a sane version number by the time we ship it. So one difference is that in this new model, everything that was a runtime before, no packages. So before in DNx, you had a DNVM,

which had a DNVM list, which showed you your runtimes. These are all gone now and you have more packages. So things like system runtime and those things are all actually just packages in your application. Do you remember when we told you that with DNx, everything is packages? You remember hearing us say that? Kinda. Scott probably said that in a bunch of demos.

We just lied. That wasn't true. It was kinda true. Yeah, thank you. Kinda. A bunch of stuff was actually in your runtimes folder. Okay, hold on. Buried in your... Hold on. You wanna explain this? That we lied and fooled all the people? Of course not. We didn't lie. But it is true now. It is true that everything is actually a package.

So, for example, coreclr, blah. You know how tiny that is? Hold on, hold on. I'm gonna use the Mac somehow and zoom in. Or not. What? You do? I'll leave it. Anyway. This was the runtime. The runtime had a bunch of things like ms-corelib, coreclr itself,

a bunch of native shims, rosalyn, probably too much stuff in here. But some stuff were packages and some stuff were actually coming from DNx. So if you saw errors where you had a mismatch between your packages and your DNx versions, it was because of this behavior. And it's gone now, so yay. Now the runtime is not in a secret folder on your hard drive.

It's just a package that you happen to bring in via your graph. Right, so I run .net restore. And if I didn't have it already, it would actually restore the internet. So if you look at my lock file, literally everything now is a package. So what it means is this is probably, let's take a look, I don't know.

There is no dnvm. The question was what's the dnvm list equivalent? There isn't one. Because you don't need one in this world. The dnvm list was there and dnvm itself was there to let you switch between DNx's because DNx was a monolith. DNx gave you the runtime, it gave you the tools, and it gave you the libraries, some of them anyway.

There's the tool chain itself? That's separate, yes. The concept of a global package cache will have to be packages folder where it installs to. That still remains. Packages are still something that we can put in a packages folder so you don't have

to restore them again, obviously. I'd like to ask the question. How many? Do I have to scan the disk? So it would be, you would look at the package. What is .net? It is .net, right? There would be in the packages. It's just packages. Maybe. This is still being debated. So the question is, so .net itself,

does it have a runtime? Is this a tool chain? So it's like you have CSC and the compiler but you don't actually have the runtime for your application. The runtime for .net list, just to ask that question. That only makes sense if you have a runtime. That's not the same as the application. The runtime is in the application, like truly this time. It wasn't before, really. So what it means is like,

if you dive into this file, you'll see things like system dot runtime. It was always a big file, a lock file. It's bigger. But Linux. More stuff. .ofx, yep. There it is. There's the runtime. This is the core CLR itself. This is the actual CLR as a package. That's a package ID, by the way. So that's actually the package.

So if you wanted to find them, you would look for packages in your packages folder that start with runtime dot. I'm not sure how I feel about this. That is a fantastic question. What runs the runtime? Because the runtime can't run itself. Someone has to boot it, right? Let's segue into that. So next step is to run dot net. Previously it was DNX.exe.

DNX.exe was native code. It booted the runtime. There's a new one. .net run and magic happens. Yeah? So it works. Just looks like, what did we run before? DNX. You'd have to run DNU build. Before it was DNX run. DNX run. Kind of the same.

I can also do .net build. No, I can't. Then debug DNX core test two. I can run it. So this is actually unexcutable. That's native to the operating system. So if I open this in finder.

No, it wasn't. No, so let me clarify that. If you've never used a non-Windows machine in your life, they don't end in exe on Mac, right? That is an exe. It's just that on a Mac, it doesn't have to end in exe. It's marked as executable. So when he built it, what was produced was something he could execute.

There's no DNX.exe. It's in his bin folder. Just like .net console app from before. Except it's not quite like a .net console app from before because in those days, Windows had the runtime, right? It was scrolled away in slash Windows, slash Microsoft framework, slash blah, blah, blah, right? So how does this work? What did it do? I'll slide a hand here. We take a DNX executable that's pre-compiled already for each OS and then on compile,

we copy it and rename it to your project. So test2-dll is your application and test2 is a stub that is just gonna say, my name is test2, I'm gonna boot test2-dll and then run it. So it's kind of cheating to make- Somewhere else on the hard drive, in the .net tools or in the runtime package, I guess.

There is a .net core host.exe and then it copies it over here, renames it to your project name and it looks like it's your exe. It's not. If I rename this to test1. It's enough to keep you happy, right? You don't have to have to be happy. And I ran this, it'll explode horribly. That's not native.

That is not native. No, that exe is native. But your DLL next to it is IL. It's not yet native. Correct. It is not yet fully native. I'm just, because he said the word native. He meant native to this platform. Like the bootstrapper is native to this platform. Not the app. No, no, no, that's not native. Yeah. Does that make sense? Yeah? It's an electron basically.

Yeah, sure. Sure. Electron dot exe. Yeah, there you go. Yep. Yeah, we're not the only ones to do this. We didn't invent this. This is a common trick. I'll name it back to test2. And there's this depth file here that's gonna change in like...

This week. This week. But I'll show it anyway because it's fun to look at. Depth file has all your dependencies. We didn't copy your dependencies to your bin folder because that is too much to copy. So we just list all the dependencies there for the runtime to read. So when you boot the runtime, it reads this file and it tries to find the packages in the package folder.

Does that make sense? So that native exe, it reads this file which is just a list of like DLLs, right? Basically all it is. And it says, okay, I need to load these when I boot dot net and tell dot net this is where they are. Because this is not like dot net on Windows. There's no GAC. There's no probing paths. There's no fusion loader with all this logic like this.

This is how it works. It's a very, very thin host that you have to tell it where all the assemblies are. And so this is the list of assemblies. The name and the format of this file will change this week. Because you have to put it somewhere. Copying all the dependencies every time is. So you could embed it as a resource. I think that's a great idea.

That I would love them to do that. That came up. It's build output. Do you ever go into your bin folder and like fiddle with the stuff and then expect it to work? You do? But you know what you're doing when you do that, don't you? That's not a problem then. Well, I think you could look in the, I mean, I get what you're saying. You could show it afterwards.

You could look in the bin folder of many a .NET application from the past 15 years and you probably wouldn't feel sanitary. Yeah, it's not intended for human consumption generally. Maybe, yeah. Yeah, I mean, the counter argument to that

is every new platform comes with new stuff to learn and you shouldn't just go in there assuming that you can delete a file because you've never heard of it before. But sure. But you're Mr. Hansen so that's what you do, right? What's this process, Kel? Absolutely. Absolutely, so as usual, we are having this debate. Like that obviously has come up.

I would love to see it embedded as a resource. No. But he doesn't want to, so. It complicates the concept. It's gross. Now, it doesn't mean that we won't do that in the future. Yeah. It is. Well, how cool that gives you power. It's gonna be less random though in the future. You don't need to change it. You might. Maybe. We'll see.

Almost. Closer. Never. You should never change it. We're gonna put different things in there so the current plan is to actually transform the project file, these two files, into a shared file. This is the point when the talk went off track. It'll be, it'll be. I can feel it in the audience. It's gonna be a revolt. Let me show one more thing, I guess, before we ramble some more.

You can. Yeah. I mean, that's how anything works, right? Actually, it's not, well, not really, because if you are, okay, if you are a virus writer and you have gotten the ability to drop a file next to another file, it's game over already, my friend. Like, it's already game over.

Research that I can sha-hash the. I totally get it. Totally get it. It just, every time you say it could be a thing, at the moment, this has been chosen for, above all else, simplicity. Yeah. This is the quickest thing that we can get that works and is easy to write from native code. Okay, it works cross-platform really well. As soon as you say we have to make it an embedded resource with a sha and it's zipped

and blah, blah, blah, we have to think about how to do that on three platforms. Yeah. Right? That's the kind of problem. It's embedded. So it doesn't mean we won't do it eventually. This might clean up in version 1.1 or 1.2, but right now this is what it is. Or never, who knows? That is a great question. Why is this different to the lock file? The new format will be the lock file format plus some stuff from here in a different file format.

Jason? Yeah, Jason. The reason it wasn't until now is because no one wanted to parse Jason from native code. Kind of. That's why. Right? Because we wanted that host that we copy into your project to be as simple as possible. We wanted that to be the purest concealer host it can possibly be. All right?

XML? Jason's a new INI file. It is. It's the new INI file. We can make it an INI file if you like. We can call it an INI as an old person. As an old person, you feel better? Well, it is open source. Don't send a pull request. Don't send a pull request, we'll just, yeah. We'll close it. You can fork it. Dot net INI by Scott.

There's a new command. The core RT stuff, I'll just show it quickly. Dot net compile dash dash native. And it compiles, then it compiles again. I said it compiles harder, right? Compiles harder. Yeah. And it did something, and it complained, and I'll ignore it.

Debug, the next core, native, and I'll open this folder before I run this application. Look, one thing, Scott. Does that make you happy? I know it embeds nothing. I mean, it's just one thing. It's just machine code now. Depth file. Is that good? You like that? Good. Would you erase this? Scott is happy, everybody. That's great. Native code. I can run it, and it's super fast.

Oh my gosh. Is that, is it faster than this? You know what? It's that depth file. It's a depth file. That's what it is. I know it. Oh, it is fast. Look at that. So fast. But it only works for hello world. He's not even joking.

Like, right now you can't use interfaces. I don't think you can throw exceptions and catch them right now. No. Someone did a console with a number, and it threw an exception. So they're working on it. This is in very, very early days. Like half a year, maybe, then it'll be good. You want to explain how this thing works? How native works?

So first it goes from C Sharp to IL via CFC, and then it goes from IL, and there's two ways. There's from using the jitter as a pre-compiler to go from IL to native code, and there's a way to go from IL to C++ to native code. And if I did, done it, compiled native. It literally takes IL and generates a C++ file source code.

Yeah. And then it compiles it again using the C++ compiler. This one. It's compiled harder. It is, it's all right, so. Wow. And you wait like. It's transpiling across C Sharp to IL to C++ to whatever C++ compiler. Does that work? Native code.

Is there a file? Can we see the C++ file? Is that possible? I don't think so. Did it work, or did it crash? Mm, you can see it launch everything, yeah. So go back to the folder. Oh, I mean, it's one file, right? So what's in that file, right? So what's in your file? How big is it?

How big is that file? Oh. Did we show how big it was? Any guesses? 600K. How big is the hello world native .NET app? Price is right. I tried to hide it on my screen. About one meg, is that right? I tried hiding it. That didn't work at all. Is it one meg? Yes, guess the size. All right, so. You can't see it, right? It's too small to see.

So that one meg includes core RT. Remember core RT from the beginning of the deck, right? It's the native runtime. It includes everything in core FX that you called. Core FX, sorry. All right, so everything in core FX that you called, right? Pretty much everything that was in your deps file. Deps file's even. But only the methods, not just the assemblies, but only the methods that you called, right?

It's a proper static linker, right? With tree shaking and all this complicated computer science stuff that I don't understand. There's no tree shaking yet? Nope. Okay, pull that back. Just the other thing that I don't understand. Fun fact. And then it's your code. Then it's the call to hello world. So the overhead is probably 99% for this case because he's just calling hello world.

But you'll never pay that overhead again, right? As the app gets bigger, it's still just. Then you can't. So a lot of things don't work. As we said, only hello world works right now. But in theory. Interface dispatch support. In theory, anything is possible. We can make anything work. It's just gonna take a lot of time and a lot of very smart developers. So fun fact. Yes.

So the question is, is this different to what Xamarin is doing with their LLVM? So .NET has a thing like that too called Lilac, which is a tool chain for .NET native that goes to LLVM. From Lilac to the star.

And the plan is that will also be an option. So if you already have an existing native tool chain or you wanna utilize the ecosystem of native stuff in LLVM, then you'll be able to say dash dash native dash dash Lilac or something, and it'll do it that way, okay?

Yeah. Dash dash native dash LLVM. Go one time. Why do I need three choices? Cause people like choice. I mean the question from Scott is why do we have three different ways? Native, I don't come from a native background, but from what I've been told by people at Microsoft who were doing this

is that it's a completely different world in the native tool chain world. We just kind of assumed like .NET, you just use a thing and you use what you get given. But apparently in the native world and C++, it's like the wild west. It's just stuff everywhere. And people use what makes them happy. There's new stuff every week, a bit like JavaScript really. And people like that choice, okay? And so some of these were academic exercises,

I think it's fair to say, which of now that we've actually got a product plan to do something native, we're still figuring out what will be in there. We're not promising CPP will be there in the first version, maybe it won't. Maybe it'll be a prototype you pull in as a separate tool. I'm not quite sure. But obviously the one that will work will be the one that goes from C sharp to IL through the Reu JIT into assembly.

And the other ones, and the lilac one, I think is a definite one as well because so many people use LLVM. What's that? It is more blessed right now. Yeah, the CPP one's kind of the poor cousin right now. Yeah, that's some dude's side project that he just threw in there. So the Reu JIT one is the main one.

So fun fact, the core RT, the runtime for native compilation is actually built in managed code. Did you hear that? You didn't tell them the other part though. I know. Just tell them the other part first. I'm holding it. And core CLR, the managed runtime is built in native code. So it's kind of reversed. So core CLR itself, like if you look for a thing like string,

I guess decimal's better. Decimal's actually in C++. See that? And it has like assembly because it's not fast enough in just pure C++. Where's the assembly? For a number. There it is, look at that. Yeah. That does what? That's a mod, mod operation?

It's decimal div mod. I think I saw add in there and it was done as assembly as well or something. Multiply by 10. That's small 10. Nice. Add in 32, there you go. The runtime for native, the native stack is actually built in managed code. That's because they actually use it

to compile to native code at compile time. There's no need to have that. So core IT, which is the native runtime is written in C sharp. Whereas core CLR, which is the managed runtime is written in C++ and assembly. That's kind of odd. Awesome. Well, at least they're dog fooding the new stuff. Yeah. We're building it with itself, which is good. It's always a good sign.

All right, let's look at one more thing. So transparency. It also means that it's easier to hire new developers because more people, it's easier to get C sharp developers. Although the type of C sharp that's in there, I mean, you still need to know what you're doing. It's pretty aggressive, yeah. So .NET-v will actually show me everything that .NET runs. Aggressive C sharp. Aggressive C sharp.

Angry, angry C sharp. Angry C sharp. If I hit this, you'll see everything that gets run as part .NET compile. You can actually go through the processes that, whoa, that was fast-ish. Something must have gone wrong. Did that work? So it ran. So okay, so first .NET blah runs .NET.

.NET-blah, the command. And we set it to driver. It's just magic. We just say .NET space thing. We go, okay, let's find something called .NET-thing. That's all it is. Could be on the path, could be anywhere. Could be anywhere. .NET build with giant arguments runs .NET-compile, which runs .NET-compile CSC,

which runs CSC, which runs the executable. So if you get into problems, you actually see what actually ran as part of the steps of the entire process. So check it out, the process ID there. Was that the host? The host. Well, dash v does it. But what actually did the printing of the, like who knows the process ID? The thing that called it?

Yep. So if I go into the bin folder, well, op folder and search for native compile CSC, you'll see the command arguments passing to CSC. And you'll see assembly info that got created. Who's ever called CSC directly? Couple of hands, okay. So that's a response file.

All right, that's how you do it when you have so many arguments, you can't fit them on a command line. Which technically is what we're doing here, right? You have to put it in a file. So what happens is you call it .NET compile and it creates this response file for going from the lock file basically into some intermediate format. And then it goes into the compile specific actual command arguments for C sharp, F sharp, BB,

whatever, and then it compiles that. So to finish, do you have an ASP.NET 5 app? I do. That we can run with .NET to prove that even right now, one month before we have to give it to everybody, it works in some shape or form. Kind of. Good. If you do the right dance. If you do the right dance, it works right now.

Let's open this one in VS code. Does everyone use VS code? VS code, anyone? Yeah. Yeah, awesome. Who uses it on a platform other than Windows? Wow, that's fantastic. Really, really fun. Like in anger? Or just like? Like for fun? To show your friends. Just what you do every day. To show your friends. To show your friends.

Yeah, it's a blame. So this is hello world ASP.NET 5. Here's a program in. It has some stuff. Hard quotes, the server cast rules, some stuff here, configuration. Oh, that's the change, by the way. This is the big change. In RC2, you'll see this in your projects. This is how you boot ASP.NET 5 with this nice, fluent web host configuration API. And then you call run, and your app runs.

ones, okay? I love that there's a main, too. I know. I agree. I love that there's a main as well. I think you're still on the fence. I think you like it. I like it sometimes. I love it. It's great. All right. Let's run it. Let's prove it to close out. So

fast. And it's in production. It feels faster if I watch things go by. That's true. Could we add a percent starting your app? 43. 52. 52. 52. Yes! It's running. There we go. So we'll finish with .NET Core CLI running an ASP.NET 5 application. If you know as much

as Fowler, you can make this work today on your own apps. Otherwise, just wait a month. I have a thing. I have a repository. You have a repository of samples, right? Don't And we'll see you next time.