According to C# Corner's .NET Core - Fork In The Road (http://www.c-sharpcorner.com/article/net-core-fork-in-the-road/), the following table explains availability for distinct platforms, although the list is continuously growing:

Another target of .NET Core is to achieve project unification by means of a unique project.json file, in which all configuration features will appear independently of the type of project being built (no more app.config, web.config, and so on). However, in Visual Studio 2017, the dependencies declared in the project.json file have been moved to the .sln file for unification.

.NET Core is supposed to be built on four parts, including Core FX, Core CLR, Core RT, and Core CLI. Let's take a quick look these parts, one by one.

The .NET Core installation has changed since the first release candidates, and now the previous location at GitHub will lead us to the https://www.microsoft.com/net/core site, where we'll find instructions to download .NET Core in four different contexts: Windows, Linux, MacOS, and Docker.

Besides this installation, you can use .NET Core inside Visual Studio 2015 and higher versions if you additionally install NET Core 1.0.0 – VS 2015 Tooling, available at the same page. It takes a few minutes and asks for a confirmation (refer to the screenshot):

Note that, at the time of writing this, the VS 2015 Tooling is available as a preview version and will probably be in its final version by the time you read this. Additionally, you can install the Core CLI from the same page mentioned earlier or go directly to the https://github.com/dotnet/cli page.

Once the installation is complete, if we go to Visual Studio and select New Project, we'll see a new section called NET Core, offering three types of applications: Class Library, Console Application, and ASP.NET Core Web Application:

As you can imagine, in the fist case, we can create a DLL to be used by other projects, and the two latest options are the ones that make sense (for the moment) with this initial version of .NET Core.

If we take a look at the files created with the Console Application option, the Solution Explorer will show us a familiar structure with some differences, though.

To start with, we see the presence of two main directories: one for the solution (which includes a global.json file) and another called src, where we find the rest of the assets of our application.

The global.json file contains the folders that should be searched at compile-time when resolving dependencies for projects. The build system will only search top-level child folders.

By default, the following content is included:

{
  "projects": [ "src", "test" ],
  "sdk": {
    "version": "1.0.0-preview2-003121"
  }
}

This defines two projects in our solution: the standard one and another for testing. Besides this, the sdk key indicates the version to be used (1.0.0-preview-003121), and we can add or change that at will.

There are other options available, such as the architecture to be used (x64 / x86) or the target runtime, as shown in the next screenshot:

Within the src directory, the typical console structure can be found, only that all references included in the References section point to Microsoft.NETCore.App (1.0.0) and include a long list of components available, all of them in a hierarchical structure of dependencies.

The aspect of the main Program.cs file is just the usual in these projects (no changes), and this is true for AssemblyInfo.cs (although some values would be ignored on other platforms).

However, there's no app.config file. This file has been replaced with another .json file, project.json, which will be in charge of the definitions of the application's configuration from now on (remember that this has changed in Visual Studio 2017, where the .sln file is used to declare dependencies).

And, as it happens with the global.json file, the editor recognizes the values assigned to the keys and provides Intellisense here as well, with interesting hints about the possible values to configure (the next screenshot includes the initial list of references and Intellisense in action within the project.json file):

Now, I'm going to use a simple code snippet to explore how some of the common namespaces are implemented in .NET Core. In this case, we have three text files located in the same directory as the application (could be any directory, of course), and we're going to search for them, read their content, and present it in the console.

So we have some very simple code in the program.cs file, which serves as the entry point of the application:

