In the previous post, we took a look at creating new .NET Core projects with the .NET Core Tools (1.0.0-preview2) in both Visual Studio 2015 and the .NET Core Command-Line Interface. We broke down the project structure, dived into the new files, and compared the CLI projects to Visual Studio ones.

In this post, we will perform the same exercise with Visual Studio 2017 RC and the 1.0.0-preview4 version of the .NET Core Tools.

This is the second post of a three part series.

• VS 2015 .NET Core Project Overview
• VS 2017 .NET Core Project Overview
• Migrating .NET Core Projects

VS 2017 .NET Core Project Overview

As with the previous tooling version, we have the option of creating projects with the Command-Line or with Visual Studio

Lets again start by creating a console application with the command line tools.

Command Line Tools

We create our project with the same new command.

> dotnet new

Created new C# project in C:\Jason\Demo\JrTech.Core101.Cmd.

Right off the bat, we notice a difference from the previous version. We have the following files in our directory.

• Program.cs
• JrTech.Core101.Cmd.csproj

What?!? Where is the project.json file? In its place, we see the return of the project file. Lets open it up and take a look.

<Project Sdk="Microsoft.NET.Sdk" ToolsVersion="15.0">

    <PropertyGroup>
        <OutputType>Exe</OutputType>
        <TargetFramework>netcoreapp1.0</TargetFramework>
    </PropertyGroup>

    <ItemGroup>
        <Compile Include="**\*.cs" />

    </ItemGroup>

    <ItemGroup>
        <PackageReference Include="Microsoft.NETCore.App" Version="1.0.1" />
    </ItemGroup>

</Project>

Hmm, not so bad. I noticed a couple key differences from previous versions of the project file.

• We are not directly tracking each C# file. Note the Compile element.
• We are referencing packages as opposed to assemblies which removes the need to have a separate packages.config file.

Next, lets restore our package dependencies with the familiar restore command.

> dotnet restore

Restoring packages for C:\Jason\Demo\JrTech.Core101.Cmd\JrTech.Core101.Cmd.csproj...
Writing lock file to disk. Path: C:\Jason\Demo\JrTech.Core101.Cmd\obj\project.assets.json
Restore completed in 656.496ms for C:\Jason\Demo\JrTech.Core101.Cmd\JrTech.Core101.Cmd.csproj.

NuGet Config files used:
C:\Users\Jason\AppData\Roaming\NuGet\NuGet.Config
C:\Program Files (x86)\NuGet\Config\Microsoft.VisualStudio.Offline.config

Feeds used:
https://api.nuget.org/v3/index.json
C:\Program Files (x86)\Microsoft SDKs\NuGetPackages\

After restore, we no longer see the project.lock.json. We do however, see the obj folder was created. Inside of it we notice the project.assets.json. If we look at the contents, it contains much of the same data as the former project.lock.json file. This is probably a good move as I wasn’t much of a fan of having the project.lock.json at the root of the project. Tucking this file data away in the obj folder makes a lot more sense as it is frequently added by default in many .gitignore files.

Now with our packages restore, lets execute the run command.

> dotnet run

Hello World!

The program successfully executes and we are left with the following file structure.

├── bin
├── obj
| └── project.assets.json
├── JrTech.Core101.Cmd.csproj
├── Program.cs

Now let’s create a .NET Core project with Visual Studio 2017 RC.

Visual Studio

Similar as before, we can create a new project by selecting File | New | Project and choosing Console App (.NET Core).

Once this is completed, we observe the following contents in the Solution Explorer.

On disk, we see the following

├── JrTech.Core101.Vs.sln
├── JrTech.Core101.Vs
| ├── bin
| ├── obj
| | └── project.assets.json
| ├── JrTech.Core101.Vs.csproj
| ├── Program.cs

Unlike version 1.0.0-preview2 of the .NET Core Tooling, we are left with a consistent file structure between the two methods. If you recall in my previous post, there were quite a few differences between creating a project with the command line vs through Visual Studio.

Comparing with the Prior Version

Now lets drill into some differences between the Visual Studio 2015 and Visual Studio 2017 RC 1 by looking at each of the key files.

File	Visual Studio 2015	Visual Studio 2017 RC
global.json	Yes	No
JrTech.Core101.Vs.sln	Yes	Yes
JrTech.Core101.Vs.xproj	Yes	No
JrTech.Core101.Vs.csproj	No	Yes
AssemblyInfo.cs	Yes	No
project.json	Yes	No
project.lock.json	Yes	No
project.assets.json	No	Yes

Looking at the two, there are some pretty significant differences. First and foremost, the xproj and project.json have been removed and their contents are merged into the new (and improved) csproj file. The project.lock.json file has been renamed to project.assets.json and relocated appropriately to the obj folder. Lastly, the global.json and AssemblyInfo.cs files were not created by default.

Pros

I’ll admit it. At first, I was a bit salty when the project.json file was removed. This was a drastic improvement over previous .NET Project Files which were very unpleasant to work with. But we have to understand. The project file never went anywhere. We were still stuck with the awkward xproj file.

One thing I really like about the new version of the .NET Core Tools is the consistency. No matter if we create a project with the CLI tooling or with Visual Studio, the file structure is the same. This in my opinion is a huge benefit. With the prior version, we had a idealistic project structure from the CLI with awkward shims to get it to work with visual studio.

Another improvement (as mentioned previously) is the new project.assets.json files. The project.lock.json file was not named intuitively and was wrongly located at the root of the project.

Cons

While moving (back) to the csproj file was a good move all-in-all, we lost a couple of features. The project.json file had intellisense support. From what I can tell the csproj version does not. Although you can edit the csproj file without closing the project as in previous versions of Visual Studio.

Lastly, the project.json file allowed us to target multiple frameworks simultaneously. With the csproj file, we can only target one.

Visual Studio 2015

Visual Studio 2017

Summary

From what I can tell, the .NET Core team is moving things in the right direction. There were some concerns throughout the community with the removal of the project.json file initially however, when looking at things holistically you can see this was a good decision. That said, I’m really hoping intellisense support is added in to the csproj project file. This was a step backwards from the project.json and I’m hoping it is included in their final release.

Stay tuned for the final post in this series which looks at migrating a .NET Core project from Visual Studio 2015 to Visual Studio 2017.

Disclaimer

As part of this post, I would also like to point out what might be obvious to some but, not to others. This is Visual Studio 2017 RC. Things could change by the time Visual Studio 2017 is released.