The .NET Core 2 Wave

This article was updated on December 12, 2017.

Will 2017 be the year of .NET Core? Of course it will!

I sat down with Scott Hunter (Director of Program Management for the .NET Platform) on the Eat Sleep Code podcast to talk about all things .NET. Scott shared plans for an exciting year of .NET development including the .NET Core 2 Wave, which includes the .NET Core 2.0 release along with .NET Standard 2.0, adoption strategies, and Visual Studio 2017 tooling.

What to expect with .NET in 2017

Scott elaborated on the status of .NET Standard 2 by saying:

I can say today we've done all the work internally to get all the APIs, they're actually working now, it just going to take awhile to get them shipped.

Internal builds of .NET Standard 2.0 are finalized and staging to ship. This means that early this year we should see the .NET Core 2 wave begin.

Update: .NET Standard 2.0 and .NET Core 2 shipped on August 14, 2017

.NET Standard 2.0 targets the intersection of APIs that .NET Framework and Xamarin support. As a result the .NET Core 2.0 wave will allow developers to code share between .NET Framework, .NET Core, and Xamarin by targeting .NET Standard 2.0. This also brings many APIs into parity that were missing from previous versions of .NET Core / Standard. Shipping later this year is UWP support for .NET Standard 2.0, expanding code sharing capabilities to that platform as well.

// "The .NET Core 2 Wave" is one of our top 5 .NET articles of 2017. See the full list here.

When should I adopt .NET Core

Since the .NET Core 2 wave is coming many developers want to know "When should I adopt .NET Core". Scott laid out a very clear plan to help weigh out the options.

It's a great solution today (.NET Core 1.x)

Most folks that jump on .NET Core or ASP.NET Core today are primarily doing it because they have a business reason. -Scott

• If you want to create an ASP.NET Core application that is cross platform;
• If want to take advantage of building container applications;
• If you want to break free of global installation with side-by-side versions of .NET Core;
• If you want superior performance.

The best of both worlds

Scott also shared an excellent tip for developers who are still evaluating whether or not to use ASP.NET Core.

If you do want to try ASP.NET Core or Entity Framework Core today. You can run them against the full framework and have all the APIs that are there (full framework). That's another option if you want to try it today. You don't get the cross platform and side-by-side benefits, but you will get the high performance. So the same ASP.NET Core that ranks #10 in the TechEmpower benchmark for serving JSON will perform the same way on .NET Framework as well.

Should I wait for the .NET Core 2 wave

If you're still not convinced it's time to try ASP.NET Core, then you can always wait for the .NET Core 2 wave. If you need APIs that are missing from .NET Standard 1.x, many are back in .NET Standard 2.0. Also the aforementioned API Parity between .NET Core and Xamarin will mean easy code sharing.

UI for ASP.NET Core is available

It's hard to imagine ASP.NET development without Telerik controls. Telerik (now Progress) has been around since the early days of .NET and continues to support .NET Core with UI for ASP.NET Core. UI for ASP.NET Core includes all of the controls available in UI for ASP.NET MVC with the addition of TagHelpers. Scott shared some fond memories of being introduced to ASP.NET through Telerik controls.

The Telerik controls are I think are one of the things that drew me to .NET back in the original .NET days. - Scott

You could build a slick-awesome application with a lot of functionality in no time with those controls [Telerik Controls]. I'm super happy that there's Core version of those today. - Scott

If you buy this stuff [Telerik Controls], I can do the work of five people myself. - Scott

Visual Studio 2017

If you're currently on .NET Core you're probably using Visual Studio 2015 with preview tooling 3. The first release version of .NET Core tooling will come with Visual Studio 2017. In Visual Studio 2017 projects will revert back to .csproj from project.json. The new .csproj system will include all of the great features introduced in project.json like:

• Simplified csproj, just a few lines of xml that is very easy to hand edit
• Simple package references
• IntelliSense
• Live package management within the file
• No need to list all of the files in the project
• Cross-platform targeting
• No more GUIDs

We wanted to make sure we didn't lose any of the goodness we learned with project.json. - Scott

What else is in Visual Studio 2017

• Live unit testing will also debut in Visual Studio 2017;
• Light weight installer;
• .NET Core support, no more preview.

To learn more about the new capabilities of .NET; including fundamental improvements and standardization efforts that bring forth the best ideas for modern .NET development, then get the free whitepaper The State of .NET in 2018.

Eat Sleep Code podcast

For more details and extras that weren't covered in this post, listen to the show in its entirety below.

Scott Hunter

Scott Hunter works on the .NET Platform with is made up of the .NET Framework, .NET Core and the Managed Languages. Prior to working on the .NET Platform, Hunter helped the Azure Developer Experience team build the Azure SDK’s, App Service Tooling, Azure Redis Cache, Azure API Management, ASP.NET, Entity Framework and the Web Tooling. Since joining the company in 2007, he has made many contributions to the ASP.NET platform including MVC, Web API and more. Scott graduated from Cal State University with a bachelor degree in Computer Science and a minor in Economics.

Show Links

• Get .NET
• A day with Scott Guthrie
• Blogs about .NET
• Kendo UI webinar

Show Transcript

