NuGet浮动版本解析异常：未知SIL.LCModel.Utils包来源排查

版本选择逻辑说明 #

你对预发布版本解析规则的猜测是对的，但对版本排序的细节认知有偏差：NuGet对同主/次/修订号的预发布版本，会对预发布后缀做逐位ASCII码字符串排序，排序优先级完全和字符串字典序一致，不会给beta、netcore这类语义标识特殊权重：

• 后缀首字母对比：restorepacking的首字母rASCII码为114，比netcore的首字母n（110）、beta的首字母b（98）都大，因此只要所有配置的NuGet源中存在10.2.0-restorepacking0022这个版本，它的排序优先级就高于你在官方源查到的所有10.2.0开头预发布版本，10.2.0-*浮动配置自然会优先解析到它。

未知版本来源定位方法 #

你之前只针对官方NuGet源做检索没找到这个版本，说明它一定来自你当前环境配置的其他NuGet源——全局NuGet配置、解决方案级NuGet.Config都可能引入你没注意到的第三方源、私有源、本地目录源，按以下步骤操作可以直接定位来源：

1. 先列出当前环境所有生效的NuGet源，确认完整源列表：

   dotnet nuget list source
   

2. 针对列出的每一个源，单独执行包版本检索，找到包含该特殊版本的源：

   # 将<源地址>替换为上一步查到的每个源地址逐个执行
   Find-Package -AllVersions -source <源地址> SIL.LCModel.Utils -IncludePrerelease -ExactMatch
   

3. 更直接的方式是开详细日志跑一次还原，直接看包的拉取地址：

   dotnet restore .\src\MyProject.csproj --verbosity detailed
   

   在输出日志中搜索10.2.0-restorepacking0022关键字，就能直接看到还原时从哪个源获取到了这个包。

常见场景说明 #

带restorepacking后缀的版本一般是包作者做打包流程验证、CI测试时生成的临时版本，通常只会推到项目内部的私有测试源（比如组织内部的Azure DevOps制品源、MyGet测试源），不会同步到公开的NuGet官方源。
如果要避免后续浮动版本抓到这类临时测试包，可以把浮动规则的预发布前缀写死，比如将版本配置改为10.2.0-netcore*，就只会匹配netcore开头的预发布版本，不会被其他后缀的高版本号测试包干扰。

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