Rider EAP update: .csproj-based .NET Core support (and how to migrate)
The latest Rider Early Access Program (EAP) build now supports working with
.csproj-based .NET Core projects. In this post, let’s see what that means, what is supported (and what is yet to come) and how to migrate from the (deprecated)
project.json format to the new
What are .csproj-based .NET Core projects?
Back in May 2016, Microsoft announced that project.json would go away. It took a while, but since a few weeks the latest stable .NET Core tooling is all MSBuild based (or
.csproj-based, if you will).
Regular .NET and .NET Core now use the same toolchain, which means they can use the same SDK’s and existing build tasks and targets. That does mean going back to an XML-based format, but it comes with a few advantages. First, Microsoft greatly simplified the
.csproj format. In minimal format, this is what it looks like:
<Project Sdk="Microsoft.NET.Sdk"> <PropertyGroup> <TargetFramework>netstandard1.4</TargetFramework> </PropertyGroup> </Project>
Second, the good things of
project.jsonwere ported over to the new
- It supports wildcards (no more merge conflicts if a file is added to a project file).
- Command line tools like
dotnet.execan work with them.
- Multi-targeting is easy: simply specify the target frameworks and it will work.
- Package references and project references can easily be added.
- Building packages from a project is easier now, too (see full reference).
In our latest Rider EAP, we added the ability to open, edit, build, run and debug .NET Core projects that make use of this new
.csproj-based file format. Managing NuGet packages is supported as well, with install/update/uninstall support and automatic restore on startup (or after manually editing the
From the Solution Explorer we can select the project file and Jump to Source (F4) to edit the project directly, for example to change a package reference version:
There are a few rough patches still, for example unit test debugging is not (yet) supported. And while debugging of regular code is supported for Windows, we’re still woring on the .NET Core debugger for Mac OS and Linux (expect it in a few weeks). We’re working on adding the Add reference context menu as well. On Windows, you currently need a Visual Studio 2017 install. We’re working on removing this limitation in future builds. On Mac OS / Linux, the Mono tooling is required.
Keep in mind you do not have to hand-edit the
.csproj file: all IDE actions like adding classes and files, refactoring, … are supported. If you do want to edit the
.csproj by hand it’s almost as pleasant as editing JSON.
What’s happening to project.json?
Since Microsoft stopped support for
project.json in all new tooling like Visual Studio, NuGet,
dotnet.exe, … and is treating it as obsolete, we’ll be doing so as well.
Right now Rider still supports opening, building and running
project.json-based projects, but for example installing and updating NuGet packages will no longer work (since the NuGet tooling we use in the back-end no longer supports it).
No worries though: no need for a DeLorean to travel to the future! Migrating to the new format is fairly straightforward – let’s look at an example!
Migrating from project.json to .csproj
Let’s look at how we can move from
project.json (and the old
.xproj) to the new and shiny. Before starting, make sure that the required toolsets are installed. On Windows, you currently need a Visual Studio 2017 install (we’re working on that). On Mac OS / Linux, the Mono tooling is required.
The latest version of the .NET Core CLI comes with a handy tool that can automate migration for most projects in the old format:
dotnet migrate. We can run it from the command line, or right from within Rider.
After opening a solution, we can open the built-in terminal (Alt+F12 or double-shift twice and type “terminal”) and run
dotnet migrate from there. Since the terminal opens in the solution folder by default, the migration tool will recognize our
.sln file and use it as the base to start migration.
If preferred, individual projects can also be migrated by invoking
dotnet migrate with specific arguments, but generally it’s recommended to convert the entire solution at once. The tool will also make a backup of the existing project files in case migration fails.
global.jsonfile and change the SDK version to 1.1.0. The
dotnet migratecommand requires .NET Core CLI RC3 or higher.
Once finished, existing
.xproj will be converted to
.csproj. Depending on the project type, Rider will automatically reload the solution after migration completes (worst case, you may have to close and re-open Rider).
Further details on migrating projects from
.csproj can be found on Microsoft’s documentation site:
Download the latest Rider EAP build and give it a try! We’d love to hear your feedback!