Updating My Blog to Visual Studio 2017 and .csproj

Now that the ASP.NET Core tooling changes are finally here, I decided to update my blog to the new bits. Goodbye project.json and hello .csproj.

Finding the project after upgrading it, I had to look for those points of contact I had gotten comfortable using. The upgrade wasn’t painful (look back at those Beta 7-Beta 8 upgrades for that story), but knowing where they moved your cheese is important. Hopefully this post helps you with the same issues.

Moving to Visual Studio 2017

I’ve been watching the changes from using the project.json file to MSBuild (e.g. .csproj) for a while. Instead of manually updating it (which you can do with the SDK alone), I decided to just open the project in Visual Studio 2017 and let it update it for me. What I ended up with was a backup directory with my old project.json file and a couple of new files:

The .csproj file is the new way to handle the compiler settings and references for the project. While the new file, runtimeconfig.template.json file is where the GC settings were moved to:

{
  "gcServer": true
}

The project pretty much worked once we made the change with no real changes.

Workflow Changes

In the old tooling, I really fell in love with the project.json because of the way that it handled nuget package references. I loved the idea of just typing into the json and see the intellisense help me find the right package. So how does this change with the new MSBuild-based changes?

Since this is Visual Studio, your tried and true Manage Nuget packages UI continues to work (as does the Powershell window):

But I kinda hate the UI for managing NuGet packages, so I wanted other options. In Visual Studio 2017, you can edit the .csproj without unloading the project. But the only easy way to do it is with the context menu option (the csproj doesn’t show up in Solution Explorer):

You can edit the PackageReference by hand, but the intellisense is missing so it becomes a lot less interesting:

<ItemGroup>
  <PackageReference Include="Microsoft.AspNetCore.Diagnostics" Version="1.1.0" />
  <PackageReference Include="Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore" Version="1.1.0" />
  <PackageReference Include="Microsoft.AspNetCore.Identity" Version="1.1.0" />
  <PackageReference Include="Microsoft.AspNetCore.Mvc" Version="1.1.0" />
  <PackageReference Include="Microsoft.AspNetCore.Mvc.TagHelpers" Version="1.1.0" />
  <!-- ... -->
</ItemGroup>

So I’ve dropped down to the new CLI support you have for managing references. I’m using two tools in a console window to help me with this. The dotnet.exe console

D:\working\Fun>dotnet add package Microsoft.AspNetCore.Routing -v 1.1.0

If you omit the –v, it will load the latest version. But since it won’t help you find packages, you can use the nuget.exe CLI. Using “nuget list” will let you search the nuget package repository easier than the website (in my opinion):

D:\working\Fun>nuget list Microsoft.AspNetCore.Mvc
Cuemon.AspNetCore.Mvc.Formatters.Json 4.1.2017.350
Cuemon.AspNetCore.Mvc.Formatters.Xml 4.1.2017.350
Microsoft.AspNetCore.Mvc.Versioning 1.0.3
Microsoft.AspNetCore.Mvc 1.1.1
Microsoft.AspNetCore.Mvc.Abstractions 1.1.1
Microsoft.AspNetCore.Mvc.ApiExplorer 1.1.1
Microsoft.AspNetCore.Mvc.Core 1.1.1
Microsoft.AspNetCore.Mvc.Cors 1.1.1
Microsoft.AspNetCore.Mvc.DataAnnotations 1.1.1
Microsoft.AspNetCore.Mvc.Formatters.Json 1.1.1
Microsoft.AspNetCore.Mvc.Formatters.Xml 1.1.1
Microsoft.AspNetCore.Mvc.Formatters.Xml.Extensions 1.1.0.02
Microsoft.AspNetCore.Mvc.Localization 1.1.1
Microsoft.AspNetCore.Mvc.Razor 1.1.1
Microsoft.AspNetCore.Mvc.Razor.Host 1.1.1
Microsoft.AspNetCore.Mvc.TagHelpers 1.1.1
Microsoft.AspNetCore.Mvc.ViewFeatures 1.1.1
Microsoft.AspNetCore.Mvc.WebApiCompatShim 1.1.1

In this way, you have lots of options for managing your packages, pick the one that makes you most comfortable. I like the CLI because it’s the same one I use when I’m doing VSCore work too.

Defining Build Scripts

Also in the csproj file are the scripts that you want to run during build events (e.g. before builds, after builds, before publish, etc.) For example, my scripts for getting the bower packages and running gulp before publish was migrated into the csproj file:

  <Target Name="PrepublishScript" BeforeTargets="PrepareForPublish">
    <Exec Command="npm install" />
    <Exec Command="bower install" />
    <Exec Command="node node_modules\\gulp\\bin\\gulp.js" />
  </Target>

What about Tools?

Finally, for the tools that were in the** project.json,** those are also migrated into the csproj files. They’ve been simplified to just be the name of the package. You do not need to include the package reference too, it’ll do both. For example:

  <ItemGroup>
    <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />
  </ItemGroup>

With that, I was able to build the project and deploy it live.

What has your experience been?