Microsoft.AspNetCore.App - 版本控制/是否应该在非 ASP.NET 类库中引用? [英] Microsoft.AspNetCore.App - Versioning / Should it be referenced in non ASP.NET class libraries?

问题描述

我正在尝试找出使用 Microsoft.AspNetCore.App 元包的正确方法.

关于构建报告的 Visual Studio，我不应该为 Microsoft.AspNetCore.App 元包指定版本.

所以我将上面的替换为:

下一个问题是，我的项目所依赖的任何类库项目或包包含对也包含在 Microsoft.AspNetCore.App 元包中的包的版本化引用，因为存在版本冲突而破坏构建.

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

所以我也删除了这些参考文献中的版本:

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

现在当我运行 dotnet restore 时，我看到一个警告:

不提供依赖性的包容性下限微软.扩展.配置.近似最佳匹配Microsoft.Extensions.Configuration 1.0.0 已解决.

所以现在应用程序构建，但正在解决一个旧的和可能过时的包版本.

维护所有这些包的下限版本似乎有点开销.

阻力最小的路径似乎可能是仅引用 Microsoft.AspNetCore.App 包(未版本化)代替元包中包含的任何包.但后来我隐含地引用了很多不必要的东西(目前有 150 个包).我可能想在一个不面向 Web 的项目中重用类库，因此所有引用的包似乎都是低效的膨胀.另外，我是否认为较新版本的 Microsoft.AspNetCore.App 可能会在我将来构建时破坏我的应用程序?

解决方案

我想你可能想观察

这是我正在进行的一个项目，我必须明确引用某些包(为了获得 ActionResults，我必须添加 2 个特定的引用.):

使用 NuGet 表示法可以在您需要时使用细粒度的库，或者通过范围/通配符 API 更新实现面向未来的模块化，或者您可以参考完整的工具包和组合.

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?

解决方案

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:

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.):

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.

这篇关于Microsoft.AspNetCore.App - 版本控制/是否应该在非 ASP.NET 类库中引用?的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！