Update the migration docs to remove instructions for versionless package references #7543
Conversation
There was a problem hiding this comment.
@natemcmaster Try my lingo updates on the last commit but confirm I didn't modify your meaning and intent.
|
Still not 100% on "It's difficult to use" ... feels like it needs a little something more concrete there. |
aspnetcore/migration/20_21.md
Outdated
|
|
||
| Known issues for projects targeting the shared runtime: | ||
|
|
||
| * It's difficult to use the 2.1.0 `Microsoft.AspNetCore.App` package with Entity Framework Core 2.1.1. The recommended solution is to upgrade `Microsoft.AspNetCore.App` to 2.1.1. For more information, see [Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions](https://github.com/aspnet/Universe/issues/1180). |
There was a problem hiding this comment.
What about "Using Microsoft.AspNetCore.App 2.1.0 with Entity Framework Core 2.1.1 causes NuGet restore failures due to package conflicts."?
aspnetcore/migration/20_21.md
Outdated
| @@ -55,7 +55,7 @@ The version specified by the package reference is the *minimum required* version | |||
|
|
|||
| Known issues for projects targeting the shared runtime: | |||
|
|
|||
| * It's difficult to use the 2.1.0 `Microsoft.AspNetCore.App` package with Entity Framework Core 2.1.1. The recommended solution is to upgrade `Microsoft.AspNetCore.App` to 2.1.1. For more information, see [Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions](https://github.com/aspnet/Universe/issues/1180). | |||
| * Using `Microsoft.AspNetCore.App` 2.1.0 with Entity Framework Core 2.1.1 causes NuGet restore failures due to package conflicts.. The recommended solution is to upgrade `Microsoft.AspNetCore.App` to 2.1.1. For more information, see [Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions](https://github.com/aspnet/Universe/issues/1180). | |||
There was a problem hiding this comment.
DOE! Bart! lol ....... I do crap like that all the time. If @scottaddie had a nickel for every one of my GooberRex foul-ups, he'd be a 💰 rich man indeed! 💰
|
Thanks for the language updates @guardrex. Changes LGTM. |
aspnetcore/migration/20_21.md
Outdated
| * Replace the version specified "Microsoft.AspNetCore.All" package reference with the versionless "Microsoft.AspNetCore.App" package reference. You may need to add dependencies that were removed from "Microsoft.AspNetCore.All". See [Migrating from Microsoft.AspNetCore.All to Microsoft.AspNetCore.App](xref:fundamentals/metapackage#migrate) and [Microsoft.AspNetCore.App metapackage](xref:fundamentals/metapackage-app). If you're targetting the .NET Framework: | ||
|
|
||
| * Add individual package references instead of a meta package reference. | ||
| * Change the target framework to 2.1, `<TargetFramework>netcoreapp2.1</TargetFramework>`. |
aspnetcore/migration/20_21.md
Outdated
| - `MyApp` has a package reference to `Microsoft.AspNetCore.App`. | ||
| - `MyApp.Tests` has a project reference to `MyApp.csproj`. | ||
|
|
||
| Add a add a package reference for `Microsoft.AspNetCore.App` to `MyApp.Tests`. For more information, see [Integration testing is hard to set up and may break on shared framework servicing](https://github.com/aspnet/Home/issues/3156). |
There was a problem hiding this comment.
@natemcmaster See what I mean? 😄 That's ok ... more free 🍺 for Scott.
|
Updated |
aspnetcore/migration/20_21.md
Outdated
| * Update each package reference to 2.1. | ||
| * Remove all references to `<DotNetCliToolReference>` elements for "Microsoft.AspNetCore", "Microsoft.VisualStudio", and "Microsoft.EntityFrameworkCore" packages. These tools have been replaced by global tools. | ||
| * Remove all references to **<DotNetCliToolReference>** elements for `Microsoft.AspNetCore`, `Microsoft.VisualStudio`, and `Microsoft.EntityFrameworkCore` packages. These tools have been replaced by global tools. |
There was a problem hiding this comment.
Are these package name prefixes? If so, let's state that to make it clearer.
There was a problem hiding this comment.
I'm not sure I've seen a format of ... for example ... Microsoft.VisualStudio.*.
Can it just read ...
Remove all references to <DotNetCliToolReference> elements.
There was a problem hiding this comment.
It would be better to be more specific. Only these can be removed without further action
* Microsoft.EntityFrameworkCore.Tools.DotNet
* Microsoft.Extensions.Caching.SqlConfig.Tools
* Microsoft.Extensions.SecretManager.Tools
* Microsoft.DotNet.Watcher.Tools
You can also remove a DotNetCliToolReference to Microsoft.VisualStudio.Web.CodeGeneration.Tools can be removed if you also run dotnet tool install -g dotnet-aspnet-codegenerator to replace it.
|
I update the DotNetCliToolReference section |
|
@natemcmaster Thank you for your help! |
|
I'll get the samples done by EOD. |
|
@natemcmaster Question tho: With roll-forward behavior, you still want 2.1.1, or just 2.1.0 and let roll-forward bits do the rest? |
|
If the 2.1.0 package didn't suffer from this issue, I would recommend that instead. I still recommend 2.1.1 as the baseline for the best user experience. |
|
Ok, sounds good. |
…on Microsoft.AspNetCore.App (#8715) Reverts #7543 See dotnet/aspnetcore#3292 (comment) for context
Follow up to #7540
I found one more reference to versionless packages. I've updated the migration guide to remove this recommendation, and also briefly mentioned the most common issues users have encountered so far.