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 2017 .NET Core Project Overview
Lets again start by creating a console application with the command line tools.
Command Line Tools
We create our project with the same
> 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.
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
> 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
> 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.
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|
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.
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.
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
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.
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 certainly change by the time Visual Studio 2017 is actually shipped.