将 packageReference 和 packages.config 混合在一个解决方案中?

Her*_*ber 4 .net asp.net csproj nuget

我们有一个包含遗留 ASP.NET 应用程序和许多其他项目的大型解决方案(主要是 .NET 4.7)。将整个解决方案移至 .NET 核心是不可行的。尽管如此,我们不再想管理传递依赖,避免带外包的问题,等等。

Visual Studio 2019 有一个迁移助手,可以帮助我们将我们的 csproj 文件从 packages.config 移动到格式。不幸的是,该助手不支持 ASP.NET 项目;主要问题似乎是web.config

我的直觉告诉我,将某些项目移动到 packageReference 可能是个坏主意,而 ASP.NET 应用程序则坚持使用 packages.config。但是,是否还有基于事实的理由反对在一个解决方案中混合使用 packageReference 和 packages.config?

Her*_*ber 6

更新 RabbitMQ.Client NuGet 包的传递依赖后遇到问题后,我们发现我们不再希望主动管理传递依赖。至少对于这个项目来说,不幸的是,它是我在问题中提到的真正大型 ASP.NET 解决方案的一部分。因此,我们继续将一个项目迁移到 packageReference,将所有其他项目保留为 packages.config。稍后,我们迁移了所有单元和集成测试项目,以及一些其他项目。现在我们采用“混合解决方案”两个月左右。我们没有遇到任何问题,我们以该状态经历了发布生命周期。

  • 我们将项目自下而上更改为 packageReference。也就是说,我们首先迁移了一些不引用任何其他项目的项目。在每个项目中,我们始终对所有引用的 NuGet 包使用 packageReference 或packages.config。为了解决您的问题,也许您想在您引用的库的 github 项目或 NuGet 项目本身打开一个问题 - 如果您认为这是 nuget 或特定 nuget 包中的错误。华泰 (2认同)