Retiring dotnet migrate in .NET Core SDK 2.0

In .NET Core SDK 1.0, we introduced a dotnet migrate command that migrates a project.json-based Preview 2 .NET Core project to a .csproj-based .NET Core SDK 1.0 project. This command was always intended to be only needed in the 1.0 timeframe, to help our early adopters move to the new project system.

In .NET Core SDK 2.0, we are retiring the dotnet migrate command. Developers who still need to migrate Preview 2 projects after the SDK 2.0 has shipped should first install the 1.0 SDK, migrate their projects, and then install the 2.0 SDK.

[livarcocc]

It is currently adding complexity to our build script because migration works for the 1.0 runtime, and on 2.0 CLI, we will carry only 2.0 shared runtime. Because of migration, we are keeping a 1.0 version of the shared framework that we want to remove.

Also, because of migration, we download a project.json capable CLI just so we can build the project.json projects and compare with the output of the migrated projects.

Another reason is that right now, migration tests account for half of our test time.

So, migration is adding build complexity to our repo, forcing us to depend on things that we don’t need/want anymore and costing half of our build time in doing so.

[khellang]

As always, it would be really nice to get just a tiny hint on why this is being done. Is it harming anyone? Blocking other features? Just too much code to maintain?