Rider EAP update: .csproj-based .NET Core support (and how to migrate)

Maarten Balliauw

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 .csproj format.

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.json were ported over to the new .csproj format:

• It supports wildcards (no more merge conflicts if a file is added to a project file).
• Command line tools like dotnet.exe can 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 .csproj).

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.

Note: If you get an error “No executable found matching command dotnet-migrate”, edit the solution’s global.json file and change the SDK version to 1.1.0. The dotnet migrate command requires .NET Core CLI RC3 or higher.

Once finished, existing project.json and .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 project.json to .csproj can be found on Microsoft’s documentation site:

• Migrating .NET Core projects to the .csproj format
• The dotnet migrate command line tool

Download the latest Rider EAP build and give it a try! We’d love to hear your feedback!

Subscribe to a monthly digest curated from the .NET Tools blog:

Subscribe form

By submitting this form, I agree to the JetBrains Privacy Policy Notification icon

By submitting this form, I agree that JetBrains s.r.o. ("JetBrains") may use my name, email address, and location data to send me newsletters, including commercial communications, and to process my personal data for this purpose. I agree that JetBrains may process said data using third-party services for this purpose in accordance with the JetBrains Privacy Policy. I understand that I can revoke this consent at any time in my profile. In addition, an unsubscribe link is included in each email.

Submit

Thanks, we've got you!