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 .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:

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:

Jump to Source to edit .csproj project file

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.

Running dotnet migrate in Rider terminal

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.
Update global.json to make sure the dotnet migrate tool works

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).

Project converted from project.json to .csproj format

Further details on migrating projects from project.json to .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!

This entry was posted in How-To's and tagged , , , . Bookmark the permalink.

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

  1. John R says:

    It’s asking for MSBuild 15 on Ubuntu. MSBuild.dll for version 15 is in the dotnet sdk, so why can’t Rider use that, instead of waiting who knows how long for it to appear in Mono?
    (yes, all the stuff is up-to-date)

  2. Pingback: Fast Forward: Symfony 2.8.19 ist erschienen & Neues bei Rider EAP - zend-framework.net

  3. Mike-EEE says:

    Please please please make a new project/solution file for Rider that is POCO-based and truly provides a “lit up” tooling experience in editing and maintenance. At the very least, please provide a SLN format that doesn’t look like it’s out of 1982. :p

    Since VS2017 is essentially a brand new IDE that has nearly 10,000 (!!!) problems already registered on its developer portal, taking the steps to investigate Rider is becoming more and more attractive by the day. Having a legitimate project model that is properly represented by POCOs (along with the powerful synergic tooling that would facilitate and empower it) would be all the more reason to do so.

    Especially so since MSFT has waded in this mire without much improvement for well over a decade. And no, removing GUIDs from schemaless tripe doesn’t count. 😉

  4. Pingback: Dew Drop - April 5, 2017 (#2456) - Morning Dew

  5. Pingback: Symfony 2.8.19 ist erschienen & Neues bei Rider EAP

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

  7. Wes says:

    For dotnet-migrate to work, do you mean the SDK version should be 1.0.0? At this time there’s no 1.1.0 SDK.

  8. giridhar p yellapu says:

    Does the latest EAP 20 support .net core debugging on Mac OS?

Leave a Reply

Your email address will not be published. Required fields are marked *