This section covers the goals of .NET Core.
- [Narrator] In order to accomplish the cross-platform support, Microsoft was essentially going to have to rewrite significant portions of .NET, ASP.NET, and NET Framework. So, this is a perfect opportunity to 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 impetus for .NET Core was a desire to be able to run cross-platform and .NET Core and ASP.NET Core delivers. So you can deploy to Windows, Linux, or Mac, and more and more distributions are coming online with every release plus additional versions, for example Windows 2016, has recently come online. You can also develop on multiple platforms and not just Windows.
So if you're on Linux or Mac, you can use Visual Studio Code and there's also Visual Studio for the Mac for building .NET Core or Xamarin-based applications. This also enables containerization. This simplifies deployment because once I have it working on quote-unquote my machine, in the container, I don't have to worry about environmental configuration or deployment processes to 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 there and 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 performance is by using Kestrel. Kestrel is an open-source, cross-platform web server based on libuv, a very popular open-source server, and using Kestrel ASP.NET performs in the top tier of the standard benchmark tests.
And with every release, they are squeezing more and 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-executed and there were different profiles and they were numbered and 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 targeted with .NET Standard. First and foremost is have a uniform set of base class library APIs, independent of workload. You can produce libraries that are usable across all .NET implementations. And hopefully, we can reduce conditional compilation. To summon up any assembly targeting a .NET Standard version is going to be usable from any other assembly targeting the same version.
There are two different deployment models, portable and stand-alone, and now the portable part of that is 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.0 and that's what my application is dependent on, and I install 1.0.1 or 1.1 or 2.0 or some other version, it doesn't remove the existing version.
So I can still run my applications regardless of what other versions get installed. Portable deployments rely on the framework being installed and this is what we expect in the full .NET Framework, right? .NET has to be installed, we're going to just put out our libraries and assemblies that we need and the application will run. Stand-alone deployments contain the 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 packages instead of having one giant MSI or file that is .NET.
Now, truth be told, we all know that .NET, the full .NET Framework, is not one giant file, but this is much more granular. Each assembly in a .NET Core Framework has its own package and the package names match the assembly names. Package versions will use semantic versioning, which is pretty much what everybody else on the Internet is doing. And this modular deployment model provides faster releases of security updates, bug fixes, et cetera.
Microsoft and the community can just release that specific package with the fix, and not have to wait to release the 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 packages I need to have on my machine, so there are distributions setup where you can just fire and forget. Full command line support is also a very high priority for .NET Core.
There is a very good reason for this: not everybody developing .NET Core applications will be using Visual Studio. So if they put all the effort into Visual Studio tooling and 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 tooling typically 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 hand that aren't supported automatically through Visual Studio.
The command line of course works on all platforms and you're seeing more and more templates, for example Yeoman templates are now available to speed development. .NET Core is truly open-source, not just source open. All of the code and all of the documentation are all truly open-source. A matter of fact, for the 1.0 version, there were over 10,000 contributors that were non-Microsoft employees. And this is really helping drive adoption in traditionally non-Microsoft or not .NET-friendly organizations, knowing that the entire framework is open-source.
With .NET Core 2, we get interoperability with the full .NET Framework. So that means that .NET Framework libraries can 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 working and you effectively test it, you can kind of break the rules.
That gap of what you can use and cannot use is shrinking with every release. .NET Standard 2.0 implements over 32,000 APIs from 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 about the .NET Core tools telemetry. So this is not the application, this is not the framework, this has no bearing whatsoever on anything that you write.
This is literally Visual Studio tooling telemetry. It's completely anonymous and aggregated for use by Microsoft and the .NET Core community engineers, and it enables Microsoft to make sure that they are building and revamping the right things within Visual Studio, and not spending a whole bunch of development cycles on 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_OPTOUT environment variable, however, I highly recommend not opting out because it just makes Visual Studio better.
- Running and debugging ASP.NET Core applications
- Pros and cons of migrating existing applications to ASP.NET Core.
- Built-in dependency injection
- Environment awareness and app configuration
- Web host configuration and SSL
- View components invoked as tag helpers
- Configuration and logging
- Using Razor Pages