ANN: Improved AnyCPU support for PDFNet for .Net

With the release of our Nuget package, was improved AnyCPU support for .Net.
https://www.nuget.org/packages/PDFNet/

However, for our existing clients, you can also get the benefit of this setup without using nuget, by following these instructions.

First let us assume your output dir (where your exe is created) is ‘bin’.

  1. Create a folder in ‘bin’ called ‘PDFNet’
  2. In ‘PDFNet’ create two folders, one called ‘x64’, other is ‘x86’
  3. Place the PDFNet.dll for x86 and x64 in the respective folders above.
  4. Download PDFNetLoader.dll : https://github.com/PDFTron/PDFNetLoader/releases/download/v1.0.0.0/PDFNetLoader.dll
  5. In your Visual Studio project add PDFNetLoader.dll as a reference.
  6. In your Visual Studio project add bin/PDFNet/x86/PDFNet.dll as a reference.
  7. Right click the PDFNet.dll (not PDFNetLoader.dll) in your references, and select Properties.
  8. Change the “Copy Local” property to “False”
  9. Somewhere in your code, as early as possible, and before any PDFNet methods are called, add the following line.
private static pdftron.PDFNetLoader pdfnet = pdftron.PDFNetLoader.Instance();

You are now ready to run your project in AnyCPU.

The project references to PDFNet and PDFNetLoader allow you to code normally.

At runtime though, the following will happen.

  1. the PDFNetLoader.Instance() method is triggered, which registers itself as an event handler for AppDomain.AssemblyResolve
  2. JIT encounters a method that uses PDFNet and tries to load PDFNet.dll, but because of the “local copy:false” this fails.
  3. PDFNetLoader gets the AssemblyResolve event, detects if system is 32 or 64 bit, and loads the corresponding PDFNet.dll.

The source code for the loader is here: https://github.com/PDFTron/PDFNetLoader/releases

Also, if you want to change the load path, you can all

private static pdftron.PDFNetLoader pdfnet = pdftron.PDFNetLoader.Instance().Path("my_path_to_folder_containing_x86_and_x64_subfolders");

And PDFNet will look for subfolders called x86 and x64 in the specified dir.

We are looking for feedback, so feel free to contact us with how it went if you try.

Interesting approach, thanks!

We have found another neat trick. It requires the project/solution be EITHER 32-bit or 64-bit, and based upon that setting, it loads the correct DLL while running on the bench, in the debugger, and when building the kit, selects the correct bitness PDFNet.dll for the deployment. The setup is small because it only includes ONE version of PDFNet.dll. It requires a manual edit (with Notepad, etc.) to any project which makes reference to PDFNet.dll. We have isolated direct access to PDFNet.dll in general projects, and one utility project makes that reference, so we don’t have to do this pervasively.

With this the REFERENCE for the project changes dynamically depending on the build target platform. It affects solution builds, bench runs, and kit builds.

But anyway, edit the referring projects VBPROJ file as:



…\Core\PDFNet\Lib$(Platform)\PDFNet.dll

Obviously we have a central source repository folder for PDFNet, Core\PDFNet\Lib with x86 and x64 sub-folders. These sub-folders are ONLY needed in the repository folder where we keep PDFNet.dll.

  • Cheers!

Great thanks for the tip!