00:00 Ed Charbeneau: This podcast is part of the Telerik Developer Network. Telerik, by Progress.

[music]

00:16 EC: Hello, and welcome to Eat Sleep Code, the official Telerik podcast. I'm your host, Ed Charbeneau, and with me today is Scott Hunter. How're you doing, Scott?

00:25 Scott Hunter: I'm doing great.

00:27 EC: Scott is the Director of Program Management for the Dot NET platform. This includes the Dot NET framework, Dot NET core and the managed languages. Scott, I'm glad to have you on the show today.

00:39 SH: Yeah, I'm glad to be here. Looking forward to chatting about Dot NET with you.

00:45 EC: Yeah. It's a great way to kick off 2017, this being the first show of the year for me, appreciate you making time to do this, and we've got a lot of stuff going on in this new year with Dot NET, so this is a great topic.

01:00 SH: Yeah, it's been... I joined Microsoft in 2007. I was a web developer, I guess is the best way to describe it. So, I was a web developer and I joined in 2007, and joined the ASP.NET team. And that was interesting because, as an external person, I walked in, going, "Hey, this ASP NET thing is gonna be this huge team." And I remember walking in and I realized, "Oh my God. We only have like 12 developers, and three or four PMs," and we had support staff as well. So the whole team was under 30 in size when I joined in 2007, and it's... Externally, I think I was just imagining Microsoft, this huge company, that ASP NET was gonna be this massive team. But it was a great team because even though it was a small team, we got a lot of crap done because we... Everybody was super effective and everybody loved the platform, and I think we did more with a smaller group of folks than people would ever imagine. And a lot of things that we started back then in 2007 are the things that you see in Dot NET all up today. The ASP NET team was one of the first teams... I was gonna say in 2008, we started open sourcing ASP NET MVC for the first time, and then, by 2012, we had actually open-sourced the platform, all of the ASP NET platform by then. And now, look at Dot NET today, and we've got Dot NET core, and the entire Dot NET framework is open source out there. So, it was... Some of those things we did back in those days were the seeds that have grown and built a platform today.

02:48 EC: Yeah. It's the Dot NET folks that are the ones that spearheaded the open-sourcing of Microsoft, is it not?

02:58 SH: There was other teams as well, I don't want the Dot NET folks to take full credit for that kind of staff. There was a wave of us that were all looking at the open source base, and I think what made Dot NET, specifically, an early pioneer in this area was mainly that the things we competed against were already open source. It was hard for me to sit there and say, "Hey, there's Ruby on Rails," which was popular back in 2007. Now there is no JS, there's Java, there's Go. All these technologies are completely open source, and how do you compete against one of those things when you know, "Hey, any developer that wants to use any of those platforms can just go download the source code or look at the source code to see how something is implemented or even make a PR to actually put a request to suggest a change in the platforms." And so I think it was mainly because we were competing against open web technologies, which led us down the path of the only way to compete with those things is to be on the same grounds as they were as well.

04:09 EC: Yeah, I think developers flocked to the distributed source control type of a model, and everybody's sharing code these days and it's just where the industry, as a whole, went. So it's great to see Microsoft, the big company that supports a lot of corporate-type development, also getting into that arena. It's a tough shift. This isn't what people are used to, in that regard.

04:39 SH: It was even a tough shift for some of the companies. In fact, I still hear rumblings and stuff around this. For example, a lot of companies that adopted Microsoft technologies back, especially in 2008, they looked at open source... They looked at us, Microsoft, as, "Hey, the reason we're buying IBM or we're buying Microsoft is because we have this supported platform." In some ways, the non-open source-ness was what attracted those people to our platform, and we had to do a bunch of education with those companies as well, saying, "Hey, yeah, the platform is open source," but that doesn't really change the world for you, because the reality is, if you download visual studio or you go and download Dot NET framework, the thing you downloaded and installed is Microsoft-supported, it's got a Microsoft EULA on it. You can pick up the phone and we'll treat it just like we did before. And so there really is a blur there. A lot of times, I used to explain that when you look at Chrome, there's two versions of Chrome, there's Chrome and there's Chromium. Chrome is the browser that most people use, and I would actually challenge it's not open source, it's actually closed source.

06:01 SH: It's a fork of Chromium. Chromium is the open source version of Chrome, where a lot of developer work goes on and then they pick the things from Chromium they want to put in the commercial product. And I think of Dot NET the same way. It's like if you wanna go to GitHub and download Dot NET and build it yourself, well then, you're using the open source version of Dot NET. If you actually want to download my installer and use my installer, well then you've got a Microsoft Sign, Microsoft EULA, fully supported version of Dot NET. And so there was a lot of education for us just two companies, but I will say it is amazing to see... I spend quite a bit of time each year traveling around the world and talking to customers, and it's amazing to walk into some of these big, big companies that... I can't drop names, but big companies around the world, and seeing them embrace open source now. So what was scary in 2008 and 2016, I walk into a lot of these companies and half of the stuff they're using is open source.

07:09 EC: And relatively speaking, eight years isn't a very large amount of time for that kind of a paradigm shift either.

