.NET Core Goes RC2

Earlier this week Microsoft delivered the second second release candidate of .NET Core, .NET Core RC2. As with most bleeding edge software, there's a lot changing and much to learn. I sat down with Jeff Fritz from Microsoft and talked to him about what's in the new release. A summary of that discussion is provided below and you can catch the full audio of the discussion on the Eat Sleep Code podcast.

.NET Everywhere

Microsoft is continuing down the path of putting .NET everywhere. This is a massive undertaking considering the targeted landscape. We're talking .NET and C# deployable on literally every form of computing - IoT, Phone using Xamarin, the Cloud via Docker, and even Virtual/Augmented reality with Unity.

Not only is .NET deploying everywhere, it's being written everywhere too. This release marks a continued effort to improve tooling across Windows, Mac, and Linux. Microsoft is actively listening to the community and delivering tools for all sorts of developers. Whether you prefer the highly integrated experience of Visual Studio, the "hipster" feel of Yeoman, or just a bare minimum command line tool, there's support for you.

CLI Changes

If you prefer to develop with the command line, you can download the .NET Core SDK. .NET Core introduced the Dot Net Execution Enviroment or DNX. This experience has been simplified and the DNX command line tool has been replaced with the new dotnet.exe.

Once you have the new SDK installed, you can start a new .NET application by simply opening a command prompt, running dotnet new and beginning to build right away.

You can see more about how to use the new CLI by visiting the project on Github or you can even improve the project by forking and submitting a pull request.

For a deeper look at CLI tools and the .NET CLI, check out our whitepaper, The Command Line: Reinvented for Modern Developers, which celebrates the resurgence of CLI tools and provides insight into how modern development platforms cater to application development through CLI—for web, desktop and mobile channels.

Project structure changes

There has been discussion of project.json and .xproj configuration files being replaced by the classic csproj file. This is something that is happening in RC2, in fact, project.json and .xproj will continue to exist into the full 1.0 release. It is under consideration to change it back to csproj after the 1.0 release (i.e. the next beta cycle). Rolling back to csproj files will be an initiative to bring better support for MSBuild, the classic build system used for .NET applications.

Addressing concerns

While returning to csproj might initially feel like it will leave Mac/Linux devs in the cold, it's actually not going to be an issue. Because of Microsofts acquisition of Xamarin, a version of MSBuild is available for all platforms.

Tooling for csproj will also improve in future versions to support users outside of Visual Studio to empower CLI users when working with project initialization and configuration. The overall interaction with the csproj file will be minimal and Microsoft intends on developers being focused on code, not on boilerplates and configuration. This should come as a breath of fresh air considering the fatigue of the JavaScript landscape today.

TagHelpers

In ASP.NET Core, TagHelpers continue to evolve as a new and better way of writing server generated HTML. TagHelpers offer an HTML-like syntax for writing components that has less visual friction and a smoother API experience when adding attributes to HTML tags. Through TagHelpers front-end developers will have an easier time working with views and coordinating with designers.

Telerik has released a small collection of TagHelpers that include window, button, date picker and time picker components. You can see full demos of TagHelpers in action in the latest Telerik DevCraft release webinar. You can also try them for yourself by starting a free trial of Telerik DevCraft.

Get RC2

You can grab the latest release for .NET Core and ASP.NET Core from get.asp.net website or the new dot.net. Extensive documentation can be found at docs.asp.net.

Listen to the podcast

Jeff Fritz @csharpfritz

Web Developer, Blogger, and Program Manager at Microsoft on #Asp.Net team. Gluten-Free geek and csharpfritz#1506 on http://Battle.Net

• Jeff Fritz's Blog
• MSDN Web Development Blog
• Fritz's 10 Minute Tips

Sam Basu

Samidip Basu (@samidip) is a technologist, Apress/Pluralsight author, speaker, Microsoft MVP, believer in software craftsmanship, gadget-lover and Developer Advocate for Telerik.

With a long developer background, he now spends much of my time advocating modern web/mobile/cloud development platforms on Microsoft/Telerik stacks. His spare times call for travel and culinary adventures with the wife. Find out more at http://samidipbasu.com.

Additional Resources

• The Command Line: Reinvented for Modern Developers (whitepaper)
• How to Web with ASP.NET
• The .NET of Tomorrow
• What Has Microsoft Done For You Lately?

Podcast Transcript

0:00:00 Ed Charbeneau: This podcast is part of the Telerik Developer Network. Telerik, a progress company.

[music]

0:00:11 EC: Hello, and welcome to Eat Sleep Code, the official Telerik podcast. I'm your host, Ed Charbeneau, and with me today is Sam Basu and Jeff Fritz. Morning guys. It's Friday the 13th, how you doing?

0:00:24 Sam Basu: Morning.

0:00:25 Jeffrey Fritz: I'm terrified. What's gonna go wrong today? Look out.

[laughter]

0:00:31 EC: Now, I've got Sam here from Telerik. Sam, why don't you give yourself a brief introduction for folks, let everybody know what you do?

0:00:40 SB: Sure thing. So just like Ed, I'm a developer advocate with Telerik. Advocates are evangelists, we really don't do anything, we just talk about stuff and try to shy away from the really hard stuff. No, I'm just kidding. We try to stay on top of technology and especially on the Microsoft stacks, so I think it's great to have Jeff on with us today, I think we've got some big changes coming and it's exciting. So that's me.

0:01:06 EC: And Jeff Fritz, you're working with Microsoft now, why don't you give everybody a quick intro as well.

0:01:12 JF: Yeah, hey there. I'm Jeff Fritz, I do work for Microsoft, I'm part of the ASP dot NET Developer Outreach Team. It's our job to put together some of the content, manage some of the social interactions, the blog posts, the videos that you're gonna see and use to learn more about ASP dot NET core dot NET Core. And I also manage the ASP dot NET web forums team. So I do a little bit of everything there for Microsoft.

