Explore the new, cross-platform .NET Core 1.0

Speaker: Richard Lander

There are solutions for cloud, desktop and mobile. There are tools to developer for these platforms. There are commonalities packed into a library.

.NET Core

It is cross platform (Windows, Linux and macOS), fast (8x faster than Node), lightweight and open-source (50% of .NET community contributions).

TechEmpower Framework Benchmarks – techempower.com/benchmarks

Asp.NET Core is for the first time in the benchmarks and it landed in the top 10.

The product has:

  • Two different distributions: Runtime (what you need to run the app) and SDK (tools you need to do development).
  • Two ways of deploying the runtime: globally installing it or deploy it with the app.
  • Two major workloads: web with Asp.Net and console apps and tools.
  • Developer experiences: Visual Studio, Visual Studio Code.
  • Chip support: Intel, ARM.
  • Two isolation models: Bare Metal, Containers. Strong relationship with Docker Corp.
    • docker.com/r/Microsoft/dotnet/

On the API side, feedback was that there are not enough APIs. People want to take existing apps and take it to .Net Core but there are not enough APIs. .Net Core 2.0 will change the game with almost double of APIs.

redhatloves.net

.NET Core vs. .NET Framework

Both supports C# and F#. .NET Framework comes with Windows, .NET Core does not. .NET Core installs side-by-side, cross platform and open-source, works on Nano, doesnโ€™t yet support VB.

Differences in the Csproj file, like TargetFramework, Sdk. More tooling required for building a web app, like PackageReference which is a new model where everything is in one file and no file location.

Commandline tools in the .NET Core SDK, like:

  • dotnet new console
  • dotnet restore
  • dotnet build
  • dotnet run (not encouraged in production because it runs MSBuild)
  • dotnet test (MSTest, NUnit, XUnit)
  • dotnet publish
  • dotnet pack

.NET Core in action

In Visual Studio:

  1. Create new console app with .NET Core
  2. Add Nuget package
    1. Nuget and SDKs separated in the project in the Solution Explorer
  3. Add package reference, Nuget package gets added
    1. Edit csproj opens without having to unload the project

In the command line:

  1. dotnet new console
  2. dotnet new classlib
  3. dotnet new xunit
  4. dotnet new sln
  5. dotnet sln add /app.csproj
  6. dotnet sln add โ€ฆ
  7. dotnet restore
  8. dotnet build
  9. code .
  10. dotnet add reference
  11. Write code
  12. dotnet restore
  13. Write tests
  14. dotnet test

Deployment

For development you install the SDK, typically globally via native installer. It includes the tools and the runtime. You can also download the product as a zip and deploy it to a private location on your box if you want to be unaffected by anything.

All apps can share the same .NET Core Runtime that is globally installed, frapework-dependent app deployment, useful for performance. Or you can package the .NET Core with you app, self contained app deployment, each app has its private runtime and are launched as executables but with this approach it uses more space.

You can publish debug or release, debug is default.

Updates are shipped 1/quarter and are installed centrally, framework-dependent apps roll forward and self-contained apps must be republished.

Self contained apps are mostly a publishing concern. You need to add one extra line in the csproj because the project file must contain one or more runtime IDs, RuntimeIdentifiers.

Asp.NET Core

Everything has been broken doen into layers and you can decide which layers you want to opt into, like Middleware, Configuration, Logging, Dependency Injection.

.NET Standard Library

One library to rule them all. Easier to reuse code across all platforms. This seems similar to PCLs but they are quite different. You can distribute PCLs as a .NET Standard Library.