New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Packages that share dependencies with Microsoft.AspNetCore.App cannot reference patch versions #1180

Closed
natemcmaster opened this Issue May 25, 2018 · 33 comments

Comments

Projects
None yet
7 participants
@natemcmaster
Member

natemcmaster commented May 25, 2018

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.

error NU1107: Version conflict detected for Microsoft.AspNetCore.Authorization. Reference the package directly from the project to resolve this issue.
error NU1107:  MyApp-> Microsoft.AspNetCore.Mvc.Testing 2.1.1 -> Microsoft.AspNetCore.Mvc.Core 2.1.1 -> Microsoft.AspNetCore.Authorization.Policy 2.1.1 -> Microsoft.AspNetCore.Authorization (>= 2.1.1)
error NU1107:  MyApp-> Microsoft.AspNetCore.App 2.1.0 -> Microsoft.AspNetCore.Authorization (= 2.1.0).

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)

  • Lift version constraints on Microsoft.AspNetCore.App
  • Introduce a new target framework for aspnetcore
  • Ensure packages that share dependencies with Microsoft.AspNetCore.App never reference anything higher than the base line (see Details)

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)

Package ID Version
Microsoft.AspNet.WebApi.Client 5.2.4
Microsoft.AspNetCore 2.1.0
Microsoft.AspNetCore.Antiforgery 2.1.0
Microsoft.AspNetCore.Authentication 2.1.0
Microsoft.AspNetCore.Authentication.Abstractions 2.1.0
Microsoft.AspNetCore.Authentication.Cookies 2.1.0
Microsoft.AspNetCore.Authentication.Core 2.1.0
Microsoft.AspNetCore.Authentication.Facebook 2.1.0
Microsoft.AspNetCore.Authentication.Google 2.1.0
Microsoft.AspNetCore.Authentication.JwtBearer 2.1.0
Microsoft.AspNetCore.Authentication.MicrosoftAccount 2.1.0
Microsoft.AspNetCore.Authentication.OAuth 2.1.0
Microsoft.AspNetCore.Authentication.OpenIdConnect 2.1.0
Microsoft.AspNetCore.Authentication.Twitter 2.1.0
Microsoft.AspNetCore.Authentication.WsFederation 2.1.0
Microsoft.AspNetCore.Authorization 2.1.0
Microsoft.AspNetCore.Authorization.Policy 2.1.0
Microsoft.AspNetCore.Connections.Abstractions 2.1.0
Microsoft.AspNetCore.CookiePolicy 2.1.0
Microsoft.AspNetCore.Cors 2.1.0
Microsoft.AspNetCore.Cryptography.Internal 2.1.0
Microsoft.AspNetCore.Cryptography.KeyDerivation 2.1.0
Microsoft.AspNetCore.DataProtection 2.1.0
Microsoft.AspNetCore.DataProtection.Abstractions 2.1.0
Microsoft.AspNetCore.DataProtection.Extensions 2.1.0
Microsoft.AspNetCore.Diagnostics 2.1.0
Microsoft.AspNetCore.Diagnostics.Abstractions 2.1.0
Microsoft.AspNetCore.Diagnostics.EntityFrameworkCore 2.1.0
Microsoft.AspNetCore.HostFiltering 2.1.0
Microsoft.AspNetCore.Hosting 2.1.0
Microsoft.AspNetCore.Hosting.Abstractions 2.1.0
Microsoft.AspNetCore.Hosting.Server.Abstractions 2.1.0
Microsoft.AspNetCore.Html.Abstractions 2.1.0
Microsoft.AspNetCore.Http 2.1.0
Microsoft.AspNetCore.Http.Abstractions 2.1.0
Microsoft.AspNetCore.Http.Connections 1.0.0
Microsoft.AspNetCore.Http.Connections.Common 1.0.0
Microsoft.AspNetCore.Http.Extensions 2.1.0
Microsoft.AspNetCore.Http.Features 2.1.0
Microsoft.AspNetCore.HttpOverrides 2.1.0
Microsoft.AspNetCore.HttpsPolicy 2.1.0
Microsoft.AspNetCore.Identity 2.1.0
Microsoft.AspNetCore.Identity.EntityFrameworkCore 2.1.0
Microsoft.AspNetCore.Identity.UI 2.1.0
Microsoft.AspNetCore.JsonPatch 2.1.0
Microsoft.AspNetCore.Localization 2.1.0
Microsoft.AspNetCore.Localization.Routing 2.1.0
Microsoft.AspNetCore.MiddlewareAnalysis 2.1.0
Microsoft.AspNetCore.Mvc 2.1.0
Microsoft.AspNetCore.Mvc.Abstractions 2.1.0
Microsoft.AspNetCore.Mvc.Analyzers 2.1.0
Microsoft.AspNetCore.Mvc.ApiExplorer 2.1.0
Microsoft.AspNetCore.Mvc.Core 2.1.0
Microsoft.AspNetCore.Mvc.Cors 2.1.0
Microsoft.AspNetCore.Mvc.DataAnnotations 2.1.0
Microsoft.AspNetCore.Mvc.Formatters.Json 2.1.0
Microsoft.AspNetCore.Mvc.Formatters.Xml 2.1.0
Microsoft.AspNetCore.Mvc.Localization 2.1.0
Microsoft.AspNetCore.Mvc.Razor 2.1.0
Microsoft.AspNetCore.Mvc.Razor.Extensions 2.1.0
Microsoft.AspNetCore.Mvc.Razor.ViewCompilation 2.1.0
Microsoft.AspNetCore.Mvc.RazorPages 2.1.0
Microsoft.AspNetCore.Mvc.TagHelpers 2.1.0
Microsoft.AspNetCore.Mvc.ViewFeatures 2.1.0
Microsoft.AspNetCore.NodeServices 2.1.0
Microsoft.AspNetCore.Owin 2.1.0
Microsoft.AspNetCore.Razor 2.1.0
Microsoft.AspNetCore.Razor.Design 2.1.0
Microsoft.AspNetCore.Razor.Language 2.1.0
Microsoft.AspNetCore.Razor.Runtime 2.1.0
Microsoft.AspNetCore.ResponseCaching 2.1.0
Microsoft.AspNetCore.ResponseCaching.Abstractions 2.1.0
Microsoft.AspNetCore.ResponseCompression 2.1.0
Microsoft.AspNetCore.Rewrite 2.1.0
Microsoft.AspNetCore.Routing 2.1.0
Microsoft.AspNetCore.Routing.Abstractions 2.1.0
Microsoft.AspNetCore.Server.HttpSys 2.1.0
Microsoft.AspNetCore.Server.IISIntegration 2.1.0
Microsoft.AspNetCore.Server.Kestrel 2.1.0
Microsoft.AspNetCore.Server.Kestrel.Core 2.1.0
Microsoft.AspNetCore.Server.Kestrel.Https 2.1.0
Microsoft.AspNetCore.Server.Kestrel.Transport.Abstractions 2.1.0
Microsoft.AspNetCore.Server.Kestrel.Transport.Sockets 2.1.0
Microsoft.AspNetCore.Session 2.1.0
Microsoft.AspNetCore.SignalR 1.0.0
Microsoft.AspNetCore.SignalR.Common 1.0.0
Microsoft.AspNetCore.SignalR.Core 1.0.0
Microsoft.AspNetCore.SignalR.Protocols.Json 1.0.0
Microsoft.AspNetCore.SpaServices 2.1.0
Microsoft.AspNetCore.SpaServices.Extensions 2.1.0
Microsoft.AspNetCore.StaticFiles 2.1.0
Microsoft.AspNetCore.WebSockets 2.1.0
Microsoft.AspNetCore.WebUtilities 2.1.0
Microsoft.CodeAnalysis.Razor 2.1.0
Microsoft.EntityFrameworkCore 2.1.0
Microsoft.EntityFrameworkCore.Abstractions 2.1.0
Microsoft.EntityFrameworkCore.Analyzers 2.1.0
Microsoft.EntityFrameworkCore.Design 2.1.0
Microsoft.EntityFrameworkCore.InMemory 2.1.0
Microsoft.EntityFrameworkCore.Relational 2.1.0
Microsoft.EntityFrameworkCore.SqlServer 2.1.0
Microsoft.EntityFrameworkCore.Tools 2.1.0
Microsoft.Extensions.Caching.Abstractions 2.1.0
Microsoft.Extensions.Caching.Memory 2.1.0
Microsoft.Extensions.Caching.SqlServer 2.1.0
Microsoft.Extensions.Configuration 2.1.0
Microsoft.Extensions.Configuration.Abstractions 2.1.0
Microsoft.Extensions.Configuration.Binder 2.1.0
Microsoft.Extensions.Configuration.CommandLine 2.1.0
Microsoft.Extensions.Configuration.EnvironmentVariables 2.1.0
Microsoft.Extensions.Configuration.FileExtensions 2.1.0
Microsoft.Extensions.Configuration.Ini 2.1.0
Microsoft.Extensions.Configuration.Json 2.1.0
Microsoft.Extensions.Configuration.KeyPerFile 2.1.0
Microsoft.Extensions.Configuration.UserSecrets 2.1.0
Microsoft.Extensions.Configuration.Xml 2.1.0
Microsoft.Extensions.DependencyInjection 2.1.0
Microsoft.Extensions.DependencyInjection.Abstractions 2.1.0
Microsoft.Extensions.DiagnosticAdapter 2.1.0
Microsoft.Extensions.FileProviders.Abstractions 2.1.0
Microsoft.Extensions.FileProviders.Composite 2.1.0
Microsoft.Extensions.FileProviders.Embedded 2.1.0
Microsoft.Extensions.FileProviders.Physical 2.1.0
Microsoft.Extensions.FileSystemGlobbing 2.1.0
Microsoft.Extensions.Hosting 2.1.0
Microsoft.Extensions.Hosting.Abstractions 2.1.0
Microsoft.Extensions.Http 2.1.0
Microsoft.Extensions.Identity.Core 2.1.0
Microsoft.Extensions.Identity.Stores 2.1.0
Microsoft.Extensions.Localization 2.1.0
Microsoft.Extensions.Localization.Abstractions 2.1.0
Microsoft.Extensions.Logging 2.1.0
Microsoft.Extensions.Logging.Abstractions 2.1.0
Microsoft.Extensions.Logging.Configuration 2.1.0
Microsoft.Extensions.Logging.Console 2.1.0
Microsoft.Extensions.Logging.Debug 2.1.0
Microsoft.Extensions.Logging.EventSource 2.1.0
Microsoft.Extensions.Logging.TraceSource 2.1.0
Microsoft.Extensions.ObjectPool 2.1.0
Microsoft.Extensions.Options 2.1.0
Microsoft.Extensions.Options.ConfigurationExtensions 2.1.0
Microsoft.Extensions.Primitives 2.1.0
Microsoft.Extensions.WebEncoders 2.1.0
Microsoft.Net.Http.Headers 2.1.0
@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