0:01:41 EC: It sounds like you're a really busy guy over at Microsoft these days especially with all of the new things happening with ASP dot NET and dot NET Core, so we wanted to have you on the show today to talk about those huge changes and the big release coming up. So why don't we go ahead and start things off with just an overview, I guess, of what's happening in dot NET land.

0:02:07 JF: So, we're moving forward, we're moving into an interesting period here as we get closer to summer 2016, where we're gonna start to really deliver on this vision, this strategy of dot NET for any device, from 64K to 64GB. It's an interesting approach where we're gonna be able to have dot NET Core running on any device, whether it's IoT, your laptop, your phone, using... It'll be Xamarin in that case on your phone, or UWP if you have a Windows phone. And then when we get out to the Cloud, you can use ASP dot NET Core on Docker, deploy that to any of those cloud solutions where you can manage lots and lots of containers or VMs, however you want or need to. So, it's really exciting for us to be at this point where we're delivering on this tremendous, tremendous set of capabilities where you're gonna be able to take C# and run it on any device.

0:03:16 JF: Now part of that is the ASP dot NET RC2 release that we're seeing this week that delivers a significant set of changes from the RC1. That really focus around re-platforming around the dot NET command line interface. That dot NET Core command line interface really starts to get us in line with the rest of the dot NET ecosystem. So we have portability across all of our dot NETs so that you can use, in the future, when everybody gets up, gets in line with these, we'll be able to use the same dot NET command line interface to compile all of your dot NET projects. But for now, we're gonna have support for ASP dot NET Core coming out of the box.

0:04:00 EC: This is a big shift for folks too, because, mostly ASP dot NET or dot NET in general has been associated with Visual Studio for a long time, and developers kind of feel like you have to have Visual Studio to use anything dot NET. And the new cross-platform approach with using the command line interface and stuff really opens things up to developers outside of that ecosystem.

0:04:29 JF: You're right, Ed. The approach... One of the tenets that the team had right from the get go was, "You know what, we wanna make sure that everybody can get access to this, they can be productive with dot NET, and we don't wanna make Visual Studio a requirement to get in and get running." So you saw us invest in Visual Studio Code, a text editor that allows you to edit code, gets some IntelliSense built into that, some refactoring. We've also added a debugger into Visual Studio Code and we've also made investments in a project called OmniSharp that allows you to get IntelliSense into other editors that people prefer, like Sublime, Vim, Brackets.

0:05:13 JF: So we're trying to bring dot NET to where developers are, and by using the command line interface, we're also allowing you to execute all of those commands that you would have executed in Visual Studio, natively, right there on the command line, whether you're on Linux, Mac, or Windows. But of course if you want that highly productive interaction with your code, to manage and drive with advanced tools, you're gonna get that best experience with Visual Studio on Windows.

0:05:42 EC: Yeah, so I think that sets some folks at ease, like Visual Studio is not going away. [chuckle] The deep, hand-holding, or warm, seat warmer analogy that I've used before, like it's Visual Studio's that Cadillac of IDEs, where you have the built-in seat warmers, and the nice stitched leather dashboard, that's not going away at all.

0:06:05 JF: No, no it certainly is not. And that's part of the challenge that we've had in preparing ASP dot NET Core and dot NET Core is pulling together all of those tools in Visual Studio, that really are the top of the pyramid for the development stack. It takes a long time to build that last piece, but meanwhile, all the run times and the libraries that you need to run ASP dot NET Core, on those various operating systems, in these different modes, you can get to, you can use. So we're splitting that delivery up a little bit. We're gonna deliver the run times in a Release Candidate 2 now, along with all the framework things. These are the things that you're gonna deploy to your bin folder when you compile your project. All of those things are RC2 now, but the top of that stack where you have the Visual Studio tools, you have the final capabilities of the command line interface, these things are gonna take a little bit longer.

0:07:10 JF: We've re-branded those as "preview one", and in doing so, we've bought ourselves a little bit of time here to make sure we get it right, get the integration between not just ASP dot NET and dot NET Core, but other projects that you're gonna have in your dot NET ecosystem. Make sure all of that works as one cohesive unit, so that you can bring other things that you've already invested in, into the ASP dot NET Core project system. When we do get there, when we do finish that tooling story, not only are you going to be able to do the integration between class libraries that you've already built with custom business logic, you're gonna be able to share them across all of your different environments. IOT, phone, desktop, UWP, ASP dot NET, but you're gonna get that tremendous experience that you get in Visual Studio with Roslyn Analyzers, the high-end debugger and IntelliSense, and IntelliTrace. All of these things are going to work when we finish the tooling release for Visual Studio.

0:08:18 SB: So Jeff, this is great. Maybe I wanna talk a little bit more about dot NET in particular before we get into the ASP dot NET stuff. I know Scott Hunter and everybody else likes talking about this, where it's really is the promise of dot NET everywhere. I mean, C# and dot NET lets you target really any platform on any device that you want to target. So, it really is a good story for dot NET developers, but let's dig in a little bit into what's happening with dot NET. So, now we have different VCLs that power dot NET on different platforms. We obviously have the dot NET framework, then we have dot NET Core, then we have Mono, then we have Unity, so all of these ports of dot NET to other platforms are also there. So, what exactly is dot NET Core? Can you break that down for us?

0:09:04 JF: So, if we really look at dot NET Core, what we're trying to do is really... It's almost a throwback to where we were 15 years ago when this whole thing started. When dot NET first came out there was one Base Class Library and it ran on Windows, and you ran the same library for Windows forms, for web services, web applications, that was it, you really had only three or four types of projects. Class libraries, I think, were the other things you had in there. So where dot NET Core comes in, is that we're gonna start to pull together this very simple but common framework that we're gonna be able to use that's portable across different environments.

0:09:58 JF: We intend to make this available to use in other environments, but for right now we're only developing and working with it on the server. And you're right, Sam, we have four, five different versions of VCLs and frameworks and run times out there that all call themselves dot NET, but it's a pain in the neck to get portability across them. We've attempted to solve that problem in the past with portable class libraries. So you write these libraries that when you start a new project, you get this set of checkboxes. "Where do you wanna deploy this to?" "I wanna put it on a web server. I wanna put it on a phone. I wanna put it in a Windows store app."

