Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions #1180
Comments
|
Current thinking on the baseline dependency version approach: New dependency versioning rules
Customer Impact
Infrastructure impactWe will need significant changes to our build system.
|
|
Thought about this more. We probably shouldn't handcraft a nuspec to force downgrade dependencies in generated nuspec to "2.1.0" for ProjectReferences. It would lead to a mismatch of assembly reference and dependency versions e.g. Alternatives
|
|
Revving assembly version is required for servicing, so that's a non-starter. |
|
Didn't know that. I thought we only had to rev file version for servicing. |
|
The runtime's loading policy on Core uses assembly versioning for tracking and substituting patched versions. On NetFx the same is used for tracking and the GAC is used for substitution, which uses assembly versioning. |
|
Oh right. Seems like the only viable option is replacing all ProjectReferences with PackageReferences. This is unfortunate -- it introduces a bunch of pain for devs working on patches. |
|
Repos aren't patch families anymore so each project needs to burn in the version. |
|
Just kicking around other ideas. I haven't fully tested, but I believe an approach using MSBuild targets to fake the behavior of a custom target framework may work. Packages in the AspNetCore.App sharedfx (such as Microsoft.Extension.Options) look like this <!-- build/netcoreapp2.1/Microsoft.Extension.Options.targets -->
<Project>
<ItemGroup Condition="'$(_AspNetCoreAppSharedFxIsEnabled)' == 'true'">
<Reference Include="$(MSBuildThisFileDirectory)ref\Microsoft.Extension.Options.dll">
<Visible>false</Visible>
<NuGetPackageId>Microsoft.Extension.Options</NuGetPackageId>
<NuGetPackageVersion>2.1.999</NuGetPackageVersion>
<Facade>true</Facade>
<Private>false</Private>
</Reference>
</ItemGroup>
<ItemGroup Condition="'$(_AspNetCoreAppSharedFxIsEnabled)' != 'true'">
<Reference Include="$(MSBuildThisFileDirectory)..\lib\netstandard2.0\Microsoft.Extension.Options.dll">
<Visible>false</Visible>
<NuGetPackageId>Microsoft.Extension.Options</NuGetPackageId>
<NuGetPackageVersion>2.1.999</NuGetPackageVersion>
<Private>false</Private>
</Reference>
</ItemGroup>
</Project> |
|
Failed to add this, but along with ⬆️ that suggestion, I mean to add -- we could lift the max version constraint on Microsoft.AspNetCore.App dependencies. It would require bumping the implicit version to 2.1.1 to make up for doing this wrong in 2.1.0, but it may worth some short-term pain for long-term gains. |
|
Ok, I played with this more. Here are my findings. To make the comparison easier, I'm going to describe solutions to the original problem and scenarios. Solutions(details below)
Scenarios
Comparison
Solution detailsUpdate implicit metapackage version (B)
Baseline dependencies (C)
See also #1180 (comment) MSBuild References (D)
See also this comment: #1180 (comment) Platform manifest (E)This approach makes it impossible to override what is in the shared framework.
|
|
Discussed the tradeoffs in person. We think we're going to get the best results from option (E) - platform manifest. Work items:
|
|
Backing off proposal (E) because we're not confident the platform manifest will give us the behavior we want. Also, we don't think we can get all the work done in time to verify this. So, as proposed in #1186, the only fix we think we can get in for 2.1.x is to Adjust version constraints in Microsoft.AspNetCore.App to |
|
I'm never going to understand all this :-/ BTW. I literally just started with a brand new project today, installed NodeServices and now I get NU1608: Detected package version outside of dependency constraint: Microsoft.AspNetCore.App 2.1.0 requires Microsoft.AspNetCore.NodeServices (= 2.1.0) but version Microsoft.AspNetCore.NodeServices 2.1.1 was resolved. |
|
@simeyla can you open a new issue with steps to reproduce this error? |
|
@simeyla make sure you've installed the 2.1.1 (2.1.301) SDK, and removed the version attribute for your package reference to Microsoft.AspNetCore.App |
|
@natemcmaster I won't be able to gather all the information right now to create a proper issue, but here's a quick summary of what I did. These steps are from last night when I created a second new project and had the same issue. As @DamianEdwards mentions I had 2.1.1 (2.1.301) SDK installed, but in addition I had to install the 2.1.1 runtime so as to see it listed under
The only solution was to manually specify RuntimeFrameworkVersion in .csproj And also The first time I did it I uninstalled NodeServices, but I believe that isn't necessary and just updating the versions is sufficient. I figured you were already working on a better explanation - I see I was one of the first downloads for 2.1.1 (which was triggered when I installed NodeServices) and so I see this becoming a major issue for people very soon. |
|
@simeyla a repro project would be really helpful. All I need is the .csproj file so I can run restore and see what happens. |
|
I started a new project Friday, and when I try and add in Microsoft.EntityFrameworkCore, I get the error:
|
|
@dcb99 Only reference |
|
Definitely only referencing |
|
+1 to what @poke said. Also, I recommend putting an explicit version on Microsoft.AspNetCore.App (see dotnet/aspnetcore#3292). If you change your project to this, the NU1107 error should go away. <PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.1" /> |
|
@poke recommends, NOT specifying a version, but @natemcmaster you DO recommend it? As long as the errors go away I will be happy. I've got the latest runtime installed. |
|
The current recommendation is to leave the version out to make the installed framework choose the active version. At the moment this is still the quickest way to get you up and running with all correct dependencies. This recommendation is going to change really soon though, so you'll probably have to specify a version again (per reasons in that linked issue). That's all in a rather fluid state though, and things aren't ultimately decided yet. |
|
Yes, I recommend specifying a version. In 2.1.0 and 2.1.1, we thought making it possible to leave off the Version attribute would help users, but it will more likely cause issues in the long run. After further review of issues like this, we're changing course and recommeding you use PackageReference normally (See dotnet/aspnetcore#3292 for more details why). I'm working on docs and an announcement to clarify this to our customers. Unless something crazy happens in the next 2 days, this will be the new, official as of the 2.1.3 runtime update (due out later this summer). Also, yes, there are some Microsoft.EntityFrameworkCore packages in the Microsoft.AspNetCore.App runtime. You can view the full list of things it brings in on NuGet.org by looking at the "Dependencies" list: https://www.nuget.org/packages/microsoft.aspnetcore.app |
|
@natemcmaster OK, I've explicitly referenced a version number for
Which is strange, because when I run
I am not sure where I'm going wrong here. |
|
The names are similar enough that it's easy to make this mistake. You have Microsoft.NETCore.App 2.1.1. You also need Microsoft.AspNetCore.App 2.1.1. You can get this from https://aka.ms/dotnet-download
|
|
By the way, I'm expecting changes to the download page to go live soon which should make this more obvious. |
|
@natemcmaster I'm on a Mac though... |
|
@natemcmaster Thanks. I swear I had installed the newest SDK and runtimes Saturday. Thanks for your time. |
|
Happy to help :) |
Our policy since 1.0.0 has been to always cascade version updates in the packages we own. e.g. if Logging has a product change in 2.1.x, then Kestrel, EF Core, Mvc, etc also re-ship with the updated Logging dependency. This has been done for a variety of reasons: * NuGet does not show updates for transitive dependencies, only direct ones * NuGet does resolves the lowest compatible transitive dependencies * ASP.NET Core ships to both .NET Framework (where transitive dependency version matters) and .NET Core (where it matters less if you use the shared framework) While transitive dependencies is still an important scenario, this practice of always patching has led to bigger issues. * High probability users will unintentionally upgrade out of the shared framework: #3307 * Conflicts with metapackages that attempt to use exact version constraints: #1180 * A quality perception issue: the high volume of new versions in servicing updates with only metadata changes has created the impression that new versions of packages may not be very important. It's also made it appear like there are more issues product than there really are. * High volume of packages changing with only metadata changes. Of the last 301 packages published in a servicing update, only 11 contained actual changes to the implementation assemblies. (3.5%) This change implements a system to verify a new, non-cascading versioning policy for servicing updates. This required changes to repos to pin version variables to that matter per-repo, and to remove some of the restrictions and checks. Incidentally, this should make defining new patches easier because it automatically determines which packages are or are not patching in the release.
All NuGet packages (not just ours, but the entire world) which share a dependency with Microsoft.AspNetCore.App cannot not reference versions of those dependencies higher than the default implicit Microsoft.AspNetCore.App version without introducing a version conflict. When a version conflict exists, the following errors will often occur.
This makes updates in NuGet UI impossible, and updates by hand very difficult. Also, it is not clear from the error messages how a customer should resolve the issue.
Solutions
UPDATE: jump to more detailed analysis: #1180 (comment)
Microsoft.AspNetCore.App 2.1.0 baseline
The following table contains a list of all dependencies of Microsoft.AspNetCore.App 2.1.0. Package authors should adhere to these versions
Table: (open details)
The text was updated successfully, but these errors were encountered: