Azure DevOps包保留策略问题：已删除包致应用更新失败

1. 给核心旧包加白名单保留 #

在Package Retention Policy里新增白名单规则，把那些仍有旧应用在依赖的特定包版本标记为永久保留或延长保留周期。不用一次性整理完所有应用，每次遇到更新失败的情况，就把对应的包版本加入白名单，等后续应用列表整理完成后再逐步移除白名单条目。

2. 搭建离线缓存仓库存旧包 #

专门建一个内部离线缓存仓库，用来存放主Feed已经清理但旧应用还在依赖的包版本。更新旧应用时，临时让Package Manager指向这个离线仓库获取所需旧包，完成卸载-更新流程后再切回主Feed。这种方式不用修改项目文件，只需要临时切换包源配置。

3. 简化项目文件修改流程 #

如果已经在手动改项目文件，不用先移除旧版本再装新的——直接在项目文件（比如.csproj或packages.config）里把旧包的版本号替换成新版本号，然后执行dotnet restore（或对应Package Manager的恢复命令）即可。这种操作跳过了卸载环节，直接完成版本替换，效率更高。

4. 脚本批量检测依赖风险 #

写个简单脚本（比如PowerShell或Python），扫描所有旧应用的项目文件，提取当前依赖的包版本，自动和主Feed里的现有版本对比。提前把即将被清理但仍被依赖的包版本加入保留列表，避免后续更新时被动踩坑。

5. 自动化恢复回收站包 #

如果经常需要从回收站恢复包，可以写个自动化脚本，根据包名和版本号直接调用Feed的恢复接口（如果支持），不用手动操作回收站，节省重复操作的时间。

内容的提问来源于stack exchange，提问作者ISAF