0:10:44 SB: And the more checkboxes you check, the lesser and lesser it your API canvas becomes and I think what dot NET standard does is kinda solve that problem. So we'll get to that in a little bit. Would it be fair if I say dot NET Core today, the cross-platform story is essentially CoreFX, CoreCLR, and CLI that runs everywhere. Does that sound fair?

0:11:04 JF: Yeah. Sure.

0:11:06 SB: Okay. And it's really much more of a modular, leaner dot NET. You don't have all of the things that dot NET Framework 4.6 has today, but just the pieces that you need to build your applications and, for now, it's console in ASP dot NET but other things, as other things get on board, you'll see that kind of expanding a little bit more.

0:11:25 JF: Right. The strategy and the direction for dot NET Core is still a little but up in the air, but certainly the cross-platform story is there, the server side story, the tooling around the command line interface, and this modular opt-in approach where you only choose the features that you need to bring along with your dot NET Core application. It also speaks towards this ability for the framework to be able to grow, to expand. So when there are features that we say, "You know what? We had this in dot NET framework, and the full desktop dot NET framework on Windows." We can bring those in as additional features to dot NET Core later on in the process.

0:12:14 SB: Right, so...

0:12:15 JF: Because of this opt-in nature.

0:12:17 SB: Sure. So you mentioned CLS. So let's kind of jump into that from a dot NET standpoint, and then we'll go into ASP dot NET. So I know we started, kind of, with the K days, remember KRE and those days? And then we switched to DNX and DNU, and now we're kind of back to dot NET, which I think is kind of the core of what you guys wanted to do in the first place. So I'm glad to see this change. So dot NET is now a CLI. Just the tools, just the basic tools, are new CLI and thanks to JavaScript and the hipster folks, CLI and command line is cool again. It's back to the '80s, and like, we're doing ASCII art, and things like that. But it's actually a lot of power, right, in your command line. So the new dot NET comes with a list of CLI tools that are crossed platform and works everywhere. So things like dot NET, and then, you have all of these verbs like, "Do a new, do a restore, do a build, test, run, publish." And so on. And these work right now on any platform, really. Correct?

0:13:15 JF: Yes. They work on MAC OS 10, they work on Linux. We have it working very well on a new Ubuntu install. It also works on a Red Hat install. And, of course, we have it working on Windows.

0:13:30 SB: And I was actually doing this yesterday. It's really nice on a fresh machine, where you can just get dot NET from the installers. You can do scripts, or you can just get it just basic dot NET. For ASP dot NET you can do get ASP dot NET, but for just pure dot NET, you can just get the dot NET CLI, and the runtime. And then when you do a dot NET new it actually puts a little project, where ever your folder is and it just essentially adds three things. There is a NuGet Config, so you have your dependencies. There's a plain program.CS, which just is a "hello word", if you're doing a C# app. And then there's a project.JSON, which has, again, the listing of all of your dependencies. And the NuGet Config is really where your get your dependencies from. And then, when you do a dot NET restore, it really goes through the JSON file, looks at all of your dependencies, and the source of your NuGet Config, and pulls everything down.

0:14:21 JF: Yeah, that's right.

0:14:24 SB: Now, when I do that, actually, one of the dependencies that it lists out is the dot NET Standard Library. And right now, I think it's 1.0.0, and then RC2. And then NuGet goes out and gets about close to 100 or so packages that I think make up the whole dot NET Core, or the standard library that's been referenced. So do you know what else is being pulled down? What all makes up a project that it's ready for dot NET to kind of bootstrap and run your application?

0:14:53 JF: So when you talk about that dot NET Standard Library. And right now we're talking about the 1.0 version, that's the version that has the least number of features, because it's most compatible with all of the dot NET platforms. Whether that's dot NET Core, the dot NET desktop framework, UWP, Windows Phone, Mono, right? This has the least number of features and it's really grabbing and pulling in the baseline things that would have been your base class library on top of Windows. But we're gonna make it available, appropriately, with those shims so that it'll work on Mac and Linux, as well. So once you download those, the NuGet process actually caches them locally. Very much like your BCL is when you install a new version of Windows or Visual Studio, you get a new version of the dot NET framework, and it stashes all of those BCL libraries, your DLLs, somewhere on disk and you don't even think about them.

0:15:58 SB: Yeah, it's a NuGet folder. And it's actually really nice. Like, the next times you run dot NET Restore, it just takes no time at all, 'cause it already has the bits.

0:16:06 JF: Exactly. And instead of in the old way with NuGet using packages config in your other project types, with this model, all we do is put down a pointer to where that DLL of that package is sitting on disk. So nothing needs to be moved around, you don't end up, like I did, with 50 copies of Microsft.ASP.Net.NupKeg sitting on disk. That's ridiculous. We're gonna have one copy for each version that you need, or you might reference in a central location.

0:16:40 EC: So when we talk about the dot NET Standard Library, let's clarify things for folks. Is the dot NET Standard Library... It's not an actual DLL itself, right? It is a meta-package or an index to all of the things that satisfy what is considered the dot NET Standard Library.

0:17:03 JF: You're right. It is a meta-package. We were using the term "line-up" internally for a while, where it's a list of, "Here's the other compatible packages that all work together for this version." So it really is just a pointer to, "Here's all the versions that meet this standard, the same standard." So you're gonna grab that and put it down locally and then, when you need other versions, because you wanna use more features, or you have a more focused application that's only using dot NET Core and it's not using Windows Phone, then you can move to a more focused version of the platform standard, like Version 1.3, 1.4, 1.5, and you'll get additional packages that come in as part of that, and you'll be able to do more things.

0:17:58 SB: So, Jeff, could we look at the dot NET Standard as sort of like a API contract so it can move independent of dot NET itself and dot NET core itself?