07:15 SH: Yeah, that's... I think that's... That is crazy fast, actually. Seeing an industry shift the way it did from closed proprietary software to very open software over that period of time is amazing, and you see that all through Microsoft. The Azure cloud that we have fully embraces open source. Linux is fully supported there, Windows is fully supported there, Node, Java, Go, Python, Ruby. It's... I think the days of saying that you build something in just one technology are over. Today, most of us have some kind of collection of tools and software that we use to build the apps that we work on today. That's also fun for, I think, you and I as well, because you get to touch a lot of different things.

08:11 EC: Yeah, it seems that open source pushes forward the cross-platform adoption as well. It's like if you have something that's open source and it's out there, there's people on different platforms that need to be able to work on it, there's people on different platforms that need to run it, so that leads us into things like ASP.NET core, where we are seeing it ASP.NET and C# running pretty much everywhere.

08:36 SH: Yeah, that was also... Open source was the first wave that I said we started in 2008, and then I think the cross-platform was the next wave, and we really started that a couple of years ago. At the time, we called ASP.NET... I think we were calling it ASP.NET vNext, and we also used the term ASP NET 5 back in those days. But the real driver for us there, once again, is we want to make Dot NET and we wanna make ASP.NET something that works wherever you are. Some folks will wanna run ASP.NET on an IOT device or they might wanna write it as... If you are at home and you've got a router hooked up to your cable modem, it's very likely that when you go into the admin screen in your router, that's running PHP or it's running Node. In the time that these routers were created, you couldn't run ASP.NET on one of those things because ASP.NET only ran on Windows. And with the open cloud and the way that the industry is moving, we wanted to make sure that Dot NET and ASP.NET work everywhere, and the Xamarin acquisition that we had... Well, actually not earlier this year now. It's early last year, it was also part of that wave. I want Dot NET to be... Our term is anywhere. Anywhere you are, you can run Dot NET.

10:02 SH: So we've got Dot NET that runs on iOS and Android. I've got Dot NET that runs on Windows. I've got Dot NET that runs on Linux, and as you said, it's... The Linux part of it's crazy because when we first were shipping the prototypes of Dot NET core that we're running on Linux, obviously, the first thing people wanna do is they all have their variance of Linux that they wanna run it on. And it was so fun, as the team, we were just trying to get the thing to work it all, but very quickly, people had ports to free BSD. Over the Christmas holiday, we had some external folks getting it, running it on ARM32, and so it's been fun seeing the community step in and get it running on platforms that we haven't had time to think about it yet.

10:50 EC: Earlier you talked about the Dot NET team being approximately 30 people when you first started.

10:58 SH: That was the ASP.NET team, let's be very clear.

11:01 EC: Or the ASP.NET team, specifically, okay. Now, with things like ASP.NET core and running on multiple systems, and that expands things, you would imagine, like testing and development. Is this causing the team to grow on its own or was it to a sufficient size before? As a program manager, have you had to, say, hire new people? Has the team been expanded or did you draw from other teams within Microsoft? Has the community stepped up and made up for some of that?

11:38 SH: Best way for me to answer that, that's actually a multi... There's a couple of interesting things to think about when we answer that question. One of them is back when I joined the ASP.NET team, the ASP NET team was part of developer division and then in 2010, Scott Guthrie started his transition from Developer Division into the cloud, and when that happens, all the webby parts of Developer Division went with Scott to the Azure organization, and so we left... The ASP NET team left Developer Division in 2010. We also brought with us the web tooling parts of Visual Studio, and the reason we all switched was, hey, this Azure cloud at Microsoft was becoming an important area for the company and Scott wanted to make sure he had all the things with him to make sure that we had a great experience for developers, for the cloud. And so that was an interesting time because the ASP NET team was technically not part of the Dot NET team after that transition. We lived by ourselves in a different part of the org for quite a few years. It was... 2010 was when we moved over there and we merged back with the Dot NET team in early 2016. So we were gone for six years. As we started planning ASP NET Core or ASP NET 5, whatever you wanna call it, when we started planning that... And Dot NET, over history, I'm sure the investment... I wasn't in the team, but I'm sure the... The investment of anything goes up and down at times.

13:29 SH: So there was a big point where the Dot NET team focused a lot on Windows 8, they focused on universal Windows platform. And so the investment goes up and down, but we did grow the team when we decided to go do the cross-platform thing. So that did involve us getting some more folks into the team to help us take Dot NET and make it work cross-platform. We had actually shipped a couple of cross-platform versions of Dot NET before, so we... A lot... Some of the code that you'll see in Dot NET Core comes from Silverlight. And so Silverlight was a web plugin that worked on primarily Windows and Mac, but the folks at Xamarin had a version of it, I think, called Moonlight that also worked on Linux as well. And so we'd actually had some ports of Dot Net that were actually cross-platform already. Another thing that happened along the way was when the Xamarin acquisition occurred, one of the things that happened there was the license on Mono was changed to be a license that made it very easy for us to take code from Mono as well. Mono also takes code from us too, so it goes both ways. When we open sourced the Dot NET platform, they immediately started taking chunks of Dot NET and... That they'd all done in a white room. They would much prefer to actually have the exact same code that we have in the Dot NET framework, and so they were taking code from us and we could take code from them.

