.NET Framework 4.7.2加载第三方库报错，.NET 5.0环境运行正常

项目接入第三方类库时，不同.NET运行环境下运行表现存在明显差异：

• .NET 5.0（已结束官方支持）环境下所有功能可正常运行
• .NET Framework 4.7.2环境下功能完全无法正常工作

错误触发于如下代码逻辑：

var addr = WinApi.LoadLibraryW(path);

if (addr == IntPtr.Zero)
    throw new InvalidOperationException($"Failed to load library \"{path}\": {WinApi.GetLastError()}");

运行时抛出异常信息：

System.InvalidOperationException: "Failed to load library "D:\Project\Project\bin\Debug\x64\lib.dll": 0"

当前使用的WinApi封装类定义：

internal class WinApi
{
    [DllImport("kernel32.dll", CharSet = CharSet.Unicode, EntryPoint = "LoadLibraryW")]
    public static extern IntPtr LoadLibraryW(string dllToLoad);
}

核心异常表现：调用LoadLibraryW加载指定路径的x64版本lib.dll时返回IntPtr.Zero，调用GetLastError获取到的错误码为0。

1. 进程架构不匹配（最高发原因）
   .NET Framework 4.7.2的项目模板默认对Any CPU配置开启「首选32位」选项，即使运行在64位系统上，进程也会以32位模式启动。32位进程无法加载x64架构的原生DLL，此时LoadLibraryW会直接返回空指针。且这类架构不匹配的拦截发生在Win32 API逻辑层之前，往往不会设置正确的错误码，最终GetLastError返回0。而.NET 5+默认关闭「首选32位」选项，在64位系统上会以x64进程启动，因此可以正常加载x64版本的DLL。
2. P/Invoke封装错误导致错误码失真
   现有LoadLibraryW的P/Invoke声明没有设置SetLastError = true，CLR不会在调用完成后保留Win32最后错误码，P/Invoke返回后CLR本身的内部逻辑可能调用其他Win32 API覆盖错误码，最终拿到的0不是加载失败时的真实错误码。
3. 原生DLL依赖缺失
   .NET Framework和.NET 5+的原生DLL搜索路径逻辑存在差异，lib.dll依赖的其他原生DLL（比如对应架构的VC++运行库、其他第三方依赖库）不在.NET Framework进程的搜索路径中时，会触发隐式依赖加载失败，连带主DLL加载返回空，部分场景下也会出现错误码为0的情况。
4. DLL搜索路径未覆盖目标目录
   项目运行时的工作目录可能和DLL所在目录不一致，导致系统搜索DLL及其依赖时找不到对应文件。

按优先级依次排查修复：

1. 修正项目平台目标配置
   • 打开.NET Framework 4.7.2项目属性页，切换到「生成」标签
   • 取消勾选「首选32位」选项
   • 若明确要加载x64版本的lib.dll，直接将目标平台设置为x64，彻底避免Any CPU带来的架构不确定性
   • 启动程序后通过任务管理器确认对应进程没有*32后缀，确认进程为64位架构
2. 修正P/Invoke封装，获取真实错误码
   给所有涉及错误码获取的Win32 API声明加上SetLastError = true配置，保证能拿到加载失败的真实错误码：

   internal class WinApi
   {
       [DllImport("kernel32.dll", CharSet = CharSet.Unicode, EntryPoint = "LoadLibraryW", SetLastError = true)]
       public static extern IntPtr LoadLibraryW(string dllToLoad);
   
       [DllImport("kernel32.dll")]
       public static extern uint GetLastError();
   
       [DllImport("kernel32.dll", CharSet = CharSet.Unicode, SetLastError = true)]
       public static extern bool SetDllDirectory(string lpPathName);
   }
   

3. 配置正确的DLL搜索路径
   在调用LoadLibraryW之前，先将lib.dll所在目录加入系统DLL搜索路径，避免因为工作目录问题找不到依赖：

   var dllDir = Path.GetDirectoryName(path);
   WinApi.SetDllDirectory(dllDir);
   var addr = WinApi.LoadLibraryW(path);
   

4. 排查DLL依赖
   使用Dependencies工具打开目标x64版本lib.dll，检查所有隐式依赖项是否都存在于输出目录或系统搜索路径中，重点确认对应架构的VC++运行库已安装，将缺失的依赖文件统一拷贝到程序输出目录。

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