0:18:08 JF: Yeah. Yeah, I think that's fair. It's an API contract that really says, "You know what? If you want to implement, if you wanna be part of a version of dot NET... " So another software vendor says, "We're going to make our own version of dot NET that works on, I don't know, jewelry." "Then that version needs to implement this minimum set of APIs in order to meet dot NET standard 1. And if you wanna advance and be part of dot NET standard 1.1, these additional APIs must be met." Etcetera, etcetera. So, it really does give you that confidence that when you are programming against a certain version of dot NET, a certain standard version of dot NET, that you have the same features across all of those frameworks that implement it.

0:19:02 JF: So, no longer do you have to say, "Uh, I'm working on a Windows phone so I don't have access to these things in system.drawing. But I am working on the web server so I don't have access to these things in Silverlight." These are things that you used to have to balance but now they've fallen by the wayside and you're able to focus on one set of APIs.

0:19:26 SB: I like the promise of this one. So essentially what this means is once this is widely adopted and, I mean, if I am writing a Xamarin app and I do not have device specific dependencies I can bring over my library as-is as long as it's following a certain standard to my ASP dot NET app and just fuse it.

0:19:44 JF: That's right. You don't have to worry about writing any of those goofy portable class library references. You can just implement the dot NET standard appropriately inside of your business class library, inside of your component, and it should be able to referenced by those other applications.

0:20:05 EC: So, let's jump over to ASP dot NET Core a little bit. When this new release comes out there's some changes to the structure of an application. So, we have project.json. What's happening with that?

0:20:20 JF: So initially what you're gonna see is that project.json has some additional fields and features to include and give you this references to the frameworks, to the dot NET standard version that you're going to be using. And these appear in those same areas that we were using for dependencies and frameworks. They changed just a little bit to support this direction that we're heading in. And this is the RC2 version of the ASP dot NET runtime and libraries. There's an RTM that's scheduled to happen in June and at that time nothing's gonna change between project.json between now and then. That project file that you use, you can use a text editor to manage your project's references, it's gonna stay exactly the same.

0:21:06 JF: However, the xproj file that you use with Visual Studio to manage your interactions and your capabilities for your project is gonna be renamed to... Csproj, because it's a C# project and at that point MSBuild is gonna start to come into play a little bit more here. In order for us to achieve that cross project model reference that we want to be able to deliver with Xamarin, with the desktop frameworks, with all these other libraries that you may already have written out there that you want to use with ASP dot NET. And some people have huge investments in this, hundreds of projects inside of a solution, and they wanna start migrating things to ASP NET Core, we need to bring MSBuild back into the picture.

0:22:05 JF: Running things with the project.json model it just made that hurdle incredibly high to cross. The MSBuild has been around for 15 years, like it or leave it it's been doing a really good job for the dot NET ecosystem, but that's where we need to bolt on all of these cool features that we did put into project.json, and optimize MSBuild a little bit so that it does work and is capable on these other platforms. And the good news is, since the acquisition of Xamarin, we actually do have a compatible MSBuild that does work on Mac and Linux. So, we're gonna take advantage of that, we're gonna enhance the MSBuild project file.

0:22:55 JF: MSBuild actually knows how to do all of the things that we've built into project.json except for NuGet. We can teach it how to do NuGet by adding in tasks to it, but it's not something that we're sure we wanna bring in to the build process. We look at the package restore and the maintenance problem as something that happens outside of the build, something that you need to have those references in place before we actually start building and compiling your application. But as we move forward past ASP dot NET Core 1.0 RTM, we're gonna start to see that dot csproj file take on more and more responsibilities for managing the project. Now, the difficult thing that people see with this is, "Well dot csproj is XML and I have to use Visual Studio to manage it." And it is XML. And it's going to be XML for the foreseeable future. And Visual Studio is used to manage it, and a lot of the things that you do see in that MSBuild.csproject file is, it is GUI.

0:24:10 JF: It's Visual Studio GUI for managing the user interface. And with the project.json approach, we've actually changed how that works a little bit by introducing the dot VS folder. So you're gonna see some things change with how content gets into the dot csproj file. You're gonna see us introduce capabilities so that you can manage that project file from the command line. I mean, let's face it, when you do start like an NPM, a node package, a lot of people will copy and paste some boilerplate content into a JSON file, package.json, and then they'll go in and maybe they'll tune some things by hand but at the end of the day they've gotta run NPM install.

0:24:55 JF: And there's great tooling with NPM, to be able to save content into your package.json file. So that's an idea that we're floating, is maybe we enhance our command line tooling here, so that you can manage your MSBuild file a lot easier and you don't need to go into it. Because the workflow we do see people use, who aren't in Visual Studio, is that they do use the command line to update and maintain some of the content that's in their project files. And after they post some initial boilerplate content into their project file.

0:25:34 JF: Because once that project file is set, for a lot of people it's hands off, and they just, they're off and developing. It's really the code they focus on. And that's what we're trying to do, is we wanna make those project files, we wanna make the ability to bring in your package references, something that you don't have to focus on or think about. Those are things that are just gonna happen, and they're gonna happen very well for you during that boilerplate, start-up time. Once you've done that, you shouldn't have to go and interact with those things because you're gonna be able to focus on your code. And at the end of the day, you're writing code, you're not managing project files. And that's really what we're trying to get people to.

0:26:15 SB: So Jeff, let me get this very clear and straight. So you're saying project json is not entirely going away. It still stays and it lists your dependencies, correct?

0:26:25 JF: It's going to stay and list your dependencies at least through the 1.0 version of ASP dot NET Core. As we go through that, as the betas start rolling out for the version after that, things will change.

0:26:42 SB: Okay. So the dot csproj, which really is for MSBuilds to utilize inside of Visual Studio, that should be for Visual Studio developers, I mean you're not gonna put that on other cross-platform projects, correct?

0:26:53 JF: No, we're going to have to do that on all ASP dot NET Core projects you'll have a dot csproj that MSBuild, in those other environments, will be able to consume.