Current thinking on the baseline dependency version approach:

New dependency versioning rules

  • Any package with <dependency> on a package inside the .App sharedfx MUST NOT reference anything other than 2.1.0
  • No longer cascade dependencies updates

Customer Impact

  • All projects not referencing Microsoft.AspNetCore.App (e.g. .NET Framework, .NET Core console apps)
    • Users must explicitly declare all dependencies, including transitive dependencies, to get latest patch versions, including security updates
  • Projects referencing Microsoft.AspNetCore.App
    • Implicit version remains 2.1.0.
    • No changes to plans for updates to portable apps: security updates should be rolled out by deploying the new aspnet shared runtime
    • No changes to plans for self-contained apps: the web SDK will update for each release to bump the implicit Microsoft.AspNetCore.App version to latest 2.1.x.

Infrastructure impact

We will need significant changes to our build system.

  • Drop our version coherence check
  • Drop our cascading versions
  • Drop ProdCon version updates to partner teams that use anything but Microsoft.AspNetCore.App
  • Drop our CI automation for updating versions in dependencies.props for now
    • Improve our automation to understand how to split fx dependencies vs test dependencies
  • Override default dotnet pack behavior
  • Update all test projects to contain the complete closure of dependencies. They cannot rely on transitive dependencies
  • All aspnet repos must become aware of what is in Microsoft.AspNetCore.App in order to select the right dependency version
  • Split dependencies.props into two sections:
    • Dependency versions to test
    • Dependency to reference in nuspec

