我引用的是NuGet包ABCpdf，它提供了abcpdf.dllx86和x64品种的托管DLL 和四对本机DLL：
packages\ABCpdf\11.2.2\build\PrintHook64.dll
packages\ABCpdf\11.2.2\build\3DGlue11-32.dll
packages\ABCpdf\11.2.2\build\3DGlue11-64.dll
packages\ABCpdf\11.2.2\build\ABCpdf11-32.dll
packages\ABCpdf\11.2.2\build\ABCpdf11-64.dll
packages\ABCpdf\11.2.2\build\ChakraCore32.dll
packages\ABCpdf\11.2.2\build\ChakraCore64.dll
packages\ABCpdf\11.2.2\build\PrintHook32.dll
在LinqPad中运行的需要一个或多个这些DLL的查询会失败，除非我将所有这些DLL手动复制到%PROGRAMFILES%\LINQPad5，这是LINQPad作者@ joe-albahari所建议的。
那是在2016年。2018年还有更多自动方式吗？
我尝试在查询属性中添加对本机DLL的引用；产生这个错误
CS0009 Metadata file '..\ABCpdf11-64.dll' could not be opened -- PE image doesn't contain managed metadata.
我尝试使用“ 将所有非框架参考复制到单个本地文件夹”选项，这听起来像是针对这种情况而设计的。不幸的是，这也不起作用。仍然出现此错误
DllNotFoundException: Unable to load DLL 'ABCpdf11-32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)
我相信与 Visual Studio 不同，Linqpad 没有“构建”步骤，并将引用的程序集动态加载到 Linqpad 进程中。结果是 Linqpad 无法运行通常作为包安装的一部分安装的附加构建任务，然后可以在构建阶段由 MSBuild 进程运行这些任务。我不能 100% 确定这是否是这里发生的情况，但如果您的 VS 项目运行良好，那么这似乎是可能的原因。
从理论上讲，我在这里 100% 推测，对这些软件包的支持可以添加到 Linqpad，但是，我在这里反驳一下，这是否值得（从软件经济学角度来看），或者甚至是正确的解决方案？我什至认为软件包作者在这方面有更多发言权。
无论如何，可能有一种方法可以让你自己完成（这将是一个肮脏的黑客）。在 NuGet 包中，托管库可以在lib包文件夹下的相应框架文件夹中找到，如果它们还需要本机 DLL，从技术上讲，它们也应该与托管库一起捆绑在同一文件夹中。
因此，您可能还有其他一些选择：您可以尝试询问软件包作者，看看他们是否愿意复制本机 DLL 并将其与托管 DLL 一起包含在其软件包中，这将解决您的问题（这是理想情况！）
或者，如果您是 DIY 类型的人并且愿意在这方面花费更多时间，您可能可以编写一个脚本/应用程序来自动为您执行此操作并在本地保存新包。您所要做的就是引用该本地包。