.NET Core goals

- [Narrator] In order to accomplishthe cross-platform support, Microsoft was essentiallygoing to have to rewrite significant portionsof .NET, ASP.NET, and NET Framework.So, this is a perfect opportunityto make additional changes to platform.So let's look at those goals.Cross-platform support, we've already discussed performance,portable class libraries via .NET Standard,different types of deployment methods,also modular deployment of .NET Core itself,full command-line support, open source,interopping with .NET Framework,that's the full .NET Framework,and also having telemetry around the Visual Studio tooling.

Let's talk about these in detail.I've already mentioned that quite a bit of the impetusfor .NET Core was a desire to be able to run cross-platformand .NET Core and ASP.NET Core delivers.So you can deploy to Windows, Linux, or Mac,and more and more distributionsare coming online with every releaseplus additional versions, for example Windows 2016,has recently come online.You can also develop on multiple platformsand not just Windows.

So if you're on Linux or Mac, you can use Visual Studio Codeand there's also Visual Studio for the Macfor building .NET Core or Xamarin-based applications.This also enables containerization.This simplifies deployment becauseonce I have it working on quote-unquote my machine,in the container, I don't have to worry aboutenvironmental configuration or deployment processesto move it to integration or production.I just move the container.

And docker support is built into Visual Studio 2017.Another key goal of the team was performance.If we think of where ASP.NET came from,web forms and MVC, there's a lot of legacy code out thereand performance wasn't necessarily one of the key goals,but with .NET Core, it is one of the key goals.One way ASP.NET Core gains a lot of performanceis by using Kestrel.Kestrel is an open-source, cross-platform web serverbased on libuv, a very popular open-source server,and using Kestrel ASP.NET performs in the top tierof the standard benchmark tests.

And with every release, they are squeezing moreand more performance out of .NET Core and ASP.NET.So Portable Class Libraries,the name has been around for a while.We had those with mobile development, Silverlight,but it wasn't necessarily well-executedand there were different profiles and they were numberedand there was some confusion around it..NET Standard significantly cleans that up.It is a formal specification for all .NET runtimes.

There are three key scenarios that are being targetedwith .NET Standard.First and foremost is have a uniform setof base class library APIs, independent of workload.You can produce libraries that are usableacross all .NET implementations.And hopefully, we can reduce conditional compilation.To summon up any assembly targeting a .NET Standard versionis going to be usable from any other assemblytargeting the same version.

There are two different deployment models,portable and stand-alone, and now the portable part of thatis not to be confused with Portable Class Libraries.The .NET Core supports true side-by-side installation.Now, this helps us in a multitude of ways.If I'm running 1.0.0and that's what my application is dependent on,and I install 1.0.1 or 1.1or 2.0 or some other version,it doesn't remove the existing version.

So I can still run my applicationsregardless of what other versions get installed.Portable deployments rely on the framework being installedand this is what we expectin the full .NET Framework, right?.NET has to be installed, we're going to just put out ourlibraries and assemblies that we needand the application will run.Stand-alone deployments containthe required application files,but also the required framework files..NET Core and all of the Core frameworks,ASP.NET Core and EF Core, are delivered as NuGet packagesinstead of having one giant MSIor file that is .NET.

Now, truth be told, we all knowthat .NET, the full .NET Framework,is not one giant file, but this is much more granular.Each assembly in a .NET Core Frameworkhas its own package and the package namesmatch the assembly names.Package versions will use semantic versioning,which is pretty much what everybody elseon the Internet is doing.And this modular deployment modelprovides faster releases of security updates,bug fixes, et cetera.

Microsoft and the community can just releasethat specific package with the fix,and not have to wait to releasethe entire new .NET Framework.Microsoft has not forgotten about the enterprise.You still can just install .NET Core.You don't have to worry about which packagesI need to have on my machine,so there are distributions setupwhere you can just fire and forget.Full command line support is alsoa very high priority for .NET Core.

There is a very good reason for this:not everybody developing .NET Core applicationswill be using Visual Studio.So if they put all the effort into Visual Studio toolingand the command line lagged behind,then there'd be a lot of developers left out in the cold.Because of this, however, the Visual Studio toolingtypically lags the support of the command line.And we'll see this throughout the course,there's a few things that we have to still do by handthat aren't supported automatically through Visual Studio.

The command line of course works on all platformsand you're seeing more and more templates,for example Yeoman templates are now availableto speed development..NET Core is truly open-source, not just source open.All of the code and all of the documentationare all truly open-source.A matter of fact, for the 1.0 version,there were over 10,000 contributorsthat were non-Microsoft employees.And this is really helping drive adoptionin traditionally non-Microsoftor not .NET-friendly organizations,knowing that the entire framework is open-source.

With .NET Core 2, we get interoperabilitywith the full .NET Framework.So that means that .NET Framework librariescan be referenced from .NET Standard libraries.Of course there's limitations.You can only use types supported by .NET Standard,and the asterisk is there because it might work,it might not, if you go outside of the .NET Standard window.Microsoft doesn't recommend it,but if you find something that is workingand you effectively test it,you can kind of break the rules.

That gap of what you can use and cannot useis shrinking with every release..NET Standard 2.0 implements over 32,000 APIsfrom the .NET Framework.Chances are what you need will already be in there.If not, it'll probably be coming soon.And finally, I want to talk aboutthe .NET Core tools telemetry.So this is not the application,this is not the framework, this has no bearingwhatsoever on anything that you write.

This is literally Visual Studio tooling telemetry.It's completely anonymous and aggregated for useby Microsoft and the .NET Core community engineers,and it enables Microsoft to make surethat they are building and revampingthe right things within Visual Studio,and not spending a whole bunch of development cycleson features that nobody uses.If you really don't want to be part of that,you can opt out by setting the .NET_CLI_TELEMETRY_OPTOUTenvironment variable, however,I highly recommend not opting outbecause it just makes Visual Studio better.

Resume Transcript Auto-Scroll

Author

Released

1/26/2018

Navigating all of the new features in each release of ASP.NET Core can be challenging. In this project-based course, Phil Japikse helps to simplify this process by laying out the new features in ASP.NET Core 1.0, 1.1, and 2.0, and acquainting you with the benefits of each. Phil begins by providing a general overview of .NET Core and discussing migration considerations. He then dives into ASP.NET Core 1.0, discussing the updated project structure, new environmental awareness, view components, and other new features. He then moves on to discuss ASP.NET Core 1.0 and ASP.NET Core 1.1, diving into helpful new features and functionality present in each iteration of the web framework.