如何在 Visual Studio 中更新存在漏洞的 NuGet 包及传递依赖？

2026-11-04数据阿明

通常不需要先卸载 NuGet 包。直接引用的包可以在 Visual Studio 的 NuGet 包管理器中更新；如果包是通过传递依赖引入的，应先找到引入它的上游包，再选择合适的修复方式。

由于没有提供具体包名、漏洞信息以及 Visual Studio 和 .NET SDK 版本，无法确定应升级到哪个版本。选择目标版本时，需要考虑漏洞公告中的修复范围，以及项目的目标框架和依赖约束。

直接引用的包如何更新？

“卸载后重新搜索并安装”的流程会丢失此前勾选项目的操作上下文，也增加选错包的机会。NuGet 可以直接更新现有引用，无须先删除。

在 Visual Studio 中，可以按以下步骤操作。具体菜单名称可能因版本和界面语言略有不同：

如果只处理一个项目，也可以从该项目的 NuGet 包管理入口更新。需要统一多个项目的版本时，可以使用解决方案级管理界面，其中的“合并”页面可以用来检查同一个包在不同项目中的版本差异。

如果希望使用命令，可以在 Visual Studio 的“程序包管理器控制台”中更新指定项目的直接引用：

Update-Package Package.Id -Version 1.2.3 -ProjectName MyProject

Package.Id、MyProject 和 1.2.3 都是示例，执行前需要替换；1.2.3 不代表任何实际包的修复版本。该命令属于 Visual Studio 的 NuGet PowerShell 控制台命令，不是普通终端中的 dotnet 命令。

更新前还要确认是否启用了集中包版本管理。如果项目使用 Directory.Packages.props 管理版本，应在相应的集中版本声明处调整，避免在项目中重复配置。

传递依赖由其他包引入。例如：

MyProject
└── Package.A（直接引用）
    └── Package.B（传递依赖，存在漏洞）

项目没有直接安装 Package.B，因此找不到可以卸载它的直接引用。只要 Package.A 仍然需要它，删除本地缓存或生成的依赖文件后，再次还原仍会把它带回来。

首先需要确认依赖链。对于采用 PackageReference 的项目，可以在 Visual Studio 的“依赖项 → 程序包”中检查包之间的关系；具体展示方式取决于 Visual Studio 版本和项目类型。

在支持相应选项的 .NET SDK 中，也可以列出存在漏洞的直接依赖和传递依赖：

dotnet list YourSolution.sln package --vulnerable --include-transitive

将 YourSolution.sln 替换为实际解决方案路径。这个命令用于检查，不会自动修复依赖。如果 SDK 不支持该选项，可以改用 Visual Studio 的漏洞提示和依赖视图。

在上面的例子中，先检查 Package.A 是否有兼容的新版本，以及该版本的依赖要求能否让 NuGet 解析到已修复的 Package.B。

升级后要检查实际解析结果。上游包版本提高，并不保证目标传递依赖已经修复。其他依赖路径、版本约束或锁定配置都可能影响最终采用的版本。

如果多个包都引入了同一个有漏洞的依赖，需要一起检查这些路径。

如果上游包暂时没有合适的更新，可以评估在项目中显式添加该传递依赖的已修复版本。对于常见的 PackageReference 项目，直接引用会参与版本解析，通常可用于提高原先通过传递依赖引入的包版本。

目标版本必须兼容项目框架、上游包和其他依赖约束。显式引用可能触发版本冲突，也可能出现编译通过但运行行为不兼容的情况，需要验证后才能采用。

启用集中包版本管理时，还应按照现有配置管理版本，不能假定只修改某个 .csproj 就能生效。

如果升级上游包和显式引用都无法得到兼容的修复版本，就需要评估替换相关上游包、移除不再使用的依赖，或等待维护方提供修复。具体选择取决于漏洞影响和项目实际使用情况。

关闭告警不会改变包版本，也不会消除漏洞。

完成修改后，还原依赖并重新检查漏洞提示，确认被报告的包实际解析到了修复范围内的版本，再进行构建和相关功能测试。

多项目、多目标框架的解决方案需要检查各自的结果；若使用依赖锁定文件，也要按项目流程同步更新。仅看到某个项目的包版本发生变化，还不足以确认整个解决方案都已修复。

“有更新版本”和“存在已知漏洞”是两种信息。应先根据漏洞提示确定受影响范围和修复版本，再决定升级目标；有时采用兼容的补丁版本即可解决问题，无须直接跨到最新主版本。