asp.net - 在一个解决方案中混合 packageReference 和 packages.config?
问题描述
我们有一个包含旧版 ASP.NET 应用程序和许多其他项目的大型解决方案(主要是 .NET 4.7)。将整个解决方案移至 .NET 核心是不可行的。尽管如此,我们不再想管理传递依赖,避免带外包的问题等等。
Visual Studio 2019 有一个迁移助手,可以帮助我们将我们的 csproj 文件从 packages.config 移动到格式。不幸的是,该助手不支持 ASP.NET 项目;主要问题似乎是web.config。
我的直觉告诉我,将一些项目移动到 packageReference 可能是个坏主意,而 ASP.NET 应用程序坚持使用 packages.config。但是,对于在一个解决方案中混合使用 packageReference 和 packages.config 是否还有基于事实的理由?
解决方案
在更新 RabbitMQ.Client NuGet 包的传递依赖后遇到问题后,我们看到我们不再希望主动管理传递依赖。至少对于这个项目来说,不幸的是,它是我在问题中提到的真正大型 ASP.NET 解决方案的一部分。所以我们继续将一个项目迁移到 packageReference,将所有其他项目保留在 packages.config 中。稍后,我们迁移了所有的单元和集成测试项目,以及一些其他项目。现在我们采用“混合解决方案”两个月左右。我们没有遇到任何问题,并且我们以该状态经历了发布生命周期。
推荐阅读
- java - CFB模式输出与CTR输出相同;难道我做错了什么?
- javascript - 固定 div 的可点击区域相对于移动 Chrome 中的 url 栏滚动移动
- c - 变长参数列表错误
- c# - 算法 - 按行分组地理点
- html - 在css中使宽度与高度成比例
- caching - Vue.js 在 Chrome 浏览器重新加载页面上的计算属性问题
- meteor - 使用 findone 自动运行跟踪器
- android - 滚动以本机反应结束时加载更多信息
- php - max_execution_time - php.ini、phpinfo 和脚本错误中的 3 个不同值
- android - 添加文本时,Android 6.0 上的 PhotoEditor SDK 崩溃