你遇到的是.NET程序集加载策略和Windows原生DLL查找机制的差异导致的问题——C++/CLI项目本质上是托管+非托管混合的，CLR加载托管依赖（DeviceLib.dll）时并不直接遵循系统的Path环境变量，而是有自己一套查找逻辑，这就是为什么把DLL放到Path目录里没用的原因。

下面是针对这类依赖问题的几种推荐解决方案，按场景优先级排序：

1. 使用应用程序配置文件（app.config）指定程序集查找路径 #

这是.NET生态中最规范的部署方案，适合固定路径部署的生产场景。

操作步骤：

• 给你的C++控制台项目添加一个app.config文件（右键项目→添加→新建项→应用程序配置文件）。
• 根据你的DLL命名情况选择配置方式：
  • 如果DeviceLib.dll是弱命名（未强签名）：只能指定应用程序目录的子目录作为查找路径

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <runtime>
        <!-- 假设test_lib是控制台输出目录的上级目录，可根据实际路径调整 -->
        <probing privatePath="..\test_lib" />
      </runtime>
    </configuration>
    

  • 如果DeviceLib.dll是强命名（已签名）：可以指定任意绝对路径

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <runtime>
        <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
          <dependentAssembly>
            <assemblyIdentity name="DeviceLib" 
                              publicKeyToken="你的公钥令牌" 
                              culture="neutral" />
            <codeBase version="1.0.0.0" href="file:///C:/test_lib/DeviceLib.dll" />
          </dependentAssembly>
        </assemblyBinding>
      </runtime>
    </configuration>
    

    （公钥令牌可通过sn -Tp DeviceLib.dll命令获取）

优点：无需修改代码，配置化管理，符合.NET部署规范。
缺点：弱命名程序集有路径限制，强命名需要额外签名步骤。

2. 注册AssemblyResolve事件手动加载程序集 #

这是最灵活的方案，适合需要动态查找依赖或无法使用配置文件的场景。

操作步骤：
在C++控制台程序的入口函数开头，添加托管代码注册解析事件：

#include <msclr\auto_gcroot.h>
#include <System.h>
#include <System.Reflection.h>

using namespace System;
using namespace System::Reflection;

// 程序集解析事件处理函数
Assembly^ OnAssemblyResolve(Object^ sender, ResolveEventArgs^ args)
{
    // 提取程序集名称（忽略版本、公钥等后缀）
    String^ assemblyName = gcnew String(args->Name->Split(',')[0]);
    String^ targetPath = String::Format(L"C:\\test_lib\\{0}.dll", assemblyName);
    
    if (IO::File::Exists(targetPath))
    {
        return Assembly::LoadFrom(targetPath);
    }
    return nullptr;
}

int main()
{
    // 注册事件，CLR找不到程序集时会触发
    AppDomain::CurrentDomain->AssemblyResolve += gcnew ResolveEventHandler(OnAssemblyResolve);

    // 调用DeviceLibWrapper的业务代码
    // ...

    return 0;
}

优点：完全不受强命名限制，路径可动态调整（比如从配置文件读取），灵活性拉满。
缺点：需要编写少量托管代码，对纯C++开发者有轻微学习成本。

3. 将DeviceLib.dll安装到全局程序集缓存（GAC） #

如果这个DeviceLib.dll需要被多个应用共享，安装到GAC是最佳选择。

操作步骤：

1. 给C#的DeviceLib项目添加强签名：右键项目→属性→签名→勾选“为程序集签名”→新建密钥文件（.snk）。
2. 编译生成DeviceLib.dll后，用开发者命令提示符运行sn -Tp DeviceLib.dll获取公钥令牌。
3. 以管理员权限运行gacutil /i DeviceLib.dll，将DLL安装到GAC。

优点：多个应用可直接引用，无需复制DLL到每个应用目录，集中管理版本。
缺点：需要强命名程序集，安装GAC需要管理员权限，不适合临时测试或小型项目。

4. 保持复制DeviceLib.dll到控制台输出目录（最简测试方案） #

如果你的项目是小型测试或单应用场景，这个方案最简单直接，就是你目前能正常运行的方式。

可以配置自动复制：右键C++控制台项目→添加引用→选中DeviceLib.dll→在引用属性中设置“复制本地”为True，编译时会自动把DeviceLib.dll复制到输出目录。

优点：零额外配置，开箱即用。
缺点：多个应用使用同一DLL会产生冗余副本，不适合共享场景。

• 项目引用/复制本地：你修改配置后取消了自动复制，输出目录缺少DeviceLib.dll，CLR无法找到。
• #using指令和Resolve #using References：这是编译时的查找配置，仅负责让编译器找到DLL完成编译；而运行时CLR仍按照自己的程序集加载策略查找，因此编译通过但运行时报错。
• 系统Path变量：CLR加载托管程序集时，默认不会遍历系统Path目录（原生DLL才会遵循此规则），所以放到Path里无效。

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