Getting Started
You can find installation and setup instructions for Mac, Linux, and Windows as well as additional documentation at http://docs.asp.net.
Open Source Stack
One of the biggest changes to ASP.NET and the .NET Framework, the runtime used by ASP.NET is that ASP.NET Core 1.0 and .NET Core are open-source projects, meaning the pieces of the stack, from collections classes to MVC to the underlying runtime execution environment, are all open source. The benefits are obvious in that the community is able to contribute to the stack, either in the form of new features or bug fixes, or even using the source code to help debug framework classes.
Cross-platform ASP.NET Apps
For developers evaluating a containerized architecture, the biggest fundamental change for ASP.NET is that ASP.NET Web and Console applications can run on either a Linux or Windows Docker host. Previously, ASP.NET applications required the full .NET Framework to be installed, and of course could only work on Windows. Every ASP.NET Core 1.0 project now explicitly declares what frameworks it supports, and you can support both the full .NET Framework and the .NET Core in a single project.
.NET Core
.NET Core is a lightweight, cross-platform, modular version of the full .NET Framework that includes CoreFX, a set of .NET libraries (collections, threading, data access, common data types, and so on), and the CoreCLR, the underlying runtime and execution environment that handles assembly loading, garbage collection, type safety, and other features. One of the key benefits of .NET Core’s modularity is that all your app’s dependencies, including the CoreCLR, can be packaged and distributed as standalone items. That means you no longer have to install the full .NET Framework on a server to run ASP.NET apps. You can find more information on .NET Core at http://bit.ly/aspdotnetcore.
.NET Core Side-by-Side Support
.NET Core’s architecture also alleviates one of the most common difficulties reported by customers, where their server environment is locked into a specific version of the .NET Framework that cannot be upgraded because of the potential to break legacy apps. With .NET Core, all the dependencies of the app are included in the app itself. This enables you to have three different apps that reference three different versions of the Core CLR without causing side-by-side compatibility issues. Your legacy apps can continue to use an older version of the Core CLR without restricting your newer apps to an outdated version of the Core CLR.
Application Dependencies using project.json
Similar to the NodeJS model, ASP.NET provides a new configuration file named project.json that lives in the root of your project folder. Project.json describes a project’s dependencies, including target frameworks as discussed in the section on the cross-platform ASP.NET apps, NuGet libraries that your project depends on, how and what to include and exclude when building for output, command line tools like scaffolding to run, and pre-compilation tasks for Javascript and CSS for your project. The key takeaway is that it’s as easy as updating a JSON file to target a new framework or add a new NuGet library, and that you can do this directly from any text editor, without the need to use Visual Studio.
Everything is a NuGet Package
.NET developers have been using NuGet, the .NET package manager for reusable libraries, for years to easily update, distribute, and discover libraries. .NET Core takes this further by requiring that all.NET components be packaged, distributed, and updated through NuGet. Previously, developers and administrators had to wait about 12 to 18 months for new functionality in the .NET Framework to be available. Now, because .NET Core libraries ship as NuGet packages, you can instantly add or update the libraries or the underlying runtime your application uses. For example, the code snippet here, from the dependencies section of the project.json file shows a list of dependencies. Each line item represents a NuGet package based on the namespace and the corresponding version of that library, which at the time of this writing is Release Candidate 1 (rc1).
"dependencies": {
"Microsoft.AspNet.Mvc": "6.0.0-rc1-final",
"Microsoft.AspNet.Server.Kestrel": "1.0.0-rc1-final",
"Microsoft.AspNet.StaticFiles": "1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.FileProviderExtensions":
"1.0.0-rc1-final",
"Microsoft.Extensions.Configuration.Json": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging": "1.0.0-rc1-final",
"Microsoft.Extensions.Logging.Console": "1.0.0-rc1-final"
...
It isn’t just the .NET Framework that is packaged using NuGet; any class library that you build for .NET Core is also packaged and distributed as a NuGet library. In fact, if you use Visual Studio’s Add Reference... feature to reference a class library in your solution, in ASP.NET Core 1.0, what it does is add a new dependency to the list of dependencies in your project.json file.
Cloud-ready Environment-based Configuration
Application configuration, stored as key/value pairs like service URLs, connection strings, application constants, or other configuration settings, are now based on a flexible cascading configuration system, with providers for JSON, ini files, and environment variables. The reason this is important for containerized solutions is that if you remember from earlier chapters, when we create a Docker image we are copying or “hard-coding” the contents of our web project into that image. But what happens if there are some things in your project, like a database connection string, that you really don’t want to hard-code in? Docker solves this by providing a way to dynamically inject environment variables into a container when it’s created. ASP.NET’s support for environment variables makes this perfect in that we can hardcode a connection string in the image and dynamically replace the value when we create the container in a development, staging, or production environment.
To set up a project’s configuration, as in previous versions of ASP.NET, you can use the startup.cs file to add code to setup the configuration services you want to use in the Startup constructor. The example below shows adding two configuration services. The first one reads configuration settings from a file named config.json. The second reads configuration settings using environment variables. The order of configuration providers matters as the order dictates the precedence rules to overwrite the same configuration found in multiple providers. In the list below, this means that environment variables will take precedence and overwrite any matching configuration in the config.json file.
public Startup()
{
Configuration = new Configuration()
.AddJsonFile("config.json")
.AddEnvironmentVariables();
} ...
In the sample config.json file below, notice that you can go beyond just the key/value pair and build a set of nested configuration settings like the ConnectionStrings section that includes a child database connection string.
{
"AppSettings": {
"SiteTitle": "My Website"
},
"ConnectionStrings": {
"SqlDbConnection":
"Server=(localdb)\mssqllocaldb;Database=Products;Trusted_
Connection=True;MultipleActiveResultSets=true"
}
}
To load the connection string, you can then just use the Configuration object that is created in the Startup constructor and pass in a string that follows the nested hierarchy for the configuration setting as shown below.
var conn =
Configuration.Get<string>(["ConnectionStrings:SqlDbConnection");
You definitely don’t want to add a production database string to source control for the production environment, so you instead set the connection string using an environment variable that is set when a Docker container is created. You can see an example of using ASP.NET and Environment variables in a Docker container in Chapter 4, “Setting Up Your Development Environment,” or refer to Chapter 6, “DevOps and Continuous Delivery” to read about more advanced options for handling environment configuration changes using services like Consul or Zookeeper.
Command-line Driven
ASP.NET is also command-line driven, meaning that common tasks, from scaffolding to build and packaging, to deployment, can be done from either the command line or Visual Studio. Doing this also enables you to use your favorite code editor, including cross-platform code editors for ASP.NET development, instead of requiring Visual Studio for development. At the time of this writing, the .NET and ASP.NET teams are rebranding their command line tools from “DNX” (DotNet eXecution) to “dotnet.” The .NET Core Command Line Interface (CLI) includes the following commands for managing .NET projects:
• Compile: Compiles your project.
• New: Creates a new “Hello World” .NET console project template.
• Publish: Prepares your project for deployment by downloading any dependencies, including the .NET Core Framework that the project requires to run.
• Restore: Restores NuGet dependencies for your project.
• Run: Compiles and runs your project.
Unification of ASP.NET MVC and Web API
In previous versions of ASP.NET, ASP.NET MVC 5 and Web API 2 had similar but different implementations for things like controllers, actions, filters, model binding, routing, and more. In ASP.NET Core 1.0, MVC and Web API have been unified into MVC, which provides a single way to handle routing, controllers, model binding, and so forth.
Dependency Injection as a First Class Citizen
Dependency Injection, or DI for short, is used to easily swap out project-wide components in a standard way. Let’s say you have a data access library. Rather than create a concrete class for that data access library, you can create an interface for data access and swap out providers. For instance, you could do this to use a mock library for local development versus a real database configured to use SQL Server, or to change to a wholly different data provider, such as using MongoDB by simply implementing the interface contract and changing the provider in the startup.cs file. As discussed in Chapter 6, dependency injection becomes especially important for testing dependencies between different microservices.
Cross-platform Data & Nonrelational Data with Entity Framework
As data access is one of the most popular uses for ASP.NET applications running on Linux or Mac, being able to access non-Windows databases like MySQL, PostgreSQL, or SQLite is critical. The Entity Framework team is working with the community to provide drivers that enable cross-platform data access. Going further, EF is also working on support for nonrelational data stores like NoSQL stores, including MongoDB, Azure Table Storage, and more. You can find the current status of EF drivers at http://bit.ly/aspefdb.
RAD Development using Roslyn
For developers, one of the most-loved improvements is that ASP.NET has a dynamic compilation system where you no longer need to build/compile your source code. Instead, ASP.NET Core 1.0 will dynamically compile your source code using “Roslyn,” the .NET Compiler platform. What this means for a developer is that they can hit F5 to run their app, switch to source code to make a change, save the code changes, and refresh the browser to see those changes instantly. That’s right, no need to stop the debugger, click Build, and then F5 again!
Cross-platform Web Server
Kestrel (https://github.com/aspnet/KestrelHttpServer) is the name of ASP.NET’s open-source cross-platform (Windows, Mac, and Linux) web server, based on libuv (libuv.org), an asynchronous IO library. Kestrel is packaged as a NuGet library and can easily be run on the command line to listen and respond to web requests from a specified port (default 5004). IIS, the built-in Windows web server, is still available for Windows hosting, but for Mac or Linux you must use Kestrel for handling web requests.
Cross-platform Console Applications
One of the most hidden features of ASP.NET Core 1.0 is the added support for console applications which are designed to run on Linux, Mac, and Windows. Console applications make it easy to build system services or “headless” processes that interact with the underlying Linux, Mac, or Windows operating system. .NET developers now have an incredibly easy way to build their own or to reuse any existing Linux-based command-line-driven tools like FFmpeg for video manipulation, network tools like Nmap, and more by calling them from a cross-platform console application.
What’s Not Included?
It’s important to note what’s not possible with ASP.NET Core 1.0. In particular, ASP.NET Web Forms is not part of ASP.NET Core 1.0, and having it will still require the full .NET Framework installation. While ASP.NET 4 apps will not run on Linux, you can still run them Dockerized within a Windows Server 2015 Container with the full .NET Framework installed.