staticstring pathImages = @"<Your Path to files>;
staticvoid Main(string[] args)
{
  Console.WriteLine(" Largest number of Rows: " + Console.LargestWindowHeight);
  Console.WriteLine(" Largest number of Columns: " + Console.LargestWindowWidth);
  Console.WriteLine(" ------------------------------
");
  ReadFiles(pathImages);
  Console.ReadLine();
}

privatestaticvoid ReadFiles(string path)
{
  DirectoryInfo di = newDirectoryInfo(path);
  var files = di.EnumerateFiles("*.txt",
  SearchOption.TopDirectoryOnly).ToArray();
  foreach (var item in files)
  {
    Console.WriteLine(" "+ File.ReadAllText(item.FullName));
  }
}

We can compile the program as always, and at runtime, we should see the output, only working on the .NET Core infrastructure (refer to the next screenshot):

As you can see, the functionalities, code, libraries, and namespaces used are just the same as the ones we would use in a standard Console application—only now, we're using the .NET Core 1.0 libraries and architecture.

However, a look at the code (and the output) will probably call your attention, since the name of the executable that we see in the output window is dotnet.exe and not NETCoreConsoleApp1 (the name we gave to our solution).

The reason for this has to do with the complexity linked to this model. The application is thought to be executable on distinct platforms. The default option allows the deployment architecture to determine the best way to configure the JIT compilers depending on the target. This is why the execution is undertaken by the dotnet runtime (named dotnet.exe).

In NET Core, two types of applications are defined: portable and self-contained. As the official documentation states:

The default configuration we're using is the portable one. Where is this configuration established? In the project.json dependencies section, you'll see that there is a "type":"Platform" entry. That's what indicates this execution model.

Actually, the resulting assembly is a DLL, as you can see by watching the bin/debug directory after compilation. In our case, this DLL is only 6 Kb long.

What about the other choice? Well, if you know that you're going to target a certain platform, you can eliminate the previously mentioned entry in the project.json file (that's first). Second, you should leave the Microsoft.NET Core.App dependency, since it will retrieve all of the rest of the required components. Finally, it will be necessary to indicate (in the runtimes node) those that you want to use.

So, I changed the project.json file to appear with this configuration:

{
  "version": "1.0.0-*",
  "buildOptions": {
    "emitEntryPoint": true
  },

  "dependencies": {
    "Microsoft.NETCore.App": {
      "version": "1.0.0"
    }
  },
  "runtimes": {
    "win10-x64": {}
  },
  "frameworks": {
    "netcoreapp1.0": {
      "imports": "dnxcore50"
    }
  }
}

Now the compiler behaves differently: it generates a new folder (dependent on the debug folder), containing a real native executable, which contains all the required elements to run in any platform of that type (win10-x64, in our demo).

After compilation, you'll see new files appearing, and one of them will be an executable file now. If you move to that folder in the Explorer, you'll see that there's a new file named NETCoreConsoleApp1.exe, which is the standalone executable. Also, this new file is larger than the DLL since it contains all the requirements (refer to the screenshot):

As we mentioned earlier, another choice available to develop these type of applications is now a command-line interface offered by the standalone installation of Core CLI or by the previous installation I made (the DotNetCore.1.0.0 - VS2015Tools.Preview2.0.1 file).

Several preconfigured command-line windows are made available depending on the platform to target under the generic name of Cross Tools Command Prompt. Just open the one that corresponds to your target platform and proceed as follows.

You can use the initial, basic demo mode that Microsoft has prepared as a start up with this tool. After opening Command Prompt, create a new directory that will serve as the root for a new project. In my case, I do it in a new C:devhello_world directory (among other things, to avoid some security issues that might arise when using the C: root directory).

At this point, you can ask for help by just typing dotnet –help, as shown in the following screenshot:

To create a new project over this location, type dotnet new. Core CLI will download all the required components to your directories, including a basic application template, which holds a program.cs file with the classic Hello World console application, along with the default project.json file.

From this point, you can also open the project with Visual Studio Code (any platform, remember) and make the desired changes. The dot (.) indicates the IDE to use the current directory as the solution's directory.

The next step is to call dotnet restore. The result is that NuGet gets called in order to restore the tree dependencies defined in project.json and creates a variant of this file called project.lock.json, which is required if you want to be able to compile and run (if you open this file, you'll see that it is pretty large).

The official documentation defines this file as:

From here, several options are available. You can launch a dotnet build command, which will build the application and generate a directory structure similar to the one we saw in Visual Studio. It will not run; it will only generate the resulting files.

The alternative option is to call dotnet run. With this command, the build option is called, and next, it launches execution; so, you should see something like this:

And, of course, it's a good practice to take a look at the resulting files, which will be located in a subdirectory of the debug file, just like in our Visual Studio app:

If you're curious, you can change the project.json file to generate the standalone executable, just like we did earlier, and the results should be equivalent.

Well, up until this point, we've seen an introduction to the .NET Core 1.0, but that's not the only development model .NET Core supports. Let's take a look at the—very interesting—ASP.NET Core 1.0.