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.json were 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!
Subscribe to Blog updates
Thanks, we've got you!
Eager, Lazy and Explicit Loading with Entity Framework Core
Entity Framework Core (EF Core) supports a number of ways to load related data. There’s eager loading, lazy loading, and explicit loading. Each of these approaches have their own advantages and drawbacks. In this post, let’s have a quick look at each of these ways to load data for navigational prope…
OSS Power-Ups: bUnit – Webinar Recording
The recording of our webinar, OSS Power-Ups: bUnit, with Egil Hansen and Steven Giesel, is available. This was the twelfth episode of our OSS Power-Ups series, where we put a spotlight on open-source .NET projects. Subscribe to our community newsletter to receive notifications about future webi…
Accelerating Your Testing Workflow with Unit Test Creation and Navigation
Unit tests play an important role in our daily development workflow. They help us ensure our codebase's correctness when writing new functionality or performing refactorings to improve readability and maintainability. In the process, we often create new test files that accompany the p…
Introducing Predictive Debugging: A Game-Changing Look into the Future
With the introduction of debugging tools, software developers were empowered to interactively investigate the control flow of software programs to find bugs in live environments. At JetBrains, we've always strived to improve the art of debugging. Besides the more standard things you expect from a de…