这问题我之前踩过一模一样的坑！本质是Visual Studio 2015的一个隐性优先级规则在搞鬼：当你的解决方案里同时包含<bar>项目时，哪怕你给<foo>手动添加的是bar.dll的文件引用，VS也会自动把它替换成项目引用，优先编译并使用本地<bar>项目的代码——完全忽略你指定的更新后DLL文件。这就是为什么你本地<bar>项目没有新增类，<foo>就报“类未找到”，而单独打开<foo>时，因为没有<bar>项目干扰，VS只能老老实实使用你添加的DLL，自然能正常编译。

下面是具体的解决步骤：

1. 修正引用类型，确保是文件引用而非项目引用 #

• 右键<foo>项目 → 选择「引用」，在引用列表里找<bar>相关的条目
• 如果它的图标是项目图标（不是DLL图标），说明VS自动替换成了项目引用：
  • 先删除这个项目引用
  • 重新添加文件引用：点击「添加引用」→ 「浏览」，选择你拿到的更新后的bar.dll
  • 添加完成后，选中这个新引用，在右侧属性面板里：
    • 把**「复制本地」设为True**（确保编译时DLL会被复制到<foo>的输出目录）
    • 把**「特定版本」设为True**（避免VS自动查找其他版本的DLL）

2. 清理VS缓存与编译残留文件 #

有时候旧的缓存会导致引用逻辑混乱，彻底清理一下：

• 关闭Visual Studio
• 找到解决方案目录，删除隐藏的.vs文件夹（需要先在系统设置里显示隐藏文件）
• 分别删除<foo>和<bar>项目目录下的bin、obj文件夹
• 重新打开解决方案，直接编译<foo>项目

3. 强制指定引用搜索路径（可选，用于顽固情况） #

如果上面的方法还是没解决，可以给<foo>指定明确的DLL搜索路径：

• 右键<foo>项目 → 「属性」
  • 如果是C#项目：切换到「生成」选项卡，找到「引用路径」，添加你存放更新后bar.dll的文件夹路径，并把它移到路径列表的最顶部
  • 如果是C项目：切换到「VC目录」→ 「引用目录」，同样添加目标文件夹并置顶
• 保存属性设置后重新编译

额外提醒 #

如果是团队协作场景，建议尽量避免在同一个解决方案里同时包含<foo>和<bar>项目，或者提前和团队约定好引用方式——要么都用项目引用，要么都用文件引用，避免这种隐性冲突。

内容的提问来源于stack exchange，提问作者Jason 'Bug' Fenter