我是一位多年后端经验的工程师，其中前几年用 ASP.NET，后几年主要用Java，这是之前一篇关于 .NET 程序常见引用问题的技术随手记，记录了那些版本冲突和依赖管理相关的坑，都是非常典型的痛点。

我不只是想要简单的解决方案，更希望系统化梳理这些问题背后的机制。

一、引用版本不匹配

A项目依赖B类库，A依赖C组件，B也依赖C组件，A引用的C组件版本是2.0，而B类库引用的组件版本是1.0，在编译的时候可以通过，但是在运行的时候报错，如：

但是可以通过在配置文件中设置引用组件的版本，如：

<runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="RabbitMQ.Client" publicKeyToken="89e7d7c5feba84ce" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-3.5.7.0" newVersion="3.5.7.0" />
      </dependentAssembly>
    </assemblyBinding>
</runtime>

如果版本不对会引发其它问题，如程序报错：

这个问题本质是DLL Hell的现代版，虽然.NET有GAC和配置文件重定向，但实际项目中混合使用NuGet和直接DLL引用时容易翻车。

二、引用的版本在NuGet库中没看到

如果引用的版本在NuGet库中没看到这种情况，可以尝试通过使用命令来安装，如Install-Package RabbitMQ.Client -Version 3.4.3。

三、引用依赖问题

公司老项目依赖很重，发布的时候遇到一个问题，A项目依赖C组件，C组件依赖D组件，D组件依赖E组件....，然后我只改了D组件，编译A项目正常，但是运行会报错，而且这种错误不是表面上的错误，比如报D组件的什么方法没有实现之类的。

这个问题暴露了深层依赖链的脆弱性，比如D组件改了接口但忘记同步更新C组件，编译期发现不了，运行时才崩溃。Java系的Maven/Gradle会严格校验传递依赖，但.NET的NuGet在这方面弱一些。

四、nuget引用的版本修改问题

如果项目A引用C组件通过NuGet，版本是【1.0】，后面改为【2.0】，重新生成项目的依赖版本并不会改过来。

如公司老项目中引用的RabbitMQ是【3.4.3.0】，现在要改为【3.5.7.0】，直接修改packages.config：

<?xml version="1.0" encoding="utf-8"?>
<packages>
  <package id="RabbitMQ.Client" version="3.5.7" targetFramework="net40" />
</packages>

重新生成项目，查看引用的依赖还是3.4.3（引用的是bin\Debug下），但是查看packages目录下3.5.7版本已经生成：

清理下【bin\Debug】下文件会被删除，再重新生成到【bin\Debug】下还是3.4.3，查看nuget管理其实已经是3.5.7了：

这个项目是一个类库，引用它的网站发布完后用的还是3.4.3。

其实nuget只是包管理，在生成项目时会根据包的配置文件去下载对应的dll到项目的packages目录中，即使修改了这个配置文件，并不表示项目的引用也会变化，因为项目的引用已经固定了，在项目的【.csproj】文件可以看到：

直接修改这个文件引用的版本：

  <Reference Include="RabbitMQ.Client, Version=3.5.7.0, Culture=neutral, PublicKeyToken=89e7d7c5feba84ce, processorArchitecture=MSIL">
    <HintPath>..\packages\RabbitMQ.Client.3.5.7\lib\net40\RabbitMQ.Client.dll</HintPath>
    <Private>True</Private>
  </Reference>

这个时候引用的版本就对了，生成的dll也会是修改后的版本。

当有个其它项目引用上面的项目，此项目也要添加rabbitmq的依赖，如果此项目的目标框架是4.5.2（被引用的项目是4.0）

修改方式和上面一样后重新生成项目会出现问题【遇到的问题-其它项目生成失败】。

这个问题，暴露NuGet版本升级问题，很有意思。我已经发现packages.config和项目文件不同步的现象，这其实是NuGet早期设计的遗留问题。现代SDK风格的项目用PackageReference就好很多，但很多老项目还在用packages.config。

五、遇到的问题-其它项目生成失败

其它项目引用正常，但是生成失败：

严重性	代码	说明	项目	文件	行
错误		Cannot embed interop types from assembly 'RabbitMQ.Client, Version=3.5.7.0, Culture=neutral, PublicKeyToken=89e7d7c5feba84ce' because it is missing either the 'System.Runtime.InteropServices.ImportedFromTypeLibAttribute' attribute or the 'System.Runtime.InteropServices.PrimaryInteropAssemblyAttribute' attribute.	Cn.Vcredit.VBS.WMXWLendingResult	D:\svn\Loan\branches\VBS_Console\Cn.Vcredit.VBS.WMXWLendingResult_CR1332_Real\CSC	

解决办法是把rabbitmq引用删除掉，然后再重新生成则会正常。

"删除引用再添加" 的问题其实和VS的智能感知缓存有关。那个suo文件特别顽固，手动清理比重启VS更彻底。

六、vs调试提示版本信息

在使用vs调试网站时提示：

你正在调试 Cn.XXX.Utility.dll 的发布版本。将“仅我的代码”与使用编译器优化的发布版本一起使用将导致调试体验降级（例如，将不会命中断点）。但是调试正常。

从技术角度看，这个问题涉及三个层面的交织：
1、编译器优化机制（Release模式的IL优化）
2、Visual Studio调试器的工作逻辑（"仅我的代码"过滤）
3、项目引用配置的实际来源（NuGet包或项目引用）

Cn.XXX.Utility.dll 是公司内部的公共库，这类基础库经常以Release模式打包分发。属于直接引用bin目录DLL的情况，无论网站自身是Debug还是Release构建，它加载的都是这个固定的Release版本DLL。

断点失效只是最明显的，更隐蔽的是无法查看局部变量值、单步执行时跳行不准。这些在排查复杂BUG时尤其致命。

简单的方法就是执行清理解决方案，然后手动删除网站项目的 bin\Debug 和 obj 文件夹，再执行重新生成解决方案。