0:27:05 SB: Okay, but I mean from a collaboration standpoint, let's just say Ed is on his Windows machine and Visual Studio. He starts up in his dot NET core project, and he gets project.json and csproj as the whole shindig, and then he pushes it to GitHub. I'm on a Mac, and I'm on Visual Code, and I get the bits down, and for me if I do not use MSBuild, I can just simply look at all the dependencies in project.json and NuGet will still resolve those dependencies and the dot NET CLI will still build my project as is, correct?

0:27:40 JF: Through the 1.0 release, that's the way it will be working, yes. After the 1.0 things will change, and on your Mac you will be using a flavor of MSBuild that'll be enhanced and compatible across the... I'm sorry, that'll be cross-platform compatible. And it should be a very good experience. We're standing firm on some of these things that we wanna make sure are good experiences, and in order to make this work in a good way for developers across platforms yes, we're bringing the MSBuild but we're also gonna bring the features of project.json that people really like. So that we have an enhanced version of MSBuild that really delivers on some of the promises that we set forth in project.json.

0:28:35 SB: Got it.

0:28:37 EC: So what we're looking forward to is, in Sam's scenarios, if I start up... File a new project in Visual Studio on a PC running Windows then if he's using a Mac and an editor on there he would then use the CLI to access those features, and it would use that new version of MSBuild that's cross-plat?

0:29:01 JF: That's the concept that we're currently working with. Or, if you do like editing XML, if you like editing XML by hand, you can certainly go in there and write it. Which, you know what, a lot of web developers like editing HTML by hand, so it's not that far a stretch if you do have to go in there and edit, but I can understand some people with the concern about going in and editing MSBuild files.

0:29:29 SB: I'm fine doing it by hand, what's the big deal? [chuckle] So Jeff, on the CLI front. So clearly we are moving away from DNX and DNVM, and ASP dot NET is gonna use the new dot NET CLI going forward, correct?

0:29:44 JF: Yep, that's right.

0:29:45 SB: Of course, we have the convenience of something like a Yeoman generator which can kind of bootstrap and give us a nice starting point with the ASP dot NET applications, and then the dot NET CLI comes in. Is that the goal?

0:29:55 JF: So that's one approach. You can certainly use Yeoman to grab some boilerplate templates and start up an application. We also have the ability, with the dot NET CLI, to say '.NET new,' and you'll get a simple console application. There's other templates that we've talked about jumping into that dot NET CLI so that you can very easily say '.NET new,' ASP dot NET, and you'll get a selection of items there. It's open ended at this point.

0:30:27 JF: We're seeing the success of the open source approach here where we get feedback about whether folks like using '.NET new' or if they wanna use the Yeoman templates, and we'll curve things appropriately as we build out the framework and tools. We heard from some folks that they didn't like taking a dependency on Yeoman to use those templates, so we introduced dot NET new and we'll see how that lands. If folks like it, we'll build that out further, but you always have the opportunity to use Yeoman. But once that... Just like currently with the RC1, when you run yo ASP dot NET you can then come through, do your package restore, and then build process. You can do the same thing with dot NET. You'll be able to use new Yeoman templates when those are available and say dot NET Restore, and then dot NET Build, and you'll have a web application. This is about choice. It's which tools are you comfortable with? We're gonna make the tools available to you as best as possible.

0:31:35 SB: Sure. So maybe I didn't catch this new thing. So dot NET new will now actually let you kind of bootstrap an ASP dot NET application, that you could say dot NET new something like ASP dot NET?

0:31:45 JF: So right now dot NET new outputs a console application.

0:31:49 SB: Right.

0:31:52 JF: There is some concept floating about, "Hey, I'd like to be able to get a template ASP dot NET application when I say dot NET new." And that's something that we're testing and trying to figure out, "Is this something we wanna put in the box or not?"

0:32:05 SB: Yeah, I would love that, actually, just being able to have a consistent way to just new up your dot NET applications, you simply say, 'console' or 'ASP dot NET,' and it just does the thing.

0:32:13 EC: Now, would there be a way for developers to create their own recipes, so to speak, for that?

0:32:24 JF: You know what? I haven't seen the way that the templates are laid out for dot NET new. But being able to add in and enhance templates, it's a tenet that we've had with Visual Studio. There are ways to add features to the dot NET command line. As the dot NET command line evolves here, I'm not sure if that's actually gonna make it in, that you're gonna be able to customize those templates. But that is a story that we have heard.

0:32:55 SB: So Jeff, this might be, again one of those nitpicky questions, but I use DNVM core for quite a while now, and I used to enjoy the fact that I could do a DNVM list that shows me all the runtimes that I've installed on my machine. And then, as I'm building an ASP dot NET app, I could say, "No, go ahead and pick that particular runtime and package it with my app." Do we still have that with the new dot NET CLI?

0:33:17 JF: So with the new dot NET CLI, it actually will look at your project.json and see which version of dot NET that you're built with, which frameworks you're targeting, and it'll go find those and launch those immediately. So that you don't have this... I had this problem all the time 'cause I was installing lots of framework versions. You don't have this problem of mismatch where, "Oh, I built this application with RC7 and I currently have RC8 active. Oh, okay, let me go get that lined up." So it becomes smarter so that you don't have this mismatch. I'm just taking a look at the version of the dot NET tool that I have here, and this is an older version, an older nightly build, and I don't see a way to output a list of the runtime versions that you have installed. But you can certainly look in the NuGet packages folder and you'll be able to see them sitting out there.

0:34:21 SB: And I think this is the fun part of being the new dot NET. It's not something that's hidden, that you have no access to. It's a folder, just go look. It's all of your runtimes are right there.

0:34:32 JF: Yeah, absolutely. And it's actually worked out very well for us because people have found cool ways to integrate and do innovative things. And we like seeing that, it's encouraging to see a very innovative dot NET ecosystem that wants to get involved and it wants to go out and build cool new things with this.

0:34:58 EC: I just wanted to clear up one more thing, too. With this renaming of the DNX command line to dot NET.exe, when we're running ASP dot NET on other operating systems, is it still the dot NET execution environment that we're running to get the application going?

