Skip to content
This repository has been archived by the owner. It is now read-only.

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

natemcmaster opened this issue May 25, 2018 · 33 comments


Copy link

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.


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 natemcmaster added bug cost: XL labels May 25, 2018
@natemcmaster natemcmaster added this to the 2.1.1 milestone May 25, 2018
Copy link
Contributor Author

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

Copy link
Contributor Author

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


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

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


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

cc @davidfowl @anurse @Tratcher

Copy link

DamianEdwards commented May 25, 2018

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

Copy link
Contributor Author

natemcmaster commented May 25, 2018

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

Copy link

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.

Copy link
Contributor Author

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.

Copy link

davidfowl commented May 25, 2018

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

Copy link
Contributor Author

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

lib/netstandard2.0/Microsoft.Extension.Options.dll  (version = 2.1.999.0)
build/netcoreapp2.1/ref/Microsoft.Extension.Options.targets (assembly version =
<!-- build/netcoreapp2.1/Microsoft.Extension.Options.targets -->
  <ItemGroup Condition="'$(_AspNetCoreAppSharedFxIsEnabled)' == 'true'">
    <Reference Include="$(MSBuildThisFileDirectory)ref\Microsoft.Extension.Options.dll">
  <ItemGroup Condition="'$(_AspNetCoreAppSharedFxIsEnabled)' != 'true'">
    <Reference Include="$(MSBuildThisFileDirectory)..\lib\netstandard2.0\Microsoft.Extension.Options.dll">

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.


(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


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


_ 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:
  - Installing .NET Core prerequisites might help resolve this problem:
  - The .NET Core framework and SDK can be installed from:
  - 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.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 '' is greater than ''.

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

@natemcmaster natemcmaster self-assigned this May 25, 2018
Copy link
Contributor Author

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 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'

Copy link

ajcvickers commented May 29, 2018

/cc @bricelam @divega

Copy link
Contributor Author

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.

Copy link
Contributor Author

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.

Copy link

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.

Copy link
Contributor Author

natemcmaster commented Jun 25, 2018

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

Copy link

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

Copy link

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


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.

Copy link
Contributor Author

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.

Copy link

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?

Copy link

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.

Copy link

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?

Copy link
Contributor Author

natemcmaster commented Jul 9, 2018

+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" />

⚠️ 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.

Copy link

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.

Copy link

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.

Copy link
Contributor Author

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 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 by looking at the "Dependencies" list:

Copy link

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.

Copy link
Contributor Author

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


Copy link
Contributor Author

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.

Copy link

dcb99 commented Jul 9, 2018

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

Copy link
Contributor Author

natemcmaster commented Jul 9, 2018

Copy link

dcb99 commented Jul 9, 2018

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

Copy link
Contributor Author

natemcmaster commented Jul 9, 2018

Happy to help :)

natemcmaster pushed a commit that referenced this issue Jul 13, 2018
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.
mklein994 added a commit to mklein994/DatingApp that referenced this issue Sep 29, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
None yet

No branches or pull requests

7 participants