Implement NuGet redirection on renaming of packages

[OlegKi]

I'm not sure which GitHub repository is responsible for the problem. Thus I post the new issue here.

I see, that a lot of developers who starts with ASP.NET 5 with early betas or RC1 spend a lot of time in migration to the next version. One of the common problem is renaming of packages. One continue the renaming in RC2 (see many announcements already published). Many developers even have no idea about renaming because NuGet gives no information about it. In many cases the renaming holds the most names of the methods.

Let us we look on an example. EntityFramework.SqlServer is renamed to EntityFramework.MicrosoftSqlServer in RC1, but the NuGet repository https://www.nuget.org/packages/EntityFramework.SqlServer/ gives no information about such renaming. I suggest to implement some kind of automatic redirection to https://www.nuget.org/packages/EntityFramework.MicrosoftSqlServer/. On searching of updates to the latest version of EntityFramework.SqlServer (dnu restore or some other) one should get at least a warning about renaming of the package to EntityFramework.MicrosoftSqlServer in version 7.0.0-rc1-final instead of just showing that 7.0.0-beta8 is the latest version of EntityFramework.SqlServer and everything is "up to date".

It would be of cause more better to implement automatic renaming (or renaming after the confirmation dialog) of the entries from project.json and implementation the Tooltips in Visual Studio to show (or include) the correct using statement. For example if I would type

services.AddIdentity<ApplicationUser, IdentityRole>();

I'll get tooltips like

and then another one, which allows me to include "Microsoft.AspNet.Identity": "3.0.0-rc1-final" and "Microsoft.AspNet.Identity.EntityFramework": "3.0.0-rc1-final" in project.json with additional including using Microsoft.AspNet.Identity.EntityFramework; in the C# code.

I think that the exact implementation can suggest the corresponding team of ASP.NET 5 project. The more comfort on renaming of packages the better, but the current state with no warning is really very bad.

[Eilon]

@yishaigalatzer

[yishaigalatzer]

Yes we are considering such an item (definitely not auto redirection) but a warning and suggestion for sure.

Currently package owners have the full capability of doing this by posting a new package with a readme or error various different ways to do (you can see win2d as an example)

[OlegKi]

@yishaigalatzer The package owner, can change "Title", "Description" and some other fields, which will be not used by dnu restore for example. Placing information like "deprecated Win2D 1.0.0" and "DEPRECATED - please use Win2D.win81 or Win2D.uwp instead" is really absolute minimum which one could do, but such step don't solve the problem of any real solution, which has many projects with its dependencies. Event such simple step didn't made by ASP.NET 5 team till now.

I look at the problem from the position of developer, which uses many packages. One common design problem is that the name of the package is the same as the id, which one uses for references. It means that the renaming breaks all existing references.

The most renaming of packages made last time by the ASP.NET team have no changes in the functionality. One wanted mostly just to change "the label" only, not the ID. Thus I see very important to extend the NuGet model to allow the redirection. I made design analysing of package dependencies for one large German company and I know that the problem is really complex and have many aspects. I could identify that renaming is relatively common case, for example, if one software product will be sold to another company, or after the companies involved in the takeover, or if the company reorganizes the structure of projects (like in your case) and so on. Thus what I suggest is mostly two things:

1. consider to provide non-mutable package id (a GUID/UUID or any other) or NuGet packages; I understand that the problem is not simple if one take in consideration long life of the product (think about Package Code and Upgrade Code of the Windows Installer), but any constant ID is better as changeable name. One can at least use the ID for internal references in NuGet repository. It could be that the ID already exist.
2. providing redirection ways by addressing (referencing) of the package by name. I mean that the publisher of the package can declare the end of life of one name and to choose the form of redirection or just a warning message: either automatic redirection with small warning or just a warning message without any actions.

The publisher of the old package should be able to decide the strategy of redirection. The current state of the problem is really terrible. The publisher renamed EntityFramework.SqlServer after the version 7.0.0-beta8 to EntityFramework.MicrosoftSqlServer and published the next minor version as 7.0.0-rc1-final. The developers, who had complex solution with many projects, like many class libraries, which used EntityFramework.SqlServer name get no information about the renaming (which is just changing "the label" in my previous definition). Everything (7.0.0-*) will be successful resolved to the last old version (7.0.0-beta8). It's the reason of many errors. It's difficult to look through all announcements published on https://github.com/aspnet/Announcements/issues, through readmes and so on. One can take a look on the questions on the stackoverflow after publishing of every new beta release of ASP.NET. One sees a lot of project.json which uses packages by old names and just try to solve new problems after changing to the new version.

The example with splitting of one package Win2D into two new packages Win2D.win81 and Win2D.uwp is less common case. I think that the current state with the package is also not sutisfied. If I would try to add "Win2D" in the "dependencies" part of some the project.json I will see all published versions of the package and will just choose "1.0.0" as the latest one. If I would resolve the dependency in Visual Studio 2015 or with dnu restore I will see "Restore complete" in the output. The project which have

"dependencies": {
    "Win2D": "1.0.0"
}

will be successfully build and the developer get no advice that the project uses the package, which is deprecated since more as a half of year. Even if the developer would open "Updates" tab of NuGet Package Manager in Visual Studio Project, he/she will get no information that any update exist.

I understand, that it would be better to implement such feature already yesterday, but probably one could better implement some features tomorrow as never.

[yishaigalatzer]

In the win2d case the user can take the extra step and actually publish a new version that adds a readme, throws an error etc.

The way we currently think about it is a deprecation feature rather than redirection. So as a user you get an error and a message.

We don't have a specific design yet, and once we get far enough to a point that we can picking this idea up we will pay Av design on our wiki.

Either way this is the wrong repo to track this as dnu has reached and end of life and we are moving to use nuget proper for restore.

[yishaigalatzer]

Oh and we advise against using * notation for public packages. It is designed for CI build updates

[OlegKi]

@yishaigalatzer An introduction of deprecation could be the only option, where I can agree with you under some conditions, but sometime one want to build with specific old version to revert to old version if something is broken, for example.

The problem is that one need mostly to use the latest version of some package (like moving from Newtonsoft.Json 8.0.0 to 8.0.1 and then to 8.0.2). Because of that exist the syntax in packages like ^2.6.0 or ~2.6.0. There are exist tools like ncu, which one starts automatically and so on. GitHub allows fo example to transfer the repository to another location and the old URLs will be automatically redirected to the new location. Npm have at least deprecate command and I don't know the practice that one renames the old packages to another name. On the other side ASP.NET team makes many renaming of assemblies, which had no problem before the publishing the assembly as the package.

In any way I wanted just to give an advice on the problem, which I see, but the ASP.NET team (NuGet team) decide of cause yourself what should be implemented and what not. Thanks your your answer.

[StingyJack]

For anyone else finding this issue and wanting this as a feature, you can do a pseudo redirection by creating one last package version for the old package that only has a readme.txt (explaining the redirect), and that last old package should list the new package info as the only dependency.

Users can then be kept along your intended upgrade path and only have to remove the last old package at some point (but not remove its dependencies).