cc @muratg @DamianEdwards @davidfowl

Member

natemcmaster commented May 25, 2018

Current thinking on the baseline dependency version approach:

New dependency versioning rules

  • Any package with <dependency> on a package inside the .App sharedfx MUST NOT reference anything other than 2.1.0
  • No longer cascade dependencies updates

Customer Impact

  • All projects not referencing Microsoft.AspNetCore.App (e.g. .NET Framework, .NET Core console apps)
    • Users must explicitly declare all dependencies, including transitive dependencies, to get latest patch versions, including security updates
  • Projects referencing Microsoft.AspNetCore.App
    • Implicit version remains 2.1.0.
    • No changes to plans for updates to portable apps: security updates should be rolled out by deploying the new aspnet shared runtime
    • No changes to plans for self-contained apps: the web SDK will update for each release to bump the implicit Microsoft.AspNetCore.App version to latest 2.1.x.

Infrastructure impact

We will need significant changes to our build system.

  • Drop our version coherence check
  • Drop our cascading versions
  • Drop ProdCon version updates to partner teams that use anything but Microsoft.AspNetCore.App
  • Drop our CI automation for updating versions in dependencies.props for now
    • Improve our automation to understand how to split fx dependencies vs test dependencies
  • Override default dotnet pack behavior
  • Update all test projects to contain the complete closure of dependencies. They cannot rely on transitive dependencies
  • All aspnet repos must become aware of what is in Microsoft.AspNetCore.App in order to select the right dependency version
  • Split dependencies.props into two sections:
    • Dependency versions to test
    • Dependency to reference in nuspec

