A recent post by Scott Hanselman triggered my curiosity about the new dotnet
Command Line Interface (CLI) tool for .NET Core, which aims to be a “cross-platform general purpose managed framework”. In this post I present my first look on using .NET Core and the dotnet
tool on OS X.
Installation
For OS X, the recommended installation procedure is to use the “official PKG”. Unfortunately, this PKG doesn’t seem to be signed so trying to run it directly from the browser will result in an error. The workaround is use Finder to locate the downloaded file and then select “Open” on the file. Notice that this PKG requires administrative privileges to run, so proceed at your own risk (the .NET Core home page uses a https
URI and the PKG is hosted on Azure Blob Storage, also using HTTPS – https://dotnetcli.blob.core.windows.net/dotnet/dev/Installers/Latest/dotnet-osx-x64.latest.pkg
).
After installation, the dotnet
tool will be available on your shell.
~ pedro$ which dotnet
/usr/local/bin/dotnet
I confess that I was expecting the recommended installation procedure to use homebrew instead of a downloaded PKG.
Creating the application
To create an application we start by making an empty folder (e.g. HelloDotNet
) and then run dotnet new
on it.
dotnet pedro$ mkdir HelloDotNet
dotnet pedro$ cd HelloDotNet
HelloDotNet pedro$ dotnet new
Created new project in /Users/pedro/code/dotnet/HelloDotNet.
This new
command creates three new files in the current folder.
HelloDotNet pedro$ tree .
.
├── NuGet.Config
├── Program.cs
└── project.json
0 directories, 3 files
The first one, NuGet.Config
is an XML file containing the NuGet package sources, namely the http://www.myget.org
feed containing .NET Core.
<?xml version="1.0" encoding="utf-8"?>
<configuration>
<packageSources>
<!--To inherit the global NuGet package sources remove the <clear/> line below -->
<clear />
<add key="dotnet-core" value="https://www.myget.org/F/dotnet-core/api/v3/index.json" />
<add key="api.nuget.org" value="https://api.nuget.org/v3/index.json" />
</packageSources>
</configuration>
The second one is a C# source file containing the classical static void Main(string[] args)
application entry point.
HelloDotNet pedro$ cat Program.cs
using System;
namespace ConsoleApplication
{
public class Program
{
public static void Main(string[] args)
{
Console.WriteLine(&amp;amp;amp;quot;Hello World!&amp;amp;amp;quot;);
}
}
}
Finally, the third file is the project.json
containing the project definitions, such as compilation options and library dependencies.
HelloDotNet pedro$ cat project.json
{
"version": "1.0.0-*",
"compilationOptions": {
"emitEntryPoint": true
},
"dependencies": {
"NETStandard.Library": "1.0.0-rc2-23616"
},
"frameworks": {
"dnxcore50": { }
}
}
Resolving dependencies
The next step is to ensure all dependencies required by our project are available. For that we use the restore
command.
HelloDotNet pedro$ dotnet restore
Microsoft .NET Development Utility CoreClr-x64-1.0.0-rc1-16231
GET https://www.myget.org/F/dotnet-core/api/v3/index.json
OK https://www.myget.org/F/dotnet-core/api/v3/index.json 778ms
GET https://api.nuget.org/v3/index.json
...
Restore complete, 40937ms elapsed
NuGet Config files used:
/Users/pedro/code/dotnet/HelloDotNet/nuget.config
Feeds used:
https://www.myget.org/F/dotnet-core/api/v3/flatcontainer/
https://api.nuget.org/v3-flatcontainer/
Installed:
69 package(s) to /Users/pedro/.dnx/packages
After figuratively downloading almost half of the Internet, or 69 packages to be more precise, the restore process ends stating that the required dependencies where installed at ~/.dnx/packages
.
Notice the dnx
in the path, which shows the DNX heritage of the dotnet
tool. I presume this names will change before the RTM version. Notice also that the only thing added to the current folder is the project.lock.json
containing the complete dependency graph created by the restore process based on the direct dependencies.
HelloDotNet pedro$ tree .
.
├── NuGet.Config
├── Program.cs
├── project.json
└── project.lock.json
0 directories, 4 files
Namely, no dependencies where copied to the local folder.
Instead the global ~/.dnx/packages/
repository is used.
Running the application
After changing the greetings message to Hello dotnet
we can run the application using the run
command.
HelloDotNet pedro$ dotnet run
Hello dotnet!
Looking again into the current folder we notice that not extra files where created when running the application.
<del>
HelloDotNet pedro$ tree .
.
├── NuGet.Config
├── Program.cs
├── project.json
└── project.lock.json
0 directories, 4 files
</del>
This happens because the compilation produces in-memory assemblies, which aren’t persisted on any file. The CoreCLR virtual machine uses this in-memory assemblies when running the application.
Well, it seems I was wrong: the dotnet run
command does indeed produce persisted files. This is a change when compare with dnx
, which did use in-memory assemblies.
We can see this behaviour by using the -v
switch
HelloDotNet pedro$ dotnet -v run
Running /usr/local/bin/dotnet-compile --output "/Users/pedro/code/dotnet/HelloDotNet/bin/.dotnetrun/3326e7b6940b4d50a30a12a02b5cdaba" --temp-output "/Users/pedro/code/dotnet/HelloDotNet/bin/.dotnetrun/3326e7b6940b4d50a30a12a02b5cdaba" --framework "DNXCore,Version=v5.0" --configuration "Debug" /Users/pedro/code/dotnet/HelloDotNet
Process ID: 20580
Compiling HelloDotNet for DNXCore,Version=v5.0
Running /usr/local/bin/dotnet-compile-csc @"/Users/pedro/code/dotnet/HelloDotNet/bin/.dotnetrun/3326e7b6940b4d50a30a12a02b5cdaba/dotnet-compile.HelloDotNet.rsp"
Process ID: 20581
Running csc -noconfig @"/Users/pedro/code/dotnet/HelloDotNet/bin/.dotnetrun/3326e7b6940b4d50a30a12a02b5cdaba/dotnet-compile-csc.rsp"
Process ID: 20582
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.4388306
Running /Users/pedro/code/dotnet/HelloDotNet/bin/.dotnetrun/3326e7b6940b4d50a30a12a02b5cdaba/HelloDotNet
Process ID: 20583
Hello dotnet!
Notice how it first calls the compile
command (addressed in the next section) before running the application.
Compiling the application
The dotnet
tool also allows the explicit compilation via its compile
command.
HelloDotNet pedro$ dotnet compile
Compiling HelloDotNet for DNXCore,Version=v5.0
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.4249439
The resulting artifacts are stored in two new folders
HelloDotNet pedro$ tree .
.
├── NuGet.Config
├── Program.cs
├── bin
│ └── Debug
│ └── dnxcore50
│ ├── HelloDotNet
│ ├── HelloDotNet.deps
│ ├── HelloDotNet.dll
│ ├── HelloDotNet.pdb
│ └── NuGet.Config
├── obj
│ └── Debug
│ └── dnxcore50
│ ├── dotnet-compile-csc.rsp
│ ├── dotnet-compile.HelloDotNet.rsp
│ └── dotnet-compile.assemblyinfo.cs
├── project.json
└── project.lock.json
6 directories, 12 files
The bin/Debug/dnxcore50
contains the most interesting outputs from the compilation process. The HelloDotNet
is a native executable, visible by a _main
symbol inside of it, that loads the CoreCLR virtual machine and uses it to run the application.
HelloDotNet pedro$ otool -tvV bin/Debug/dnxcore50/HelloDotNet | grep _main
_main:
otool
is the object file displaying tool for OS X.
We can also see that the libcoreclr
dynamic library is used by this bootstrap executable
HelloDotNet pedro$ otool -tvV bin/Debug/dnxcore50/HelloDotNet | grep libcoreclr.dylib
00000001000025b3 leaq 0x7351(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
00000001000074eb leaq 0x2419(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
000000010000784b leaq 0x20b9(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
The HelloDotNet.dll
file is a .NET assembly (has dll
extension and starts with the 4d 5a
magic number) containing the compiled application.
HelloDotNet pedro$ hexdump -n 32 bin/Debug/dnxcore50/HelloDotNet.dll
0000000 4d 5a 90 00 03 00 00 00 04 00 00 00 ff ff 00 00
0000010 b8 00 00 00 00 00 00 00 40 00 00 00 00 00 00 00
0000020
Directly executing the HelloDotNet
file runs the application.
HelloDotNet pedro$ bin/Debug/dnxcore50/HelloDotNet
Hello dotnet!
We can also see that the CoreCLR is hosted in executing process by examining the loaded libraries.
dotnet pedro$ ps | grep Hello
18981 ttys001 0:00.23 bin/Debug/dnxcore50/HelloDotNet
19311 ttys002 0:00.00 grep Hello
dotnet pedro$ sudo vmmap 18981 | grep libcoreclr
__TEXT 0000000105225000-000000010557a000 [ 3412K] r-x/rwx SM=COW /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__TEXT 000000010557b000-000000010575a000 [ 1916K] r-x/rwx SM=COW /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__TEXT 000000010575b000-0000000105813000 [ 736K] r-x/rwx SM=COW /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__LINKEDIT 0000000105859000-00000001059e1000 [ 1568K] r--/rwx SM=COW /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__TEXT 000000010557a000-000000010557b000 [ 4K] rwx/rwx SM=PRV /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__TEXT 000000010575a000-000000010575b000 [ 4K] rwx/rwx SM=PRV /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__DATA 0000000105813000-0000000105841000 [ 184K] rw-/rwx SM=PRV /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
__DATA 0000000105841000-0000000105859000 [ 96K] rw-/rwx SM=ZER /usr/local/share/dotnet/runtime/coreclr/libcoreclr.dylib
Native compilation
One of the most interesting features on .NET Core and the dotnet
tool is the ability to create a native executable containing the complete program and not just a boot strap into the virtual machine. For that, we use the --native
option on the compile
command.
HelloDotNet pedro$ ls
NuGet.Config Program.cs project.json project.lock.json
HelloDotNet pedro$ dotnet compile --native
Compiling HelloDotNet for DNXCore,Version=v5.0
Compilation succeeded.
0 Warning(s)
0 Error(s)
Time elapsed 00:00:01.1267350
The output of this compilation is a new native
folder containing another HelloDotNet
executable.
HelloDotNet pedro$ tree .
.
├── NuGet.Config
├── Program.cs
├── bin
│ └── Debug
│ └── dnxcore50
│ ├── HelloDotNet
│ ├── HelloDotNet.deps
│ ├── HelloDotNet.dll
│ ├── HelloDotNet.pdb
│ ├── NuGet.Config
│ └── native
│ ├── HelloDotNet
│ └── HelloDotNet.dSYM
│ └── Contents
│ ├── Info.plist
│ └── Resources
│ └── DWARF
│ └── HelloDotNet
├── obj
│ └── Debug
│ └── dnxcore50
│ └── HelloDotNet.obj
├── project.json
└── project.lock.json
11 directories, 13 files
Running the executable produces the expected result
HelloDotNet pedro$ bin/Debug/dnxcore50/native/HelloDotNet
Hello dotnet!
At first sight, this new executable is rather bigger that the first one, since it isn’t just a bootstrap into the virtual machine: it contains the complete application.
HelloDotNet pedro$ ls -la bin/Debug/dnxcore50/HelloDotNet
-rwxr-xr-x 1 pedro staff 66368 Dec 28 10:12 bin/Debug/dnxcore50/HelloDotNet
HelloDotNet pedro$ ls -la bin/Debug/dnxcore50/native/HelloDotNet
-rwxr-xr-x 1 pedro staff 987872 Dec 28 10:12 bin/Debug/dnxcore50/native/HelloDotNet
There are two more signs that this new executable is the application. First, there aren’t any references to the libcoreclr
dynamic library.
HelloDotNet pedro$ otool -tvV bin/Debug/dnxcore50/HelloDotNet | grep libcoreclr.dylib
00000001000025b3 leaq 0x7351(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
00000001000074eb leaq 0x2419(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
000000010000784b leaq 0x20b9(%rip), %rsi ## literal pool for: &amp;amp;amp;quot;libcoreclr.dylib&amp;amp;amp;quot;
HelloDotNet pedro$ otool -tvV bin/Debug/dnxcore50/native/HelloDotNet | grep libcoreclr.dylib
HelloDotNet pedro$
Second, it contains a ___managed__Main
symbol with the static void Main(string[] args)
native code
HelloDotNet pedro$ otool -tvV bin/Debug/dnxcore50/native/HelloDotNet | grep -A 8 managed__Main:
___managed__Main:
0000000100001b20 pushq %rax
0000000100001b21 movq ___ThreadStaticRegionStart(%rip), %rdi
0000000100001b28 movq (%rdi), %rdi
0000000100001b2b callq _System_Console_System_Console__WriteLine_13
0000000100001b30 nop
0000000100001b31 addq $0x8, %rsp
0000000100001b35 retq
0000000100001b36 nop
In addition to the HelloDotNet
executable, the compile --native
command also creates a bin/Debug/dnxcore50/native/HelloDotNet.dSYM
folder the native debug information.
Unfortunately, the .NET Core native support seems to be in the very early stages and I was unable to compile anything more complex than a simple “Hello World”. However, I’m looking forward to further developments in this area.