15:09 SH: And so the cross-platform Dot NET is the culmination of code from Silverlight, code from Mono, and then lots of code that we just have ported ourselves to our cross-platform.

15:22 EC: Yeah, I've been a Dot NET developer since ASP.NET 1.0, so I've seen these changes come about over the years, but it's interesting to hear the history that's gone on behind the scenes to make all this stuff happen to where we are today.

15:39 SH: Yeah. It's... As interesting as it might be from your seat, trust me, it's even more interesting from my seat. I remember back, right as we were starting to plan the ASP NET 5 wave, which now has become, as I said before, ASP NET Core, I remember going into some of these executives at Microsoft's offices and saying, "Hey, we wanna open source and make it all cross-platform." I think... There were some folks that were skeptical of it when we first went and threw those proposals out there, but we did a prototype and the feedback on the prototype was so good that it convinced everybody that we were heading down the right path.

16:26 EC: And speaking of that path that we're headed down now, you were talking about Xamarin and Moonlight and some of these other open source initiatives or cross-platform initiatives like Mono that's brought us to this new Dot NET standard in a way. So we have this new Dot NET standard that's trying to help us solidify what the portable class libraries were trying to do in the past. Can we talk about that a little bit?

17:01 SH: Yeah. That's... The Dot NET standard is an interesting area and it came about... In early January of 2016, is when we started talking about Dot NET standard. I had just moved... We had just merged the ASP NET team, the Entity Framework team, and the Dot NET team back together into a single team, and we were holistically looking at our frameworks and going, "Man, it's... " It felt, to some of us, that we had a couple of different Dot NETs. There was Dot NET framework. There was ASP.NET Core, I guess, at the time. There was Xamarin, and there were some Windows platforms like UWP and Windows 8 that existed as well. And those were all probably the current platforms of Dot NET, but as we looked at those, each of those had different APIs. And so if you were a Dot NET developer... Let's say you're a Windows Forum developer or a WPF developer, and Microsoft shows up and says, "Hey, we'd like you to write a universal Windows application, and the reason you should write one of these is you write the application and it will work great on all the Windows devices and it will have great support for touch. It can even run on Xboxs and HoloLens. So you can write a single app that runs on all those platforms." But developers, as they started trying to build a UWP application, would run into some hard edges.

18:39 SH: There was a bunch APIs that were considered Core Dot NET APIs that were just missing on the platform and that's kind of... Because the Windows team, like the Dot NET Core team, was re-imagining how you build Windows applications. Likewise, if you were an ASP NET developer and you moved and tried to write some code in ASP NET Core, you would probably find a good chunk of stuff missing. For some customers, that was okay because they want cross-platform so bad that they're just gonna figure it all out, but it was very clear to us that we had a fragmented Dot NET platform, and we started having discussions about how we defragment Dot NET. And the way to defragment Dot NET that we came up with was... At the time, each of these platforms would say, "Here's the APIs I want to support." That makes sharing code across all these platforms super, super difficult. And so, as the Dot NET team, we said, "Hey, we wanna grab the reins of the APIs," and the Dot NET team defines the APIs, they exist on all the platforms. And that really is what Dot NET Standard is. Dot NET Standard is a definition of, "Hey, the Dot NET team has defined a series of thousands and thousands of APIs, and if you want to be a Dot NET Standard platform, you have to make sure these APIs exist on your platform." And so the first wave of that shipped with ASP NET Core, but I would say that the set of APIs in that wave was very small.

20:20 SH: And at the time, Xamarin supported them and Dot NET Core supported them, and obviously, Dot NET Framework supports them. But our vision, moving forward, is we have something called Dot NET Standard 2.0, and that will ship later this year. We're not very far away from it. In fact, internally, I can just say today, we've actually done all the work internally to get all the APIs... They're actually working now. We just... It's just gonna take us a while to actually get them shipped, but the idea there was to take an intersection of what the Xamarin platform supported, what Dot NET Framework supported, and use that intersection of saying, "Hey, here's the APIs that cross between these things." 'Cause we wanna make code share across Xamarin and Dot NET Framework very easy. They both have to have the same APIs, and so the initial wave of the Dot NET Standard 2 is basically taking that intersection and making that the base of the platform. And so, later this year, or early this year, you'll see us shipping a version of Dot NET Core that supports Dot NET Standard 2.0. Dot NET Framework, because it's the mother of all Dot NETs, they, of course, already supports Dot NET Standard 2.0, and Xamarin will support Dot NET Standard 2.0.

21:39 SH: And that means you can write code... I would hope in the future, developers don't target frameworks, they target Dot NET Standard. And by doing that, you could make a NuGet package, or a code library, and it will easily work on all the platforms. And so that's a key tenet of that. Later in the year, you'll see us bring Dot NET Standard support to UWP applications, and at that point, I think we really have... We'll have nailed the Dot NET Standard scenario, which means it's super easy to share across Core, Full Framework, Xamarin, and UWP. And if you're a UWP developer today, you'll probably rejoice because you're gonna get a bunch of APIs that are missing back as part of this. But it makes Dot NET feel whole again to me, and that's... That really is the goal of the team, is... We wanna have one set of APIs that you can count on everywhere, and then we have another wave of work that's coming with VS 2017, and that is having the same tooling platform across all the Dot NETs as well.