cc @muratg @DamianEdwards @davidfowl

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

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.

Kestrel.nupkg 2.1.1
  <dependency id=Kestrel.Core version=2.1.0 />

lib/netstandard2.0/Kestrel.dll
   // reference Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.1.0
warning MSB3277: There was a conflict between "Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" and "Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".

Alternatives

  • Replace all ProjectReferences with PackageReferences
  • Don't rev assembly version

cc @davidfowl @anurse @Tratcher

Member

natemcmaster commented May 25, 2018

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.

Kestrel.nupkg 2.1.1
  <dependency id=Kestrel.Core version=2.1.0 />

lib/netstandard2.0/Kestrel.dll
   // reference Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.1.0
warning MSB3277: There was a conflict between "Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60" and "Microsoft.AspNetCore.Server.Kestrel.Core, Version=2.1.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60".

Alternatives

  • Replace all ProjectReferences with PackageReferences
  • Don't rev assembly version

cc @davidfowl @anurse @Tratcher

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 25, 2018

Member

Revving assembly version is required for servicing, so that's a non-starter.

Member

DamianEdwards commented May 25, 2018

Revving assembly version is required for servicing, so that's a non-starter.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

Didn't know that. I thought we only had to rev file version for servicing.

Member

natemcmaster commented May 25, 2018

Didn't know that. I thought we only had to rev file version for servicing.

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards May 25, 2018

Member

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.

Member

DamianEdwards commented May 25, 2018

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

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.

Member

natemcmaster commented May 25, 2018

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.

@davidfowl

This comment has been minimized.

Show comment
Hide comment
@davidfowl

davidfowl May 25, 2018

Member

Repos aren't patch families anymore so each project needs to burn in the version.

Member

davidfowl commented May 25, 2018

Repos aren't patch families anymore so each project needs to burn in the version.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

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

Microsoft.Extension.Options.2.1.999.nupkg
lib/netcoreapp2.1/_._
lib/netstandard2.0/Microsoft.Extension.Options.dll  (version = 2.1.999.0)
build/netcoreapp2.1/Microsoft.Extension.Options.targets
build/netcoreapp2.1/ref/Microsoft.Extension.Options.targets (assembly version = 2.1.0.0)
<!-- 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>
Member

natemcmaster commented May 25, 2018

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

Microsoft.Extension.Options.2.1.999.nupkg
lib/netcoreapp2.1/_._
lib/netstandard2.0/Microsoft.Extension.Options.dll  (version = 2.1.999.0)
build/netcoreapp2.1/Microsoft.Extension.Options.targets
build/netcoreapp2.1/ref/Microsoft.Extension.Options.targets (assembly version = 2.1.0.0)
<!-- 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>
@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

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.

Member

natemcmaster commented May 25, 2018

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 25, 2018

Member

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)

Name Description
(A) Do nothing Sorry world.
(B) Update implicit metapackage version Update the Microsoft.AspNetCore.App version
(C) Baseline dependencies All packages should use the 2.1.0 version of any dependency that is shared with Microsoft.AspNetCore.App
(D) MSBuild References Use targets embedded in the package to manipulate manually the <Reference> items
(E) Platform manifest Write a platform manifest that lists which assemblies are in the shared framework

Scenarios

Name Description
Transitive dependencies If users update only top-level packages, their transitive dependencies are updated, too
.NET Framework Package can be used on .NET Framework projects
NETCore.App Package can be used on a non-web project that targets Microsoft.NETCore.App
AspNetCore.App Package can be used on a web project using the Microsoft.AspNetCore.App shared framework
Tooling Visual Studio, CLI, etc. tooling works well

Comparison

_ Transitive dependencies .NET Framework NETCore.App AspNetCore.App Tooling
(A) Do nothing users lose advantages of trimming users must override all conflicts
(B) Update implicit metapackage version n/a n/a 🤙 deployment to servers that are missing the updated runtime will fail
(C) Baseline dependencies users must manually list and update the complete closure No updates are shown for transitive dependencies. Users will not easily be able to see updates are available
(D) MSBuild References n/a 🤙 Host cannot resolve assembly from NuGet cache, but otherwise 🤙 Requires an update to AspnetCore.App to avoid NuGet conflicts
This does not work with P2P references because PrivateAssets=Build by default.
(E) Platform manifest n/a 🤙 Requires an update to AspnetCore.App to avoid NuGet conflicts, otherwise

Solution details

