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)

Bedraggled

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.

Laureen

Thank you. Since this question was posted in 2018, I've changed jobs twice, and my current employer does use ABCPDF for a couple things but not nearly as extensively as my old employer does. This package does not put the non-framework DLLs in the lib subfolder; they exist only in the build subfolder. I'll contact the vendor and see if they will change (or if they have a justification); and I'll also try manually copying them to the lib subfolder after adding the nuget. Doing that, even manually, "feels" better than copying them to %PROGRAMFILES%\LINQPad5. – Bedraggled

Unfortunately it didn't work -- neither constructing my own nupkg, nor copying the files to the extracted lib or lib\net40 folders. So, I'll keep using %PROGRAMFILES%\LINQPad5. – Bedraggled

What's the version of your LinqPad? And what's the package version? When I had tried it with the latest ABCPDF package, it did work for me. – Laureen

I have LINQPad 5.43.00 ... Check Updates says I have the latest release (Except for a beta version). – Bedraggled

Thanks Ross, could you also let me know the version of the Nuget package you're using? – Laureen

ABCpdf 12.1.0.5 – Bedraggled

@RossPresser One thing to watch out for is, by default, LinqPad 5 doesn't use regular NuGet cache that is under your user profile folder, %USERPROFILE%/.nuget. Instead, it uses a LinqPad specific one, which can be changed if you navigate through, NuGet package management, clicking on "Settings", and then selecting the "Advanced" tab. On my setup, it's default is %LocalAppData%\LINQPad\NuGet.FW46. I've used the following statement to test it: var point = new WebSupergoo.ABCpdf.XPoint();. This gives the same error as you do. After copying the DLLs to the relevant folder, it runs fine. – Laureen