0:35:23 JF: It's not gonna be the DNX tool, you're gonna be using the dot NET tool to run that. So that CLI will run the same way on all three operating systems, and it does the same thing in all of them. You'll be able to say dot NET-run and be able to say, for example, I can call dot NET-run web and it'll run the web commands here for my application.

0:35:51 EC: So is the term, the ".NET execution environment" just dead as a whole?

0:35:55 JF: Yeah, that's gone.

0:35:55 EC: Okay.

0:35:57 SB: I think that makes sense. It was an acronym. I think just pure dot NET is just more simple and just think about this from a pure getting started standpoint. We are trying to really lower down the barrier to entry. Like a college kid with a Mac, just get dot NET and that's all. You can just bootstrap your application and get started. And to Jeff's point, you could actually say dot NET is essentially... The runtime is just a bootstrapper and so it can run an IL. If you want you can just say, ".NET run this particular DLL, in this particular folder." It'll do that or you can have more of a verb where you can say ".NET-build dot NET-run." And then it will combine a couple of things into one action.

0:36:36 EC: Yeah, I just wanted to clarify because you know, with these changes of course there is a lot of things that need to be updated. And that'll come slowly with time, but I'm still seeing the term ".Net execution environment" being used in documentation. So there might be some confusion for folks and I wanted to disambiguate that for people.

0:36:57 JF: Right. The documentation is being updated with all the information you need for the dot NET CLI and the DNX stuff is gonna come out of there. You're gonna see all of our branding update as the RC2 comes out so that ASP dot NET 5 goes away and it's now being referenced as ASP dot NET Core. It really is a big task for us to get all of that content, all of that branding moved over and talking about the new tools, the new product in the appropriate way.

0:37:32 EC: And where are things heading with cross-platform and things like Docker?

0:37:37 JF: So we're doing a lot of work to try and get our Docker story much more improved. Our initial test docker images were big. They're 800 meg on top of a Linux version that is really small, it's 20, 30 meg for that base docker image and then we start layering stuff on top of it. And it gets to be pretty big even before you put your application on top of it. So, we're doing some refactoring in there to see if we can make those images smaller, to simplify things, so that you can really move your docker images around, your container images to any platform very, very quickly. So that's one piece that we're seeing. We're also seeing folks that wanna run on the smaller Windows Nano environment. So we're trying to make sure that we have Windows Nano images and capabilities all set-up so that you can deploy that Nano server very quickly with a dot NET Core, ASP dot NET Core install and get tremendous value out of that, and stand up a bunch of those.

0:38:47 JF: Maybe you wanna manage micro-services that have active directory built in to them, you're gonna be able to do that. So we're really investing now in this story because we heard from a lot of customers that want to be able to do... They wanna be able to take things over to Linux. They've got a lot of investments in Linux environments, they wanna take things to Unix environments, they wanna take things and really explore the micro-service approach and have smaller server installs that really do one or two things extremely well. And we wanna support that type of distributed, computing architecture so that's what you're going to see, us make a little a little bit more investment in here as we move forward.

0:39:31 JF: And it's something that we heard loud and clear after that November release of the RC1. So, very much the open source, the Release Candidate approach that we were taking, worked very well for us to be able to hear feedback from customers who were looking at the source code, who were interacting with the pre-RTM versions of the tools, of the framework, and giving us their feedback about where they needed to see it go to support their workloads. So, we're really excited about that, that's something that really helps us as we really embark on our first, entire framework that is built completely in the open with all kinds of feedback coming in. We're very happy with this.

0:40:21 SB: So Jeff, I think the last sentence of what you said really resonates with us and I don't think it's lost on anybody that what you guys are really doing, it's monumental. You are essentially setting up dot NET for the next 10 years and all of the work that you're doing with ASP dot NET is kind of repositioning it to be more forward and future facing.

0:40:40 JF: Yeah, it really is. I mean think about it. The dot NET base class library that we use in windows forms, ASP dot NET 4.6 has been around for 15 years, the base components of it are the same thing that have evolved from way back from 2001, 2002. So, we're trying to reinvent for this new world where, "Yeah, you know what? There are such things as smartphones. There are IOT devices. There are huge clouds where we wanna deploy a tremendous memory space and processor capabilities." And we need to expand the dot NET platform to be able to handle all of those things and set it up to expand for the next generation of technologies that are coming along, like you said Sam, over the next 10 years.

0:41:33 SB: Yeah and you can take to things like HoloLens and Xbox that just opens the frontiers a lot more.

0:41:40 JF: Oh yeah. Xamarin has landed dot NET on a number of platforms that we wouldn't have even considered. But, we're there now.

0:41:49 SB: That's true. One last thing, NuGet, so we talked about how it knows how to bring down your dependencies from either a hosted server or just plain up straight up NuGet. Where are things headed with NuGet 'cause I know we talked about this a little bit where, is truly NuGet gonna be dot NET-focused and you're letting the Bowers and the NPMs do the JavaScript handling?

0:42:14 JF: Great question, Sam. So, yes, we do wanna keep NuGet and the NuGet.org service focused on dot NET capabilities. Bower and NPM are tremendous package managers that managed those environments very, very well for those folks who are writing CSS libraries, JavaScript libraries. There's no need to reinvent the wheel and try and figure out with NuGet how to shoehorn those things in. Because really, the folks that have built some of these libraries, they're not really publishing to NPM or to Bower because those environments, they really just host a pointer back to the GitHub repositories that those projects use. So, they update, submit a record once to those repositories, and whenever there's a new tag in those Git repositories, that's what you're gonna see when you do a Bower install or an NPM install.

0:43:16 JF: Where NuGet, we need to host binaries... Dot NET hosts and delivers binaries to the NuGet.org catalogue and repository, so we're hosting a ton of capabilities out there in these DLLs that we're managing, inspecting, and delivering. So, with all that overhead and managing the way that the dot NET ecosystem works, why try and reinvent the wheel and republish things whenever there's a new version of Knockout, or Angular, or React? Let those package managers that manage those things, that those project teams have already submitted their stuff to, let those package managers work very well inside of our ecosystem, so that you get the best of both worlds.