22:50 EC: So if there's folks out there that are maybe waiting to start working with Dot NET, ASP.NET Core or Dot NET Core, because they're worried that there's going to be some libraries that aren't supported or API surfaces that they feel might be missing, do you think Dot NET Standard 2.0 is going to solve that and that's a good point for people to jump on and start using ASP.NET Core?

23:21 SH: Yeah. I would say today... Most folks that jump on Dot NET Core or ASP NET Core today are primarily doing it because they have a business reason, and there's a couple big business reasons why Dot NET Core might be interesting to you. One, obviously, is if you wanna build applications that can run cross-platform, so maybe your company is standardized, its data centers on Linux, and you have Dot NET assets and you wanna have these Dot NET assets work in the hardware your company's running, then Dot NET Core is a great solution today, even though there's some of those APIs missing. If you wanna go and build containerized applications, Docker containers are primarily Linux-based toady. Even though we have... We just announced late last year support for Windows containers and Window Server 2016, but that's still relatively new. That's like October of last year is when that technology came out. If you've been pushing yourself in the container world, then Dot NET Core is a great solution for you today. And then, finally, with Dot NET Core, we try to solve some of the key issues that we saw customers run into with Dot NET framework. And one of the challenges that we have with Dot NET framework is it is a global, machine-wide installed platform.

24:43 SH: And the challenge of that is if your company is standardized on Dot NET 4.5, the question you might ask yourself if you install Dot NET 4.6 on your machine, that Dot NET 4.6 affects every application on that machine/server. And so if there is any compatibility problems or any bugs that we've introduced or bugs we fixed that end up breaking things in your code, you're gonna have to retest all the apps on the machine to make sure that they are actually compatible with the new version of the Dot NET framework. So one of the key things of Dot NET Core was the idea of being able to have many of these Dot NET Cores all side-by-side on the machine. And so it's not a global installed component, meaning that I could have five apps on my machine using Dot NET Core 1.0, I could have three more using Dot NET Core 1.0.3, and I could have three or four more using Dot NET Core 1.1, and none of them steps on top of each other, which means if one of the teams in your org wants to use the latest version of Dot NET Core, you can deploy that application on a server and you are guaranteed that it will not stop on any of the other applications. All the other applications can continue to use the version they are using. And so making this side-by-side thing a big piece of the platform to give our customers more control over compatibility and stuff like that is a big thing to Dot NET Core.

26:16 SH: So if those kinds of things are important to you today, then I would go port to Dot NET Core and fight through whatever I have to do with missing APIs. If you're a Dot NET framework person and you are just looking to, "Hey, when is the right time to try Dot NET Core just because it's the new thing and I wanna start trying the new thing out," that will be with the Dot NET Standard 2.0 wave. And we're actually gonna... That wave will be a bigger than just Dot NET Standard 2.0 wave. It'll be... I think we're gonna call the whole thing Dot NET Core 2, and so, in the Dot NET Core 2.0 wave, that's when, if you've been sitting on the sidelines waiting, that would be a great time to take a look at the platform because a lot of the API's that are missing in Dot NET Core today will come back, you can easily share NuGet packages across Dot NET framework, Xamarin, and Dot NET Core. And so a lot of the adoption blockers will be out of the way, but you get to keep all the... All the great tenants that are still there. You will get all the cross-platform, you will get all the side-by-side, you will get the super high performance that we did with ASP.NET Core, you get all those benefits.

27:26 EC: Excellent. Yeah, I've been trying to give people the heads up that 2017 is going to be this year of ASP.NET Core because of Dot NET Core 2.0 and Dot NET Standard 2.0. Some of that stuff was under an NDA for a while, so it's been one of those things I've had to keep under my hat until it's been made public. So it's exciting to be able to let people know this is coming and let them know that they can start writing some ASP.NET Core applications for their corporate endeavors and having all of those new benefits.

28:10 SH: So one thing that we should talk... When you talk about ASP NET Core, one thing that I think a lot of folks miss on, and maybe, as a team, we don't make enough... A big enough deal about it. ASP NET Core actually runs on the Dot NET Framework as well. So both ASP NET Core and NET Framework Core, both of them can work on Dot NET Core and they can work on the Dot NET framework. And so that was actually a design decision that was on purpose for us, because we knew when Dot NET Core first shipped, it was not gonna have the full API set that we have in Dot NET Framework. And so we actually made those technologies work on Dot NET Framework, and so if you do wanna try ASP NET Core or NET Framework Core today, you can run them against the full framework and have all the APIs that are there. So that's another option. If you wanna try it today using the full framework, you don't get the cross-platform and the side-by-side benefits, but you will get the high performance. So the same ASP.NET core that ranks number 10 in the tech and power benchmark for serving JSON will perform the same way on the Dot NET framework as well.

29:35 EC: That's an excellent tip to know. I didn't know that myself, so that's a really good way of looking at it. So if you haven't tried Dot NET Core yet, give it a shot. I've been using it quite a bit for work purposes. As most of you know, this is a podcast that's supported by Progress, which is also the makers of the Telerik UI controls. So we have support for ASP.NET Core already, so all of our 80 plus controls, UI controls for ASP.NET MVC, also work in ASP.NET Core. So I've been working a lot with that, trying to make sure that we're communicating all of that to our customers and showing people demos and how to get the ASP.NET Core up and running, and file a new project and installing things.

