同一解决方案中OpenCL.dll API在一个项目可用另一项目不可用

问题场景 #

我在使用一款.NET封装的OpenCL API库进行神经网络开发，仓库内的.NET库基于.NET Standard 2.1，自带的OpenCl.DotNetCore.Tests测试项目（原目标框架.NET Core 2.1）运行完全正常。但在同一解决方案下新建.NET 6控制台项目，执行以下代码时：

static async Task Main(string[] args)
{ 
    Console.WriteLine("Starting test!");
    IEnumerable<Platform> platforms = Platform.GetPlatforms().ToList();
}

会抛出异常：

System.EntryPointNotFoundException: 'Unable to find an entry point named 'clGetPlatformIDs' in DLL 'OpenCL'.'

即使将原测试项目的目标框架改为.NET 6，运行依然正常。我尝试了复制核心代码、添加延迟、手动复制OpenCL.dll到输出目录等方法，均无法解决问题，也找不到两个.NET 6项目之间的实质性差异。

排查方向与解决方案 #

1. 统一项目平台目标 #

OpenCL.dll分32位和64位版本，原测试项目大概率设置了明确的平台目标（如x64），而新建的.NET 6项目默认是Any CPU，在部分环境下会自动适配为32位，导致找不到对应架构的DLL入口点。

• 操作步骤：右键.NET 6项目 → 属性 → 生成 → 平台目标，改为与原测试项目一致的选项（如x64），同时取消勾选“首选32位”。

2. 指定明确的运行时标识符（RID） #

.NET 6的默认RID可能与原测试项目存在差异，导致DLL加载路径或架构匹配出错。

• 操作步骤：在项目的.csproj文件中添加明确的RID配置，示例：

<PropertyGroup>
  <RuntimeIdentifier>win-x64</RuntimeIdentifier>
</PropertyGroup>

保存后重新生成项目。

3. 核对DllImport的调用约定与字符集 #

原库中clGetPlatformIDs的DllImport声明可能依赖特定的调用约定或字符集，.NET 6的默认行为与.NET Core 2.1存在细微差异，可能导致入口点匹配失败。

• 若能查看库的源码，确认clGetPlatformIDs的声明是否包含明确的调用约定和字符集，示例：

[DllImport("OpenCL", CallingConvention = CallingConvention.Cdecl, CharSet = CharSet.Ansi)]
private static extern int clGetPlatformIDs(...);

4. 检查依赖项复制配置 #

原测试项目可能配置了自动复制OpenCL相关依赖到输出目录，而新项目未开启该设置。

• 操作步骤：右键项目中的OpenCL库引用 → 属性 → 确保“复制本地”设置为True，同时确认库是否携带了对应架构的OpenCL.dll，保证输出目录中存在正确版本的DLL文件。

5. 用融合日志追踪DLL加载过程 #

使用Windows自带的融合日志查看器（Fuslogvw.exe）可以追踪DLL加载的详细过程，定位项目实际加载的OpenCL.dll路径及失败原因：

• 打开Fuslogvw.exe，配置“记录绑定失败到磁盘”，运行项目后查看生成的日志，明确DLL加载的问题节点。

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