I know, you should not change the Package ID of a NuGet Package. But I did, because of a big refactoring.
Now I want to know if there is a proper way to define a successor NuGet package.
Old ID in Nuspec: OldLibrary1
New ID in Nuspec/csproj file: Library1
If a user opens the NuGet Package Management window for a Visual Studio Solution and the old package (ID OldLibrary1-1.0.0) is installed, he should see an update/upgrade to package Library1-2.0.0.
Is there a possible way to define this in some way?
By the way I use ProGet as NuGet server.
NuGet recently added deprecation information to it's HTTP protocol, however, as far as I know, only nuget.org has implemented it (it's very new, NuGet 5.3, Visual Studio 16.3). If your private nuget server (Proget) hasn't implemented it yet, you can try contacting the developers and ask them to implement it.
Otherwise the best option I've heard about is to create a new version of your old library, do not include any assemblies in it, just have a NuGet dependency on your new package id.
The issue with this is if your package consumer is using PackageReference, Visual Studio's upgrade experience isn't yet great, because when you release a new version of your new package, people getting it as a transitive dependency of your old package won't be notified about the available upgrade. An option to work around this is to include a MSBuild targets file which displays a build warning on every build, telling them to install the new package and uninstall the old package. People who ignore warnings won't see it, so if you want to be extreme, make it an error instead, but it helps get the message out.