[chuckle]

30:31 EC: So it's been a learning year last year for me, and I've been trying to teach others on all this new stuff. So it's been a lot to keep up with, but it's been a lot of fun.

30:45 SH: That's funny you mention that. The Telerik controls are, I think, one of the things that drew me to Dot NET way back in the original Dot NET days. I remember playing with ASP.NET back when Dot NET was first shipped, and I don't remember when the Telerik controls first came out, but I just remember the awesome power I had just by dragging a couple of these controls onto my web forms applications back in those days. And you could build a slick, awesome application with a lot of functionality in no time with those controls, and so super happy that there's Core versions of those things today.

31:23 EC: Yeah. I came to the company as a customer, so I had this... The same experience as a Dot NET developer and one day I downloaded a couple third-party controls to try them out, and I found a lot of powerful options with the Telerik controls. Like you said, you drag and drop, and all of a sudden, you have got this great looking application, and immediately went to my boss and was like, "If you buy this, this is like hiring two new people."

[chuckle]

31:54 EC: And I was a lone wolf developer for years just using those tools.

32:00 SH: Same for me, I had the exact same conversation with my boss as well. It's like, "If you buy this stuff, I can do the work of five people just by myself," which was true.

32:13 EC: Yeah, and it's great stuff. We're supporting Dot NET Core and we're also supporting Angular 2, and I've been doing a lot of work on showing folks that use the Dot NET Core platform how to integrate the Angular 2 UI Controls as well. So again, more learning. It's what we do, right? Learn, learn, and learn.

[chuckle]

32:36 SH: That, to me, is what's... That's what makes Dot NET interesting and that's what makes web programming interesting to me, is... The fun for me over my time at Microsoft so far has just been... As part of the Dot NET team, we just adopt to whatever we see is happening in the developer world. So back in 2008, when we did MVC, that was because we were seeing the MVC pattern becoming very popular with Ruby on Rails. I remember a couple years later when frameworks like Angular came out, mobile applications, as the iPhone and Android phones were becoming more popular, you needed to have great support for APIs, and so I remember we built ASP NET Web API to have a platform for that. And I remember we were doing things like looking at real-time and we built a SignalR Framework on top of ASP NET to do real-time. And then we saw this shift into cross-platform and containers, and we did the open sourcing and cross-platform support for Dot NET. That's what keeps the job fresh, is the fact that the industry and the technology is always changing, and our job is to make Dot NET a great choice and a relevant choice as each of these shifts happens in our industry. That's why I love doing what we do. It's just so fun, just to... I think I'd be bored if we were still just doing the same thing that we were doing in 2007, but each of these paradigm shifts, we get to adopt the framework and the tools.

34:17 EC: Absolutely, I can't agree more. Speaking of the tools, I think we have a little bit of time left to talk about Visual Studio 2017, if you don't mind?

34:28 SH: Yeah.

34:29 EC: So what do we have to look forward to with regards to Dot NET Core and, let's say, web programming in Visual Studio 2017?

34:40 SH: So I think the biggest thing that we're doing in Visual Studio 2017 is... This is a weirdness of Dot NET Core. We actually RTM-ed Dot NET Core in June of 2016, but the tooling was never RTM-ed actually. So, right now, if you're playing with Dot NET Core, you're likely using VS 2015 and you've downloaded one of our beta tooling installers. I think it's... We're at preview three, I think, right now, for the tooling. VS 2017 will be the first Visual Studio IDE that has full Dot NET Core support baked into Visual Studio. So that's... It'll be the first one that just writes part of the installing of VS, you can actually get Dot NET Core support. It will also... As we were building Dot NET Core, we first started experimenting with a new project system that we were calling Project JSON at the time. And the reason we even got to this new project system was when we first started this effort, we're like, "Hey, how do we... " We want to make sure that... Because the technology runs cross-platform, that if you're on a Mac or you're on a Linux machine, that there's a decent developer experience. Up to this point, the only way to build Dot NET applications, for the most part, was to use Visual Studio. If you tried to edit... Hand create a Dot CSPROJ file in Notepad, I don't think you'd be very successful.

36:15 SH: And so the idea was, "Hey, we want to make building these applications so simple that the project file is just something anybody could type into a Notepad." And so this led to a file called Project JSON and a new project system, and we learned a lot from that experience. It was a great experience, but after we started working in Dot NET Standard, we realized trying to code share between a Dot NET Core project and a Xamarin project or a Dot NET Core project and a Dot NET Framework project was just super, super hard. We can make it work one way, but making it work both ways... It was easy for us to make it where a Dot NET Core project could actually use a Dot NET Framework project, but making a Dot NET Framework project that could use a Dot NET Core project just... It didn't work. And as we started looking at the problems that we're trying to solve as we're trying to solve that, it just looked insurmountable. And then the other thing that hurt us was if we're really going to go down this Project JSON path, we really would need to go make Project JSON the way you do Dot NET everywhere. So we ended up moving back to the CS project system, or the MSBuild project system, and what we wanted to do, as part of that transition, is we wanted to make sure we didn't lose any of the goodness that we learned in Project JSON.

