Page 26 - MSDN Magazine, November 2018

the .NET CLI installation there are two components that really contribute to this. The first component is the shared runtime, which is a redistributable version of the .NET Core runtime and is consumed by the CLI and end users. The second component is the shared host, which is responsible for consuming the DLL that’s generated as part the publish process. The shared host is a generic apphost that allows any .NET Core library (DLL), to be executed as an application. When “dotnet run my.dll” is executed, my.dll is being hosted inside of this shared host. When the SCD application is packaged, what’s happening is that the shared runtime, the shared host, and the application DLL are placed together in an executable package, an .exe for Windows, or an appropriate executable file for Linux and macOS. The actual documentation for this design can be found in the .NET CLI repository at bit.ly/2QCgZIp.
Runtime Identifiers
RIDs indicate the supported platforms for creating self-contained deployments for platforms other than Windows. For example, Windows 10 supports x86, x64, ARM and ARM64. Support for ARM addresses Windows 10 Internet of Things (IoT) devices. On Linux, only x64 is supported, with the following distributions: Ubuntu, RedHat, CentOS, Fedora, Debian, Gentoo, OpenSuse, Oracle, Tizen and LinuxMint. In macOS, versions 10.10 through 10.13 are supported. Finally, Android is supported in .NET Core 2.0 or later, which also introduces a portable RID that will build all options for a particular target group. More information can be found in the RID catalog located at bit.ly/2PKXRXi.
CoreRT Deployments
In addition to FDD and SCD, a third option being worked on at Microsoft, called CoreRT, offers the ability to generate native binaries from .NET Core-based code. CoreRT performs ahead- of-time (AoT) compilation using the CoreCLR just-in-time (JIT) compiler. This allows .NET Core code to produce both single executables and libraries that can be consumed by other languages like C++. CoreRT lets .NET developers create libraries and exe- cutables that are native to the targeted platform, providing a wider reach for the .NET platform.
Getting started with CoreRT is as simple as adding a NuGet package to a project. Inside the sample project I’ve been working with, I simply run the following command:
> dotnet new nuget
With the nuget.config file added, I then call to the .NET MyGet feed using the following lines:
<add key="dotnet-core" value="https://dotnet.myget.org/F/dotnet-core/api/v3/index.json"/>
<add key="nuget.org"
value="https://api.nuget.org/v3/index.json" protocolVersion="3"/>
Next, I add the CoreRT NuGet package, like so:
> dotnet add package Microsoft.DotNet.ILCompiler -v 1.0.0-alpha-*
And then I run publish, passing in the platform RID, as shown here:
> dotnet publish -r win-x64
Finally, I can test the application as a natively compiled appli- cation. The application is created in a folder called native and is roughly 6KB in size, which is close to the size of the FDD appli- cation and doesn’t require any runtime to be shipped with it, as it would using SCD.
The pros of CoreRT are native compilation to a single native binary, with dependencies included, for each target. Execution is faster, because JIT compilation isn’t required, and the application should have faster throughput due to compiler optimizations for each target.
The cons are that the application must be compiled for each tar- get platform, which needs to be selected in advance. There’s also, for now, the small matter of CoreRT being in pre-release stage.
CoreRT applications work very similarly to how SCD applica- tions work. There’s a small native execution engine, the CoreRT native runtime, which provides runtime services like garbage collection that gets compiled with the application into a single native package. And there’s a managed portion of CoreRT that’s written in C#. The .NET Core application is first compiled with the Roslyn Compiler, then the application, along with CoreRT and CoreFX, is passed through an intermediate language compiler that analyzes the dependencies and shakes the tree so only the absolute minimum number of libraries will be compiled into native code using a compiler based on LLVM. Finally, a linker is used to link the CoreRT native runtime with the compiled native output from the application to produce the final native executable. Matt Warren has an awesome blog post about the subject at bit.ly/2NRS5pj, and of course the GitHub repository for CoreRT has links to parts of the design at github.com/dotnet/corert.
Wrapping Up
SCD offers one big advantage over FDD—it doesn’t require the user to install any additional software to support an installed application. I’m used to just building applications for Windows where the .NET framework is typically already available. But when .NET Framework isn’t installed, or the wrong version is installed, it can create bad experiences for users.
.NET Core promises to change this, as it will require users to install not only the runtime but a specific version of the runtime to support your application. SCDs may produce larger applications (and, therefore, larger downloads) because the runtime is packaged with the application, but this allows the user to install the applica- tion without having to worry about additional requirements. For users outside of Windows, such as those for macOS and Linux, SCD is the common experience that users expect, and it will help with the adoption. In environments that are controlled by the developer or organization, this becomes less of an issue, and FDD would likely have the advantage.
CoreRT—compile to native—deployments are still in the very early stages. These deployments will offer many of the advantages of both FDD and SCD, with no framework installation required and compact application files. However, there’s still a journey ahead to make this approach functional. n
Jamie PhilliPs is a senior software development engineer at SentryOne, located in East Tennessee. He’s been working with .NET since 2007 and has a keen inter- est in DevOps and the cloud. He can be found on Twitter: @phillipsj73, his blog at phillipsj.net and GitHub as phillipsj.
Thanks to the following technical experts for reviewing this article: Andrew Hall (Microsoft), Daniel Oliver, Cameron Presley (SentryOne)
20 msdn magazine
.NET Core