Native DLL in LINQPad

Question

I am referencing the NuGet package ABCpdf, which provides a managed DLL abcpdf.dll and four pairs of native DLLs, in x86 and x64 varieties:

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

Queries that run in a LinqPad that need one or more of these DLLs fail, unless I manually copy all these DLLs to %PROGRAMFILES%\LINQPad5, as suggested here by the LINQPad author @joe-albahari.

That was in 2016. Is there any more automatic way in 2018?

I tried adding a reference to the native DLL in the query properties; that generates this error

CS0009 Metadata file '..\ABCpdf11-64.dll' could not be opened -- PE image doesn't contain managed metadata.

And I tried using the Copy all non-framework references to a single local folder option, which sounds like it's designed for exactly this scenario. Unfortunately that didn't work either; still got this error

DllNotFoundException: Unable to load DLL 'ABCpdf11-32.dll': The specified module could not be found. (Exception from HRESULT: 0x8007007E)

Answer 1

I believe unlike Visual Studio, Linqpad doesn't have a "Build" step and loads referenced assemblies into the Linqpad process dynamically. The consequence is Linqpad cannot run the additional build tasks that may normally be installed as part of a package installation which then can be run by the MSBuild process during the build stage. I'm not 100% sure if that's what's happening here but if your VS Project is running fine, then this seems to be the likely cause.

In theory, and I'm 100% speculating here, support for these packages can be added to Linqpad, but, and I'm being rhetorical here, is it worth it (from a software economics PoV), or is it even the right solution? I would even argue package authors have more say in this.

In any case, there may be a way to do it yourself (it'll be a dirty hack). In a NuGet package, the managed libraries can be found in the respective framework folders under the lib folder of the package, and if they also require native DLLs, technically they should also be bundled in the same folder, alongside with the managed ones.

So, you may have a few other options here: You can try asking the package authors to see if they're willing to duplicate and include the native DLLs along with the managed ones in their package and that would solve your problem (this is the ideal case!)

Or alternatively, if you're a DIY type of person and willing to spend some more time on this, potentially you can write a script/app that would do this for you automatically and save a new package locally. All you'd have to do is then reference that local package instead.