37:43 SH: So if you play with VS 2017... I think we have RC 2 out right now, and I think RC 3 is coming pretty soon. One of the things you're gonna notice is, with Dot NET Core projects, you get a simplified CSPROJ, meaning that, basically, you'll get a CSPROJ that's just a few lines of XML. It's not full of GUIDs, it's a few lines of XML and it's very easy to hand-edit, just like Project JSON was. In fact, it's so easy to hand-edit that we actually built a feature into Visual Studio 2017 where you can right click on your project and say 'Open in the Editor', and actually hand-edit the file just like you could a Project JSON file, if you wanted to, and you'll get the same IntelliSense, you'll be able to edit your packages live. And so we tried to take all the cool benefits of Project JSON and bring them back into CSPROJ. So a couple of those things is file globbing, meaning that you don't have to list every single file on your project in your CSPROJ file. This is one of the cool benefits of Project JSON, meaning that you didn't have to do a source control merge every time you added a file. As I said, we have the same very simple package references that we had in Project JSON. They're available in the CSPROJ file as well, you can hand-edit those, you'll get IntelliSense and the RTM timeframe.

39:00 SH: We also preserved a bunch of the capabilities like being able to cross-target, being able to write a DLL and then tell the system that you want it to spit out a Dot NET Framework DLL, a Dot NET Core DLL, you can do that. And we simplified the CSPROJ file, removing all the GUIDs, removing a lot of the ceremony, making it very small and clean and easy to see, and then having the ability to edit these things in Visual Studio 2017. So you get all that with the VS 2017 wave. And that tooling will be the RTM tooling, so that's exciting. But there's also a bunch of other exciting things we've done in VS 2017 as well. One of my favorites is we have something called Live Unit Testing that we've added to VS 2017 and Live Unit Testing is... The whole premise behind it really is... Today, a lot of the development life cycle is you write a bunch of code and you run your tests. And the idea behind Live Unit Testing is as you're writing your code, tests are running all the time in the background. And so you actually will find the errors much earlier or find tests that break much earlier as the IE does this. And we've done all the right things to make sure that we run this thing out of process so it doesn't make your VS run out of memory. We do a lot of work to make sure we don't make your CPU go crazy.

40:31 SH: So we're trying to all the right things to make this not be intrusive or it shouldn't slow down your typing or anything like that, but you get a much cooler developer experience. That's a nice thing coming in the VS 2017 wave. Another one is we've completely redone the VS installer. So one of the challenges today with Visual Studio is if you just check something, the granularity is pretty big. You can't just say, "I want C# only WinForms development." You basically say, "I want Windows development," and you get a whole bunch of stuff. And so we went through the IDE and we've broken pieces up into smaller pieces, and so you have a lot more granularity and so you can install VS and put a much smaller footprint on disc. We wanted to address the problems of... When a Visual Studio update comes out, we don't want your machine to grind for an hour to putting that update on. So we've done a lot of work to make sure that when an update does happen, it'll be a very quick process. Some of that was we don't globally install a lot of the stuff anymore. So there's still some components that are globally installed, but most of it's locally installed, and we even have our own registry as a file inside of our folder with the idea of saying that, "Uninstalling or reinstalling a VS should become a much, much faster thing than it was before."

41:57 SH: So that's another wave. And there's also a ton of other investments that we've done across the product line, but I think the ones that'll affect the Dot NET folks the most are gonna be the Live Unit Testing, the Dot NET Core support, and the moving to Project JSON and the installer. I think those are all areas that people will really enjoy.

42:19 EC: And there's a VS 2017 preview available for download, correct?

42:24 SH: There is. So right now, if you go to VisualStudio.com, there'll be a preview of 2017. That's technically... It's at release candidate mode, at this point. And as I said, somewhere in mid-January... I mean mid-December, it switched to, technically, RC2 and the next wave of the RC is coming very, very quickly. Dot NET Core Support, even though the Visual Studio is in RC, we were still calling our Dot NET Core Support preview, but we're about to finally remove the preview title from the Dot NET Core Support. A lot of the reason we were still calling it preview was we just got Dot NET Core Support into the 2017 previews in mid-November, and it was the first time that we actually had done that shift from Project JSON to CSPROJ. And we knew we needed a couple of cycles of customers trying and us trying, trying the tooling, before we rip that preview label off. And so, I believe, on the next refresh of the 2017 preview, we will finally rip that band-aid off and we'll be very close to having RTM Dot NET Core tooling.

43:42 EC: And in regards to CLI tooling, or command line tooling, what type of stuff is coming down the pipe there?

