.NET Core 2中fuslogvw的替代方案是什么？附具体问题
关于COREHOST_TRACE是否是fuslogvw的最佳替代
在.NET Framework里，fuslogvw确实是排查程序集绑定问题的利器，但到了.NET Core生态，官方并没有提供完全对等的工具。COREHOST_TRACE是官方推荐的核心调试手段之一，虽然不是唯一选择，但对于.NET Core 2.x版本来说，它是非常高效的方案，尤其是针对宿主启动、程序集加载和原生DLL查找的问题。
如何使用COREHOST_TRACE：
- 启用跟踪：设置环境变量
COREHOST_TRACE=1来开启控制台输出；如果想把日志保存到文件，再加COREHOST_TRACEFILE=corehost_trace.log。 - 查看输出：运行你的.NET Core应用后，日志会详细记录每一步加载操作——包括程序集搜索路径、原生DLL的尝试加载位置，以及成功/失败的原因。
- 重点解读：关注包含
Attempting to load native library的行，这里会列出系统实际查找DLL的所有路径，对比你预期的输出目录，就能快速定位问题。
其他替代方案：
- Process Monitor（ProcMon）：Windows平台下可以用这个工具监控进程的文件系统操作，过滤DLL名称，直观看到应用尝试加载DLL的所有路径和结果，适合排查更复杂的加载问题。
- dumpbin工具：对于原生DLL，用
dumpbin /dependents libwkhtmltox.dll查看它依赖的其他组件（比如VC++运行库），很多时候DLL加载失败是因为依赖项缺失，而不是自身找不到。 - .NET Core 3.0+的dotnet trace：不过你用的是2.0版本，这个工具还没推出，所以暂时用不上。
解决你的ASP.NET Core 2.0项目DllImport问题
你遇到的发布版正常、本地开发构建失败的情况，结合配置和错误信息，我整理了几个排查方向：
平台位数不匹配
你复制的是32位的libwkhtmltox.dll，但VS本地开发默认可能是Any CPU模式，在64位系统上会以64位进程运行，这时候无法加载32位DLL。- 解决：右键项目→属性→生成，把目标平台改成x86；如果需要支持多平台，就配置条件编译，根据平台复制对应位数的DLL（参考下面的配置示例）。
验证DLL是否真的复制到输出目录
有时候VS的复制操作可能因为缓存或配置问题没生效，去本地输出目录（比如bin/Debug/netcoreapp2.0）看看有没有libwkhtmltox.dll。如果没有，手动复制一份试试，若能正常运行，说明是VS的复制配置有问题。依赖的VC++运行库缺失
libwkhtmltox依赖特定版本的VC++ Redistributable，发布环境可能已经安装，但本地开发环境可能缺少。用dumpbin /dependents查看它的依赖，然后安装对应的VC++运行库（比如2017版的x86运行库）。用COREHOST_TRACE确认查找路径
按照前面的方法启用跟踪，运行项目后查看日志，看系统尝试加载libwkhtmltox.dll的路径是否包含你的输出目录。如果没找到，可能是输出目录不在宿主的搜索路径里，这时候可以尝试把DLL放到系统目录，或者调整项目的输出配置。
多平台复制配置示例：
如果需要同时支持x86和x64，可以修改项目文件为：
<ItemGroup Condition="'$(Platform)' == 'x86'"> <ContentWithTargetPath Include="Dependencies\wkhtmltox\v0.12.4\32 bit\libwkhtmltox.dll"> <CopyToOutputDirectory>Always</CopyToOutputDirectory> <TargetPath>libwkhtmltox.dll</TargetPath> </ContentWithTargetPath> </ItemGroup> <ItemGroup Condition="'$(Platform)' == 'x64'"> <ContentWithTargetPath Include="Dependencies\wkhtmltox\v0.12.4\64 bit\libwkhtmltox.dll"> <CopyToOutputDirectory>Always</CopyToOutputDirectory> <TargetPath>libwkhtmltox.dll</TargetPath> </ContentWithTargetPath> </ItemGroup>
内容的提问来源于stack exchange，提问作者user310988
