8

I'm trying to work out the correct way of using the Microsoft.AspNetCore.App meta package.

Visual Studio on building reports that I shouldn't specify a version for the Microsoft.AspNetCore.App meta package.

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

So I replace the above with:

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

The next issue is that any class library projects or packages that my project depends on that contain versioned references to packages that are also included in the Microsoft.AspNetCore.App metapackage break the build because there is a version conflict.

<PackageReference Include="Microsoft.Extensions.Configuration" Version="2.2.0" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.1.1" />
<PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" Version="2.1.1" />

So I remove the versions on these references too:

<PackageReference Include="Microsoft.Extensions.Configuration" />
<PackageReference Include="Microsoft.Extensions.Configuration.Json"  />
<PackageReference Include="Microsoft.Extensions.Options.ConfigurationExtensions" />

Now when I run dotnet restore, I see a warning:

<Project> does not provide an inclusive lower bound for dependency 
Microsoft.Extensions.Configuration. An approximate best match of 
Microsoft.Extensions.Configuration 1.0.0 was resolved.

So now the app builds, but an old and possibly out of date package version is being resolved.

It seems like a bit of an overhead to maintain lower bound versions for all of these packages.

The path of least resistance seems like it might be to just reference the Microsoft.AspNetCore.App package (unversioned) in place of any packages that are contained within the meta package. But then I'm implicitly referencing a lot of unnecessary stuff (150 packages at present). I might want to reuse the class library in a project that is not web facing and so all of the referenced packages seem like inefficient bloat. Also, am I right in thinking that newer versions of Microsoft.AspNetCore.App could break my app when I build in the future?

gbro3n
  • 6,729
  • 9
  • 59
  • 100
  • A single reference to `Microsoft.AspNetCore.App` should be enough. Do you really need the extra references? – Lex Li Mar 14 '19 at 15:16
  • 1
    @LexLi The point is that the class library projects contain the specific Microsoft package references, and it wouldn't be suitable or accurate for them to contain a reference to `Microsoft.AspNetCore.App` – UncleDave Mar 14 '19 at 15:17
  • @LexLi - the issue is that Microsoft.AspNetCore.App contains references to 150, mostly very common packages. It's not unlikely that a class library might want to reference one of them (and as UncleDave says, referencing Microsoft.AspNetCore.App for one library seems very inefficient), and by default the version number is included. When the executing application references Microsoft.AspNetCore.App (unversioned as Visual Studio directs us to do), package version conflicts arise. – gbro3n Mar 15 '19 at 09:01
  • What kind of build failure you get? Usually the package version conflict is reported as a warning and it still works. – Aleš Doganoc Apr 01 '19 at 22:21
  • What's your project's target framework, and what version of the .NET Core SDK are you using to build your project? – yaakov Apr 03 '19 at 04:49

2 Answers2

6

I think you might want to observe the NuGet Version ranges and wildcards notation.

When referring to package dependencies, NuGet supports using interval notation for specifying version ranges, summarized as follows:

+-----------+---------------+-------------------------------------------------------+
| Notation  | Applied rule  |                      Description                      |
+-----------+---------------+-------------------------------------------------------+
| 1.0       | x ≥ 1.0       | Minimum version, inclusive                            |
| (1.0,)    | x > 1.0       | Minimum version, exclusive                            |
| [1.0]     | x == 1.0      | Exact version match                                   |
| (,1.0]    | x ≤ 1.0       | Maximum version, inclusive                            |
| (,1.0)    | x < 1.0       | Maximum version, exclusive                            |
| [1.0,2.0] | 1.0 ≤ x ≤ 2.0 | Exact range, inclusive                                |
| (1.0,2.0) | 1.0 < x < 2.0 | Exact range, exclusive                                |
| [1.0,2.0) | 1.0 ≤ x < 2.0 | Mixed inclusive minimum and exclusive maximum version |
| (1.0)     | invalid       | invalid                                               |
+-----------+---------------+-------------------------------------------------------+

So instead of removing the Version property altogether use a range or wildcard, eg:

Minimum version, inclusive 

<PackageReference Include="Microsoft.Extensions.Configuration.Json" Version="2.1" />

Ref: How to correct dotnet restore warning NU1604, does not contain an inclusive lower bound?

It takes some configuring and I hope Microsoft sort all this out in RTM 3.0 with a wizard to update the dependency tree... Here's a project from 6 months ago it contains a reference to Microsoft.AspNetCORE.Mvc:

enter image description here

Here's a project I'm working on and I had to explicitly reference certain packages (to get ActionResults I had to add 2 specific references.):

enter image description here

Using the NuGet notation allows finely grained libraries when you need it, or future-proof modularity with range/wildcard API updates or you can reference the full kit and caboodle.

Jeremy Thompson
  • 61,933
  • 36
  • 195
  • 321
  • In my **Unit.Test** projects I get this using EF InMemory and Moq. I add EF Core and specifically EFCore * *InMemory/Abstractions/SQLServer* with specific versions, I don't add all `Microsoft.AspNetCORE.Mvc` *.App/All* full. – Jeremy Thompson Apr 08 '19 at 11:56
1

It appears the answer is in the replies. Choose one of these strategies:

  1. Don't reference Microsoft.AspNetCore.App meta-package but instead reference the specific packages that you need. Best for distributed libraries.

  2. Reference Microsoft.AspNetCore.App with a specific version, and ensure this version is the same throughout the entire solution. It requires that you own the entire stack, so it's probably only helpful for monoliths with many dependent projects in a single solution.

David
  • 5,882
  • 3
  • 33
  • 44
robrich
  • 13,017
  • 7
  • 36
  • 63
  • 2
    Good options, although I think we're talking about a bigger problem in that there's a conflict of best practice. > *Visual Studio on building reports that I shouldn't specify a version for the Microsoft.AspNetCore.App meta package* conflicts with ** does not provide an inclusive lower bound for dependency**. – Jeremy Thompson Apr 08 '19 at 03:18