0:44:07 EC: Yeah, this is a question I've been answering quite frequently as of late, because I used to maintain one of those packages. So if you've ever used the foundation CSS, HTML framework within dot NET you've probably used my package. And I've been letting people know over time that that package is gonna cease to be updated because these new capabilities are part of dot NET now, and we don't really need to maintain that in an additional spot just for dot NET.

0:44:43 JF: Right.

0:44:43 SB: And also for NuGet, I think the importance of NuGet increases a lot more in the dot NET space, because the whole core framework is actually broken up into modular pieces, which are delivered through NuGet, to Jeff's point we are delivering binaries through NuGet, so I think it's much, much more important in the dot NET space.

0:45:00 JF: Right. When you think about it, there's... In the dot NET 4.6 and earlier world, you only ever got a new version of the dot NET framework when there was a new version of Windows or there was a new version of Visual Studio. And when that happened, you got this big, couple gigabyte install that came down and put down a base class library on your system. You got tools appropriate for things, and as we move into this more modular world where we're not gonna deploy a base class library with Windows, you're gonna get your base class library from the central NuGet.org package repository, well now things change, and you're right. The base class library is something that you now get when you need it, which actually works out great for people like my mother who isn't technical, and she won't get a Windows update that says, "Now we're installing dot NET framework 7. Whatever that doesn't exist." And she doesn't use that. It's not a runtime that she needs for any of her applications, so why should she install it? In this new opt-in world, I only get the dot NET framework when I need it, and I can package it with my application, so just those components that I need are installed with my application. It's a win-win scenario for consumers, for developers, and for operations folks.

0:46:31 SB: Okay, so a couple more things I guess before we wrap up. Tag helpers, I know you and Ed are both big fans of that. Where are things headed and why should people look to use tag helpers? We keep getting the question as to how close they are to the ASPX days. What are some big advantages?

0:46:50 JF: So, tag helpers are gonna be in the 1.0 release here of ASP dot NET Core, they're part of the RC2. They're really an evolution of those HTML helpers that you got in MVC. And we've heard this story before, if you've heard anything about tag helpers, it really is a way for us to take that embedded C# that you got when you did @html.inputbox and turn it back into a tag that looks and feels like HTML. But the catch is, and where this is different from those ASCX approaches that you had before when you build user controls, or when you wrote a composite control, a compiled control that was a C# file that got compiled and you can reference inside of Visual Studio. The difference is, you don't have access inside of this tag to the entire page structure.

0:47:48 JF: Now, what a lot of people who were writing those user controls and compiled controls, what they would do is they would make some changes to their control and then they would go and throw some capabilities out into the head of the file. They would make some changes to various locations all over the form and they really had carte blanche access to the entire web form. And that can be dangerous. It's this black box that has full control over the code you wrote. With tag helpers, you only have control over what happens between the starting angle bracket and the ending angle bracket/angle bracket. That's it. So you can do a lot, they could be very powerful.

0:48:35 JF: It also gives us the ability to hand some of that HTML creation to our designer friends who can then say, "You know what, I'm gonna put a scheduler control here." And they can just use a tag helper appropriate for a scheduler, and it just appears where they put that in their HTML. They don't have to learn how to use in the ASCX notation with all the properties and things. They don't have to learn how to go grab some ASP: Control and add that into their web form. They can really focus on just using angle brackets like any other piece of HTML. Which really is the same direction that folks are going with the JavaScript frameworks like Angular and Aurelia. We wanna give you these capabilities so that you can program in something that's more like HTML, with some code that's hiding behind the scenes, that's gonna render that the way you want to but only affect just that area of the page.

0:49:35 EC: And I think more importantly in that respect, you can define a class, a CSS class, right on the tag without having to know C# and open up anonymous objects. And you can inject data dash attributes without any kind of trickery or...

0:49:54 JF: Absolutely. All of the Visual Studio tooling is still there and still knows how to manage HTML. And even though you started with a "foo" tag, it knows when you type class=, "Oh, I'm looking for CSS classes." And it's gonna give you IntelliSense on classes. You type style= and it gives you all the hints around CSS styles. Very cool stuff where the tooling helps you.

0:50:20 SB: Yeah. And I think I like the simplicity of just going down to plain HTML-like angle brackets on it. And these are just literally like HTML things that you're writing up and they may look like old ASPX days, but they don't function like those things. And HTML helpers, as nice as they were, it made me cringe sometimes whenever you mixed up server side C# with some HTML and sometimes it didn't get all the IntelliSense and having to adjust I mean, you had access to a lot more things in code that you possibly didn't want to do from your HTML helper. So, yeah, good things.

0:50:50 EC: Yeah. And to put people at ease we're not talking about Razor going away in any shape or form.

0:50:56 JF: No. Razor is very much our preferred templating mechanism for ASP dot NET.

0:51:02 EC: And I also see some uses for some more complex controls as well. For example, maybe something that's very configuration-heavy like a grid or something, still may be more palatable from a fluid API coming off of a Razor HTML helper rather than a tag helper.

0:51:23 JF: That's right. Those capabilities are still there but with tag helpers you also have the ability to put child tag helpers inside of. So you can certainly say, "You know what, let's create a grid tag helper and inside of that grid tag helper let's have column tag helpers that know how to manage column formatting." So there's all kinds of capabilities that are in there that we're waiting to see folks explore and deliver on.

0:51:54 EC: Yeah. It'll be interesting to see those things come around as the tag helpers mature.

0:52:01 SB: Yeah. So why don't we let maybe Jeff do the closing rounds to kind of give us the future of ASP dot NET. And my last pitch, before we round up, would be I'm excited as a dot NET developer with some of the directions that dot NET is going, the places that you can take dot NET that you never were used to before. The flexibility that I have to work on a Windows machine and on a Mac or anything and be able to build and collaborate with my team members. I also think that as great as the ASP dot NET ecosystem is gonna be, there's always space for richness of the ecosystem to be enhanced by parties outside of Microsoft which is where folks like us at Telerik, we come in and we will give you all of the UI controls that you can render now through tag helpers.