Update implicit metapackage version (B)

  • On each update to our packages and Microsoft.AspNetCore.App, we ensure the .NET Core SDK updates the implicit package version for Microsoft.AspNetCore.App
  • Down sides: users may see this error when deploying to a server without the update installed
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Users\namc\.dotnet\x64\
  - Installing .NET Core prerequisites might help resolve this problem:
      http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.0 at [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]

Baseline dependencies (C)

  • All packages (not just ours) which share a dependency with Microsoft.AspNetCore.App MUST NOT reference patch versions

See also #1180 (comment)

MSBuild References (D)

  • Create a new version of Microsoft.AspNetCore.App without maximum version constraints
  • Add lib/netcoreapp2.1/_._ to packages in Microsoft.AspNetCore.App so by default this reference is a no-op on .NET Core projects.
  • Use MSBuild targets to add appropriate <Reference> items to add-back the reference conditionally checking for Microsoft.AspNetCore.App's presence

See also this comment: #1180 (comment)

Platform manifest (E)

This approach makes it impossible to override what is in the shared framework.

  • Create a new version of Microsoft.AspNetCore.App without maximum version constraints
  • Update the SDK to include a platform manifest for Microsoft.AspNetCore.App with contents like this
Microsoft.AspNet.WebApi.Client.dll|Microsoft.AspNet.WebApi.Client|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.dll|Microsoft.AspNetCore|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Antiforgery.dll|Microsoft.AspNetCore.Antiforgery|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Authentication.dll|Microsoft.AspNetCore.Authentication|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Authentication.Abstractions.dll|Microsoft.AspNetCore.Authentication.Abstractions|99.99.99.99|99.99.99.99
....
  • Microsoft.NET.Sdk will filter out the reference from the NuGet package in favor of the one in the platform

    Encountered conflict between 'Platform:Microsoft.Extensions.Options.dll' and 'Runtime:C:\Users\namc.nuget\packages\microsoft.extensions.options\2.1.1\lib\netstandard2.0\Microsoft.Extensions.Options.dll'. Choosing 'Platform:Microsoft.Extensions.Options.dll' because AssemblyVersion '99.99.99.99' is greater than '2.1.1.0'.

  • This does not filter what the compiler gets, so we need to add ref/netcoreapp2.1/*.dll files with assembly version 2.1.0.0 so apps crash due to forced downgrade

Member

natemcmaster commented May 25, 2018

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)

Name Description
(A) Do nothing Sorry world.
(B) Update implicit metapackage version Update the Microsoft.AspNetCore.App version
(C) Baseline dependencies All packages should use the 2.1.0 version of any dependency that is shared with Microsoft.AspNetCore.App
(D) MSBuild References Use targets embedded in the package to manipulate manually the <Reference> items
(E) Platform manifest Write a platform manifest that lists which assemblies are in the shared framework

Scenarios

Name Description
Transitive dependencies If users update only top-level packages, their transitive dependencies are updated, too
.NET Framework Package can be used on .NET Framework projects
NETCore.App Package can be used on a non-web project that targets Microsoft.NETCore.App
AspNetCore.App Package can be used on a web project using the Microsoft.AspNetCore.App shared framework
Tooling Visual Studio, CLI, etc. tooling works well

Comparison

_ Transitive dependencies .NET Framework NETCore.App AspNetCore.App Tooling
(A) Do nothing users lose advantages of trimming users must override all conflicts
(B) Update implicit metapackage version n/a n/a 🤙 deployment to servers that are missing the updated runtime will fail
(C) Baseline dependencies users must manually list and update the complete closure No updates are shown for transitive dependencies. Users will not easily be able to see updates are available
(D) MSBuild References n/a 🤙 Host cannot resolve assembly from NuGet cache, but otherwise 🤙 Requires an update to AspnetCore.App to avoid NuGet conflicts
This does not work with P2P references because PrivateAssets=Build by default.
(E) Platform manifest n/a 🤙 Requires an update to AspnetCore.App to avoid NuGet conflicts, otherwise

Solution details

Update implicit metapackage version (B)

  • On each update to our packages and Microsoft.AspNetCore.App, we ensure the .NET Core SDK updates the implicit package version for Microsoft.AspNetCore.App
  • Down sides: users may see this error when deploying to a server without the update installed
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.
  - Check application dependencies and target a framework version installed at:
      C:\Users\namc\.dotnet\x64\
  - Installing .NET Core prerequisites might help resolve this problem:
      http://go.microsoft.com/fwlink/?LinkID=798306&clcid=0x409
  - The .NET Core framework and SDK can be installed from:
      https://aka.ms/dotnet-download
  - The following versions are installed:
      2.1.0 at [C:\Users\namc\.dotnet\x64\shared\Microsoft.AspNetCore.App]

Baseline dependencies (C)

  • All packages (not just ours) which share a dependency with Microsoft.AspNetCore.App MUST NOT reference patch versions

See also #1180 (comment)

MSBuild References (D)

  • Create a new version of Microsoft.AspNetCore.App without maximum version constraints
  • Add lib/netcoreapp2.1/_._ to packages in Microsoft.AspNetCore.App so by default this reference is a no-op on .NET Core projects.
  • Use MSBuild targets to add appropriate <Reference> items to add-back the reference conditionally checking for Microsoft.AspNetCore.App's presence

See also this comment: #1180 (comment)

Platform manifest (E)

This approach makes it impossible to override what is in the shared framework.

  • Create a new version of Microsoft.AspNetCore.App without maximum version constraints
  • Update the SDK to include a platform manifest for Microsoft.AspNetCore.App with contents like this
Microsoft.AspNet.WebApi.Client.dll|Microsoft.AspNet.WebApi.Client|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.dll|Microsoft.AspNetCore|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Antiforgery.dll|Microsoft.AspNetCore.Antiforgery|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Authentication.dll|Microsoft.AspNetCore.Authentication|99.99.99.99|99.99.99.99
Microsoft.AspNetCore.Authentication.Abstractions.dll|Microsoft.AspNetCore.Authentication.Abstractions|99.99.99.99|99.99.99.99
....
  • Microsoft.NET.Sdk will filter out the reference from the NuGet package in favor of the one in the platform

    Encountered conflict between 'Platform:Microsoft.Extensions.Options.dll' and 'Runtime:C:\Users\namc.nuget\packages\microsoft.extensions.options\2.1.1\lib\netstandard2.0\Microsoft.Extensions.Options.dll'. Choosing 'Platform:Microsoft.Extensions.Options.dll' because AssemblyVersion '99.99.99.99' is greater than '2.1.1.0'.

  • This does not filter what the compiler gets, so we need to add ref/netcoreapp2.1/*.dll files with assembly version 2.1.0.0 so apps crash due to forced downgrade

@natemcmaster natemcmaster self-assigned this May 25, 2018

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 26, 2018

Member

Discussed the tradeoffs in person. We think we're going to get the best results from option (E) - platform manifest.

Work items:

  • Add a 2.1.0.0 reference assembly to all patching packages (or v1.0.0.0 in signalR's case)
  • Adjust version constraints in Microsoft.AspNetCore.App to [2.1.0, 2.2.0)
  • Update default implicit version of AspNetCore.App to 2.1.1
  • Construct a platform manifest for all assemblies in the AspNetCore.App sharedfx
    • Let's cap the manifest's effect for now at 2.1.999.0. e.g. Microsoft.AspNetCore.dll|Microsoft.AspNetCore|2.1.999.0|2.1.999.0
  • Only use the manifest conflict resolution if `$(MicrosoftNETPlatformLibrary) == 'Microsoft.AspNetCore.App' AND $(SelfContained) != 'true'
Member

natemcmaster commented May 26, 2018

Discussed the tradeoffs in person. We think we're going to get the best results from option (E) - platform manifest.

Work items:

  • Add a 2.1.0.0 reference assembly to all patching packages (or v1.0.0.0 in signalR's case)
  • Adjust version constraints in Microsoft.AspNetCore.App to [2.1.0, 2.2.0)
  • Update default implicit version of AspNetCore.App to 2.1.1
  • Construct a platform manifest for all assemblies in the AspNetCore.App sharedfx
    • Let's cap the manifest's effect for now at 2.1.999.0. e.g. Microsoft.AspNetCore.dll|Microsoft.AspNetCore|2.1.999.0|2.1.999.0
  • Only use the manifest conflict resolution if `$(MicrosoftNETPlatformLibrary) == 'Microsoft.AspNetCore.App' AND $(SelfContained) != 'true'
@ajcvickers

This comment has been minimized.

Show comment
Hide comment
@ajcvickers
Member

ajcvickers commented May 29, 2018

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 30, 2018

Member

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 [2.1.1, 2.2.0). This removes the guardrails we wanted which would prevent users from upgrading out of the sharedfx, but we don't see a sane way to implement this without wrecking the user experience for NuGet packages.

Member

natemcmaster commented May 30, 2018

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 [2.1.1, 2.2.0). This removes the guardrails we wanted which would prevent users from upgrading out of the sharedfx, but we don't see a sane way to implement this without wrecking the user experience for NuGet packages.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster May 31, 2018

Member

For 2.1.1, let's solve the version constraint issue. #1186. I've opened #1192 to investigate more how we can re-add the guardrails to help users avoid hoisting out of the shared framework.

Member

natemcmaster commented May 31, 2018

For 2.1.1, let's solve the version constraint issue. #1186. I've opened #1192 to investigate more how we can re-add the guardrails to help users avoid hoisting out of the shared framework.

@simeyla

This comment has been minimized.

Show comment
Hide comment
@simeyla

simeyla Jun 22, 2018

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 commented Jun 22, 2018

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jun 25, 2018

Member

@simeyla can you open a new issue with steps to reproduce this error?

Member

natemcmaster commented Jun 25, 2018

@simeyla can you open a new issue with steps to reproduce this error?

@DamianEdwards

This comment has been minimized.

Show comment
Hide comment
@DamianEdwards

DamianEdwards Jun 25, 2018

Member

@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

Member

DamianEdwards commented Jun 25, 2018

@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

@simeyla

This comment has been minimized.

Show comment
Hide comment
@simeyla

simeyla Jun 25, 2018

@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 dotnet --info.

  • Create dotnet new project - which gives me 2.1.0
  • Install package NodeServices which automatically gave me 2.1.1
  • Got all sorts of errors about project being locked

The only solution was to manually specify RuntimeFrameworkVersion in .csproj

 <PropertyGroup>
   <TargetFramework>netcoreapp2.1</TargetFramework>
   <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> 

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 commented Jun 25, 2018

@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 dotnet --info.

  • Create dotnet new project - which gives me 2.1.0
  • Install package NodeServices which automatically gave me 2.1.1
  • Got all sorts of errors about project being locked

The only solution was to manually specify RuntimeFrameworkVersion in .csproj

 <PropertyGroup>
   <TargetFramework>netcoreapp2.1</TargetFramework>
   <RuntimeFrameworkVersion>2.1.1</RuntimeFrameworkVersion> 

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jun 26, 2018

Member

@simeyla a repro project would be really helpful. All I need is the .csproj file so I can run restore and see what happens.

Member

natemcmaster commented Jun 26, 2018

@simeyla a repro project would be really helpful. All I need is the .csproj file so I can run restore and see what happens.

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

I started a new project Friday, and when I try and add in Microsoft.EntityFrameworkCore, I get the error:

  • error NU1107: Version conflict detected for Microsoft.EntityFrameworkCore.Abstractions. Reference the package directly from the project to resolve this issue.

  • error NU1107: coreapp -> Microsoft.EntityFrameworkCore 2.1.1 -> Microsoft.EntityFrameworkCore.Abstractions (>= 2.1.1)

  • Microsoft.AspNetCore.App 2.1.0 -> Microsoft.EntityFrameworkCore.Abstractions (= 2.1.0)
    I am on 2.1.3.
    Is there a better way to deal with this?

dcb99 commented Jul 9, 2018

I started a new project Friday, and when I try and add in Microsoft.EntityFrameworkCore, I get the error:

  • error NU1107: Version conflict detected for Microsoft.EntityFrameworkCore.Abstractions. Reference the package directly from the project to resolve this issue.

  • error NU1107: coreapp -> Microsoft.EntityFrameworkCore 2.1.1 -> Microsoft.EntityFrameworkCore.Abstractions (>= 2.1.1)

  • Microsoft.AspNetCore.App 2.1.0 -> Microsoft.EntityFrameworkCore.Abstractions (= 2.1.0)
    I am on 2.1.3.
    Is there a better way to deal with this?

@poke

This comment has been minimized.

Show comment
Hide comment
@poke

poke Jul 9, 2018

@dcb99 Only reference Microsoft.AspNetCore.App without specifying a version. EF Core is already included in there as well, so you don’t need something else.

poke commented Jul 9, 2018

@dcb99 Only reference Microsoft.AspNetCore.App without specifying a version. EF Core is already included in there as well, so you don’t need something else.

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

Definitely only referencing Microsoft.AspNetCore.App, no version specified. I guess I just missed EF Core being included. Identity is now part of 2.1.1 also?

dcb99 commented Jul 9, 2018

Definitely only referencing Microsoft.AspNetCore.App, no version specified. I guess I just missed EF Core being included. Identity is now part of 2.1.1 also?

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jul 9, 2018

Member

+1 to what @poke said. Also, I recommend putting an explicit version on Microsoft.AspNetCore.App (see aspnet/Home#3292). If you change your project to this, the NU1107 error should go away.

<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.1" />

⚠️ As a result of updating Microsoft.AspNetCore.App to 2.1.1, you will also need to make sure to install the 2.1.1 runtime. https://aka.ms/dotnet-download

Member

natemcmaster commented Jul 9, 2018

+1 to what @poke said. Also, I recommend putting an explicit version on Microsoft.AspNetCore.App (see aspnet/Home#3292). If you change your project to this, the NU1107 error should go away.

<PackageReference Include="Microsoft.AspNetCore.App" Version="2.1.1" />

⚠️ As a result of updating Microsoft.AspNetCore.App to 2.1.1, you will also need to make sure to install the 2.1.1 runtime. https://aka.ms/dotnet-download

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

@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.
Did I miss it somewhere in the documentation that Entity Framework Core is baked in to .net core now? I've done more developing with the .net framework so a lot of these issues with core are new to me.

dcb99 commented Jul 9, 2018

@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.
Did I miss it somewhere in the documentation that Entity Framework Core is baked in to .net core now? I've done more developing with the .net framework so a lot of these issues with core are new to me.

@poke

This comment has been minimized.

Show comment
Hide comment
@poke

poke Jul 9, 2018

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.

poke commented Jul 9, 2018

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.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jul 9, 2018

Member

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 aspnet/Home#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

Member

natemcmaster commented Jul 9, 2018

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 aspnet/Home#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

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

@natemcmaster OK, I've explicitly referenced a version number for Microsoft.AspNetCore.App. Now when I try and scaffold out entity classes from the CLI, this is the error:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.

Which is strange, because when I run dotnet --info, I see 2.1.1 installed:

.NET Command Line Tools (2.1.300-preview1-008174)

Product Information:
Version: 2.1.300-preview1-008174
Commit SHA-1 hash: b8df89a54f

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.13
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/2.1.300-preview1-008174/

Host (useful for support):
Version: 2.1.1
Commit: 6985b9f684

.NET Core SDKs installed:
2.1.300-preview1-008174 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0-preview1-final [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0-preview1-final [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.0-preview1-26216-03 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

I am not sure where I'm going wrong here.

dcb99 commented Jul 9, 2018

@natemcmaster OK, I've explicitly referenced a version number for Microsoft.AspNetCore.App. Now when I try and scaffold out entity classes from the CLI, this is the error:

It was not possible to find any compatible framework version
The specified framework 'Microsoft.AspNetCore.App', version '2.1.1' was not found.

Which is strange, because when I run dotnet --info, I see 2.1.1 installed:

.NET Command Line Tools (2.1.300-preview1-008174)

Product Information:
Version: 2.1.300-preview1-008174
Commit SHA-1 hash: b8df89a54f

Runtime Environment:
OS Name: Mac OS X
OS Version: 10.13
OS Platform: Darwin
RID: osx.10.12-x64
Base Path: /usr/local/share/dotnet/sdk/2.1.300-preview1-008174/

Host (useful for support):
Version: 2.1.1
Commit: 6985b9f684

.NET Core SDKs installed:
2.1.300-preview1-008174 [/usr/local/share/dotnet/sdk]

.NET Core runtimes installed:
Microsoft.AspNetCore.All 2.1.0-preview1-final [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.All]
Microsoft.AspNetCore.App 2.1.0-preview1-final [/usr/local/share/dotnet/shared/Microsoft.AspNetCore.App]
Microsoft.NETCore.App 2.1.0-preview1-26216-03 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]
Microsoft.NETCore.App 2.1.1 [/usr/local/share/dotnet/shared/Microsoft.NETCore.App]

I am not sure where I'm going wrong here.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jul 9, 2018

Member

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

image

Member

natemcmaster commented Jul 9, 2018

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

image

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jul 9, 2018

Member

By the way, I'm expecting changes to the download page to go live soon which should make this more obvious.

Member

natemcmaster commented Jul 9, 2018

By the way, I'm expecting changes to the download page to go live soon which should make this more obvious.

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

@natemcmaster I'm on a Mac though...

dcb99 commented Jul 9, 2018

@natemcmaster I'm on a Mac though...

@dcb99

This comment has been minimized.

Show comment
Hide comment
@dcb99

dcb99 Jul 9, 2018

@natemcmaster Thanks. I swear I had installed the newest SDK and runtimes Saturday. Thanks for your time.

dcb99 commented Jul 9, 2018

@natemcmaster Thanks. I swear I had installed the newest SDK and runtimes Saturday. Thanks for your time.

@natemcmaster

This comment has been minimized.

Show comment
Hide comment
@natemcmaster

natemcmaster Jul 9, 2018

Member

Happy to help :)

Member

natemcmaster commented Jul 9, 2018

Happy to help :)

natemcmaster added a commit that referenced this issue Jul 13, 2018

Implement patch policies per repo and set default to ProductChangesOnly
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: aspnet/Universe#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.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment