.NET Core and ASP.NET Core 1.0 are finally here, and in this post I'll show how to get started with these new tools using the command line tooling. This is not meant to be your typical getting started tutorial that jumps right into Visual Studio and creates a Web project from there. Rather, the purpose of this post is to demonstrate some of the core underpinnings of how .NET Core and ASP.NET Core projects are bootstrapped and using the command line tooling is actually the best way to demonstrate this.
I'll start at the beginning with 'HelloWorld' then add additional pieces and ASP.NET and demonstrate how to deploy and then run the application both on Windows and a Mac.
You can find the code for this simple walkthrough at:
If you're brand new to .NET Core and what it all means you might also enjoy reading the Overview post first:
Command Line Tooling
One of the nice things about the new command line tooling is that all .NET pieces - the runtimes, compiler and command line tooling - are installed through a single unified install. As I mentioned in my ASP.NET and .NET Core Overview post.
I’ll use Windows here to create this first application, but note that you can also do the same thing on a Mac or a Linux machine if the .NET SDK is installed. The steps other than installation are the same so you can follow along on a Mac or Linux.
Start by downloading the .NET SDK from http://dot.net. Click on the .NET Core link and follow the install instructions for your platform. To create a new project, you can follow the directions from that page.
The steps are:
- Create a new folder
- Change to the new folder
dotnet new to create a new project
dotnet restore to bring down NuGet packages required
dotnet run to actually run the application
As you can see in Figure above the output of this console application is dumped to the console. You’ve just created and run a .NET application in 3 small steps.
dotnet new which creates a new project with a
program.cs file that contains a
public Main() function, just like you expect for a classic Console application. All .NET Core applications, including ASP.NET applications now are Console applications.
The first thing you need to do is
dotnet restore which restores all the NuGet packages linked in the project. In an empty project like this one it doesn't actually do anything other than reference the .NET Standard Library installed on your machine.
Once you've restored you can do
dotnet run which runs the default hello world program:
You can now open the
program.cs file in that was generated and change the code. For example, change the
Console.WriteLine() to add a date and time:
public class Program
public static void Main(string args)
Console.WriteLine("Hello World. Time is: " +
Back at the command line just use
dotnet run and you should see the updated message including the time displayed.
Hello World. Time is: 5:36 PM
Note that the code automatically was recompiled and executed with the change you made when you did
dotnet run. There's no explicit compilation step - there is however an explicit
dotnet build command you can use if you explicitly want to just build your project.
To recap. You:
- installed .NET
- ran three commands
- and had a running .NET piece of code
While developers of languages like NodeJs have taken this for granted you can now much more easily create new project or small utilities using this same approach using .NET.
Where's my Executable?
One thing you might have noticed in the code above is that you are not executing an EXE file. Instead you run
dotnet run in a folder that contains a
project.json file which contains the instructions to bootstrap the application. This does mean that current applications have to run out of a dedicated folder and have to contain the files to build the project.
Code is compiled into an assembly on the fly (stored in the
bin folder as a DLL) which is then loaded by the dotnet runtime loader that hosts the DLL when you do
dotnet run. The build process does produce binaries in the
bin folder, but there's no mainline exe.
dotnet run options determine whether the project is compiled or uses the existing assemblies from the
Building an Exe
dotnet build or
dotnet run using the project json shown earlier, it produces a platform agnostic, portable set of assemblies that can execute on any platform that are loaded from
dotnet.exe when you run
It is possible to build your application to an EXE by creating a platform specific build. A number of directives in
project.json can be used to specify the output targets.
dotnet publish then creates a renamed
dotnet.exe that automatically launches the platform specific project. For more info please see .NET Core Application Deployment (thanks to Bertrand for the link).
In the future there's also been talk about the creation of native binaries with dynamic compilation, but for now only this pass through execution through
dotnet.exe and a required folder are supported.
Command Line Bigotry?
So the command line tooling is interesting in that it makes it much easier to create, build and run .NET applications.
But it's not just that you can perform the build process from the command line, but the fact that it’s very easy to get started. Download a relatively small SDK, install it, scaffold a base project, then use any text editor (or full boat Visual Studio) to make a change to your code and run. Compare that with the process of how you get started with the full version .NET, which pretty much involves downloading Visual Studio or installing a slew of SDKs and figuring CSC command line syntax. Using
dotnet.exe with a few simple commands is a lot more approachable, and more importantly you can be up and running with this code from download to running code in about 5 minutes.
This is a very good thing!
The command line tools are there to make getting started easier and to appease those that like to work on a lower level than the big monster that is Visual Studio.
But that isn’t to say that you’re going to have to build your application from the command line now - you can still use Visual Studio which then uses the command line tooling for creating the projects on your behalf.
In fact, if you install the Visual Studio tooling for ASP.NET Core you get Visual Studio integration like you would expect, so you can use the rich Visual Studio editor and your favorite tools and extensions to build your applications.
But behind the scenes, Visual Studio calls into these same command line tools to compile your project. This opens up the build process to tooling or your own build process management, because you have easy access to the same tools that Visual Studio uses to build your project.
Personally I'm not a big command line guy - I prefer visual tooling for most things, but I have to admit that with this new tooling I find myself at the command line more often. Because the tooling is easy to use with terse commands it can often be quicker to restart an app from the command line than the Visual Studio run cycle. So beware - you might end up changing your habits (again - probably a good thing).
Other Posts you might also like