0:52:41 SB: We do have support for the new RC1 bits and will eventually have several for the RC2 bits. So you can actually render and work with our controls in a cross-platform way. So I'm excited as an ASP dot NET developer, as a dot NET developer, and be able to do these new and fun things. I'm not tied down to Visual Studio all day, I can work on a little text editor and be equally productive with CLI. So that's all from me. Jeff, why don't you give us your vision as to why you're excited about the next iteration and about the future?

0:53:14 JF: The number one thing I'm excited about is performance. Bar none, the team has just teed off on the performance question and story around ASP dot NET, and they've hit it out of the park. The original tests that they were showing for ASP dot NET web forms, for ASP dot NET MVC, it didn't even compare, it wasn't even in the same league as some of the other frameworks that are out there. But the changes that they've done to make it palatable, to make it perform better are tremendous. In our development lab right now, we see 1.1 million requests per second come through on both Windows and Linux servers.

0:54:00 JF: That's tremendous, but we've had to park our performance working there because we hit our first goal. We crossed a million requests per second. When we get on the other side of the RTM here, there's a pull request or two hanging out there that are gonna bump us up by another 50%. We're gonna get up to 1.6 million requests per second in our development lab and that's gonna be very respectable, compared to some of the other frameworks out there. It certainly surpasses some of the open source ones, Ruby, Node. ASP dot NET is gonna be at the top of the heap, ahead of those. And really we're focused on these TechEmpower benchmarks that are out there that have more powerful machines than what we're using in our development lab. And then Equivalent Hardware, we're seeing significant performance there as well that are gonna put us in the top 10 easily of their industry-wide web benchmarks. We're very excited about that.

0:55:00 JF: I'm excited because it means that you're gonna need less hardware, less server requirements in order to drive the same throughput that you had before. So from a performance point of view where I love talking about server-side web interactions, I can't be more happier to see that coming through and landing. I'm excited that we've got this RC2 now, we're gonna see RTM in June. And we're gonna start getting ready for the tooling integrations that are gonna happen with Visual Studio 15. When that version rolls out, there's a preview release of Visual Studio 15 out there. We're gonna start to see tooling builds that work with Visual Studio 15 some time after the RTM of ASP dot NET that'll bring those standard bits of debugging and advanced capabilities that you want to profile your application that you've used with Visual Studio for all these years, they're gonna bring it into that application. I'm very excited to see that land. We're gonna see SignalR come back after the RTM, we're gonna see a new version of that introduced. It's something that's bubbled to the top of our list. We've heard a lot of feedback from folks who want to run SignalR on ASP dot NET Core and that's something that we're gonna be bringing back to ASP dot NET Core after the 1.0 release.

0:56:35 JF: So there's a few things that are on the immediate agenda, that we're gonna be working on. And you know what? We've tried to be very flexible with our schedule here. And as customers raise features that they want because they're seeing what we're doing, we carve our sprints appropriately, so that we can deliver those features. So we've had a very fluid schedule and things like F# capabilities have started to get into the box. We're gonna see VB come into the box here soon. And it's these changes, this ability to react to customer requests that I'm very happy to see. And it's landed some of our core tenets in this rewrite of ASP dot NET Core and dot NET Core very, very well. And I'm looking forward to working with the community in the future to further guide the way that this framework develops. It's very exciting.

0:57:40 SB: Yeah, well said.

0:57:41 EC: And Jeff, we're recording this on Friday the 13th, but we're gonna be actually airing this on Monday, the following Monday. When will we see the new bits released? Where do we get them? And how do we get started?

0:57:58 JF: Since we're time-shifting, you should be able to get them today. If you go to get.asp.net, you'll be able to see a download there for your appropriate platform that you navigated to that website with. You should see a download there for the current version of the tools with Visual Studio 2015, for Visual Studio Code and a jump-off point to get the command line interface, so you can start to download and work with your projects. You're also gonna be able to go to a new website that we're standing up. It's dot, D-O-T.net. That's kind of confusing, but dot.net. You're gonna be able to go to and get the latest versions of dot NET Core. You'll be able to get a jump-off from there to get ASP dot NET Core. But if you're working with dot NET Core and you wanna build cross platform console applications, you'll be able to go to just dot dot NET and get some of those things.

0:58:58 EC: And where... Sorry, go ahead.

0:59:00 JF: No, no, so that's our jump-off point. And you can get documentation at docs.asp.net. And of course, every week the lead program managers on the project have a video series they run at live.asp.net.

0:59:17 EC: And where can we find things that you're writing and find you online?

0:59:21 JF: Oh, good question. Let me plug myself here. Here we go. You can read all about the things that I'm writing for Microsoft. I manage the Web Development Blog on MSDN. That's blogs.msdn.com/webdev. I also have a personal blog that I manage stuff at, at JeffreyFritz.com and I've started a video series there called "10 Minute Tips with Fritz." So I've got little 10 minute snippets of, "Here's how to do something in ASP dot NET Core or do something with ASP dot NET 4.6 and earlier." I post these videos to YouTube and it's really, it's 10 minutes of, "Here's how to go through and do something simple." I've got a handful of videos out there now, and it's something I'm trying to do on a weekly basis.

1:00:10 EC: Great. We'll wrap all those things up and put those in the show notes. So, if you're listening and you wanna go grab those links, go to developer.telerik.com and look for the show and we'll have all the links to everything that we talked about today.

[music]

1:00:26 JF: Sound great. Thanks a lot, Ed.

1:00:27 SB: Alright, Jeff. Thanks so much for being on the show with us. We really appreciate your time.

1:00:31 JF: Cool.

1:00:31 EC: Absolutely. Thanks for coming out, Jeff.

1:00:33 JF: No problem. Have a good one, guys.

1:00:35 EC: Alright. Bye bye.

[music]

1:00:55 JF: For web services, web applications. That was it. You really had only three or four types of projects. Class libraries, I think, were the other things you had in there. So, let me pause you there for a second, guys. I've got a meowing cat here I've got to kick out.

[background conversation]