43:51 SH: When it comes to CLI, first off, that's actually a design change for us. Historically, tooling for Dot NET, as I said earlier, has been primarily been a Visual Studio thing. There was not really a great way to build Dot NET applications from command line. But as you start looking at making cross-platform Dot NET, you've gotta have a great way of building these applications from command line. And so internally, as a team, we said, "Hey, what we're gonna do is we're gonna go CLI first, and so any experience that we build with tooling, we're gonna build a command line version of it first," and for the most part, what's gonna be unknown to you, when you're actually in the IDE and doing things, the IDE is out... Is running out and running the same command like tooling that you might run on a Linux or Mac machine yourself. So it allows us to write the tooling one time and share it across all the different ways you might use that tooling. But sometimes when I hear people that have seen this demo of Dot NET Core, they're like, "Man, you guys are all going command line," and, "What about Visual Studio," and the majority of our developers use Visual Studio and they use it for the productivity, and so we're not deemphasizing the visual tooling and Visual Studio at all, because we're focusing on some of the command line stuff. We're going to give you all the ways of doing stuff in VS, with all the high productivity that we've always give you.

45:16 SH: But we want to enable the command line for people that are running on platforms other than Windows. And with that, we should also talk about something else. We should talk about... We just announced in November, as well, Visual Studio for Mac. And that's a rebrand of Xamarin Studio, Xamarin Studio being the IDE that Xamarin had built for building Xamarin-based applications on iOS and Android. What we've done with Visual Studio for Mac is we've gone and taken the Dot NET Core workloads and we've dropped those into Xamarin Studio, or now Visual Studio for Mac. And the idea here is if you're on a Mac, now you'll have an editor or a full IDE experience for Dot NET core as well. You can build applications, both console class library and ASP NET applications. It's early preview at this point, but we want to have the same kinds of parity that we have with Visual Studios. We'd love to have the publish to cloud that we have in Visual Studio, to publish the containers that we have in Visual Studio. We wanna have the same templates that we have in Visual Studio. So you're gonna see this continue to grow over the next couple of months, but the main idea there is, from that one IDE, you can build an iOS, an Android application, and you can build the ASP NET Core back in for that application all in the same IDE. And so you're just going to continue to see that IDE grow and share the same capabilities that we have in Visual Studio for Dot NET Core applications.

46:54 EC: Visual Studio has to be, by far, my favorite Microsoft product. I've used it since I've started development. I've tried other things and there is nothing more comfortable for me to program in than Visual Studio, so it's nice to see that it's making its way to Mac through the rebranding of Xamarin Studio. And it's also nice to see Visual Studio code coming out and I've seen a lot of adoption on Visual Studio code from folks that swore they'd never use Visual Studio.

[chuckle]

47:30 EC: But now they're using Visual Studio code and they're getting an idea of what IntelliSense is like, and good code completion is like, and it's fun to see those folks enjoying those benefits that I've had for years.

47:46 SH: Yeah. It's kind of... To me, it's part of the new Microsoft. The new Microsoft, I think of... We have Dot NET Core, which is cross-platform, and we've got Visual Studio Code, a great editor that runs on Windows, Mac, and Linux. It's just part of that cool wave of... I think our motto used to be all about doing stuff for Windows, and now our motto is just, "Make awesome software." Some of my favorite Microsoft applications now are... I'm a big fan of OneNote, and I love the fact that I can run OneNote on the web, I can run it on my iOS device, and I can run it on Windows. It's just part of this industry shift that I'm really enjoying. But VS Code is awesome, and we also wanna make sure that Dot NET works great in VS Code, and so we have great support there for IntelliSense, we have the bucking support in VS Code, and in the future, you'll see us have support for probably even doing remote debugging into the cloud with VS Code as well.

48:49 EC: So Scott, we've covered a lot today. We've covered Dot NET standard, and ASP.NET Core, and Dot NET Core, Visual Studio, and the other amazing tools that are coming this year. So I wish you an excellent 2017. I think it's gonna be a great year for all Dot NET developers. I really appreciate you making time for the show.

49:16 SH: Yeah. I am super excited to be on the show and I'm glad we had a chat, and I'd love to do it again.

49:22 EC: Is there anything that... Any links that you'd like to share or ways to get in touch with you online, Twitter, any of those things?

49:32 SH: I think the big things I'd wanna point people to is go to dot.net, that's the homepage for Dot NET, and if you wanna find me, I'm on Twitter. I am @cool, C-O-O-L, csh.

49:49 EC: Awesome, and I have a couple events coming up as well. I'll be in Arizona at the end of the month, this month, January 23rd, for an event called 'A Day With Scott Guthrie'. So that should be a fun event. If you're in the Phoenix, Arizona area, stop by and see us. Grab a ticket for the event and come by. If you're looking for updates on Dot NET, we are blogging all the time on developer.telerik.com. You'll find blogs by me on ASP.NET Core and Angular 2. And Sam Basu is always on there talking about Xamarin, so you can come get your fill of Dot NET on developer.telerik.com. You'll find the podcast there as well, and we also have a Kendo UI Webinar on January 24th, so make sure you tune into that if you have time. We'd appreciate it. You can sign up for the webinar on developer.telerik.com as well. We'll include links for everything in the show notes. Again, good luck with 2017, Scott, and we appreciate you being on.

51:02 SH: Yeah. Well, I'm gonna join you at the event in Phoenix as well.

51:06 EC: Awesome. Look forward to meeting you in person.

51:10 SH: So, I will see you there.

51:11 EC: Alright. Take care and safe travels.

51:13 SH: Thanks. See you.

[music]