我之前也碰到过一模一样的情况——把输出路径改成非默认的bin目录后，CLR还是死盯着项目根下的bin找依赖，这其实是ASP.NET默认的程序集加载机制在搞鬼。给你几个亲测有效的解决办法：

• 调整调试工作目录
  右键你的项目 → 属性 → 调试选项卡，把「工作目录」设置成你指定的输出路径..\Any\Debug\。这样调试时应用的基目录就会指向输出目录，而不是项目根目录，CLR就会优先从这个目录加载程序集。

• 配置web.config的程序集探测路径
  在你的web.config里的<runtime>节点下添加probing配置，明确告诉CLR去自定义路径找依赖：

  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <!-- 填写你的输出路径相对项目根的路径 -->
      <probing privatePath="..\Any\Debug"/>
    </assemblyBinding>
  </runtime>
  

  这个配置会让CLR在默认路径之外，额外去指定的privatePath里搜索缺失的程序集。

• 确认引用的「复制本地」设置
  找到项目里的Microsoft.ApplicationInsights.Web引用，右键 → 属性，确保「复制本地」设置为True。只有这样，构建时NuGet包的DLL才会被复制到你指定的输出目录，避免出现路径正确但文件缺失的尴尬情况。

• 清理后重新生成解决方案
  有时候旧的bin目录残留的文件会干扰加载逻辑，先执行「Build → Clean Solution」清理所有旧输出，再「Build → Rebuild Solution」重新生成，确保所有文件都输出到正确的目录。

至于为什么改成bin就正常？因为ASP.NET的CLR程序集加载逻辑默认把项目根下的bin目录作为优先搜索路径，不需要额外配置就能找到DLL；而自定义路径必须明确告诉CLR去哪里找，不然它还是会走默认的搜索逻辑。

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