北京
.NET 10的包修剪（Package Pruning）功能，正在让不少开发者的SDK升级变成一场还原失败。当仓库把警告提升为错误时，NU1510诊断信息会直接阻断构建流程。面对这个报错，最直觉的做法是删掉所有出现问题的PackageReference，但这条路并不总是安全的。
对于只面向net10.0的应用程序，如果框架本身已经提供了对应程序集，删除引用确实没有问题。但情况在类库项目中会变得复杂——尤其是那些仍然需要支持netstandard2.0目标的库。盲目删除全局引用，可能让旧目标框架失去它实际需要的依赖。
NU1510的触发边界
从.NET 10开始，面向.NET 10或更高版本的项目默认启用包修剪。当项目直接引用的某个包已被注册为可修剪，且目标SDK已经提供了相同或更高版本的程序集时，NuGet就会抛出NU1510警告。这个诊断信息并非通用的未使用包检测器，它不会自动适用于任意的第三方包。
在CI环境中，很多团队会全局启用TreatWarningsAsErrors策略，将警告直接升级为错误。示例项目在应用这一策略后，添加了对System.Text.Json 10.0.11的直接引用，使用稳定的.NET SDK 10.0.303执行还原时，进程以退出码1结束。如果没有启用警告即错误的策略，同样的条件通常只会产生一条警告，而不会导致还原失败。
net10.0应用的修复路径
对于仅面向net10.0的应用程序，修复方式很直接：移除包引用即可。示例中的应用程序在删除引用后，依然能够正常导入System.Text.Json并序列化相同的数据负载，验证输出为{"Message":"framework-provided","Count":10}。这说明框架提供的程序集完全能够满足需求。
微软在.NET 10破坏性变更指南中给出的建议是：当所有目标框架都能修剪该引用时，直接移除；当较旧的目标框架仍然需要时，则使用条件化处理。
多目标类库的差异化处理
多目标类库需要不同的答案。示例库同时支持netstandard2.0和net10.0，如果全局删除引用，就会移除旧目标框架所需的依赖。正确的做法是在MSBuild中明确表达这种差异化需求：通过TargetFrameworks属性声明两个目标框架，然后使用Condition条件，仅在netstandard2.0目标下保留System.Text.Json的包引用。
这种处理方式把NU1510看作一个针对特定目标的依赖决策问题：先证明哪些引用是冗余的，再保留那些仍然必需的引用，最后验证为消费者生成的包是否完整。把警告当作一次依赖审计的机会，而不是简单地消除报错，才能避免在升级过程中埋下新的兼容性隐患。
特别声明：以上内容(如有图片或视频亦包括在内)为自媒体平台“网易号”用户上传并发布，本平台仅提供信息存储服务。
Notice: The content above (including the pictures and videos if any) is uploaded and posted by a user of NetEase Hao, which is a social media platform and only provides information storage services.
