C#编译报CS0012错误时程序集版本信息来源咨询

编译器根本不是从你修改的.csproj文件（哪怕是你之前留的注释内容）、本地bin/obj缓存里拿到1.0.84.1这个版本号的，版本信息来自你项目中引用的其他依赖程序集。

所有.NET程序集编译的时候，都会在自己的元数据里硬编码一份自己引用过的所有其他程序集的完整标识，包括精确版本号、公钥标记、文化信息。你项目里肯定至少有一个直接引用的DLL——要么是其他NuGet包，要么是同解决方案里的其他类库项目——当初是基于1.0.84版本的Firmware.Internal编译的，它的元数据里明明白白记着自己依赖Firmware.Internal, Version=1.0.84.1，而且用到了其中的InternalGroup类型。

编译器做类型解析时会递归遍历所有依赖的引用清单：当它顺着这个依赖找到InternalGroup类型的归属是1.0.84.1版的Firmware.Internal，再看你当前项目直接引用的是83版本，83版本里又确实不存在这个类型，就会精准抛出你看到的错误——版本号是直接从依赖的元数据里读出来的，不是凭空猜的，当然不会报成其他版本。

你之前做的几个操作没用的原因也很简单：

• .csproj里的XML注释完全不会被编译流程解析，删不删对结果没有任何影响
• 清空bin、obj目录只会删除当前项目的编译中间产物和输出文件，改不到你引用的其他第三方DLL、类库项目编译产物里的元数据
• 如果你只改了主项目的引用，没有同步调整其他依赖的版本，错误会一直存在

1. 先定位到底哪个依赖在引用84版的Firmware.Internal：可以在Visual Studio里展开项目的「依赖项」节点，挨个点开每个引用的DLL/包的子依赖项，找哪个项下面挂着1.0.84.1版本的Firmware.Internal；也可以用开发者命令提示符执行以下命令，直接扫描输出程序集的依赖链：

   ildasm /text 你的项目输出文件路径.exe /metadata | findstr "Firmware.Internal"
   

2. 找到问题依赖后做对应处理：如果是NuGet包，就把包降级到适配83版Firmware.Internal的对应版本；如果是同解决方案的类库项目，就把这个类库项目里的Firmware.Internal引用也改成83版本，重新编译类库即可。

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