Retiring dotnet migrate in .NET Core SDK 2.0

[bleroy]

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.

[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?

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

[tmds]

@bleroy The .NET Core 1.0.4 release for RHEL only included updates to the framework and not the 1.0.1 CLI. Removing the migrate command in the 2.0 SDK means it is never available on RHEL.

[mlorbetske]

cc @balachir

[livarcocc]

@tmds What do you mean? We do have a RHEL zip of the SDK available for 1.0.1 of the CLI.

[tmds]

@livarcocc the package built by Red Hat: https://www.microsoft.com/net/core#linuxredhat

[bleroy]

@tmds: would it be acceptable to use the one you can find on https://www.microsoft.com/net/download/linux?

[tmds]

@bleroy that would be an anti-pattern for the RHEL software collections. Some things went wrong causing RH not to ship an update CLI. I expect we will do better for 2.0. Atm no one is looking to improve this for 1.x, so it would be preferable the 2.0 cli includes the migrate command.

Migration itself doesn't require a 1.0 runtime, does it? From the above, I understand the tests do not only validate conversion of project.json to csproj but the projects are actually compiled (which requires the 1.x runtime) and the resulting output is compared? I guess this accounts for most of the time.

[dasMulli]

Is there any telemetry data available on how many users are still using a project.json based cli and how many users are still on vs 2015?
I'm a little worried because not every company upgrades their VS quickly. So it would be a pity if the 2015>2017 migration path would be broken - I guess there won't be a way to install an "old" version of VS.
I've also heard from quite a few users on slack that they want to give csproj / vs2017 some time to improve. For a lot of them, missing mono support (esp running tests on mono) is a blocker.

[dasMulli]

As for the runtime.. I guess if you migrate, you probably already have a shared 1.0/1.1 runtime installed and the migration emits a RuntimeFrameworkVersion property based on what the project.json file was using.

[jeffkl]

@livarcocc would it make sense to just leave the migrate command but turn off the tests in the build? You could put a warning in the output of the command that its no longer supported and then reject any pull requests that try to add functionality because the tests are turned off. I can see people upgrading over the next year and trying to come from project.json-based projects.

[bleroy]

Quick update: we're looking at ways to keep the migration code available in the long term while mitigating the engineering cost associated with keeping it in CLI. We'll come back to this thread with a proposal.

[bleroy]

In order to give people more time to migrate their code to the new tooling, and to take into account the current unavailability of the command under certain environments, we've decided to keep dotnet migrate in 2.0. We do want to mitigate the cost it represents, however.

To that end, we're in the process of creating a new repo to receive the source code for the migrate command. This enables us to isolate the test code and issues from the rest of the CLI. This repo will become a dependency of the CLI, which will continue to support dotnet migrate through a shim in the main CLI code calling into the migrate code.

From a user's perspective, nothing changes for 2.0: dotnet migrate continues to be available. In releases post 2.0, we'll re-consider whether the command still needs to be present, or if it can become a completely separate executable.

[johnkors]

Could a solution be to provide it as a tool instead of being part of the CLI..?

[livarcocc]

Is it still part of the CLI. We just moved the code to a separate repo and now the CLI consumes a library to implement dotnet migrate. The repo is at github.com/dotnet/cli-migrate.