PDF Toolkit DLL Errors - DLL not listed in guide

[RobWood]

Hi, 

I have a requirement to convert a PDF doc into a Word file. I've selected the PDF Toolkit but I am running into errors surrounding some of the DLL Dependencies. My vers of of BP is 6.8.

I have followed the steps within the PDF Toolkit guide to get the Adobe.PDFServicesSDK v2.2.1 and all DLL Dependencies listed within the screenshot. These have all been added to the BP automate folder. When I try and run through the PDFToDocx action (via the PDF Toolkit Test process) I am receiving an error for the  System.Linq.dll file not being loaded:

"Exception encountered while executing operation:Adobe.PDFServicesSDK.exception.SDKException: Unable to sign jwt token. ---> System.IO.FileLoadException: Could not load file or assembly 'System.Linq, Version=4.1.2.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) ---> System.IO.FileLoadException: Could not load file or assembly 'System.Linq, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)..."

I've managed to resolve other errors that we're related to the DLLs listed in the screenshot of the guidance, but this DLL is not listed anywhere in the guidance and doesn't come with the core product as standard. I've tried adding in different vers of the System.Linq.DLL file, and have tried adding external references / Namespace import for the DLL, but the error continues to appear. 

How can I resolve this in order to get the object working?

Thanks, 

Rob 

[GeoffHirst]

HI Rob,

Thank you for being an SSC Blue Prism customer. You have an interesting issue here, and not one I have seen before.

I hold my hands up here, I omitted to include the .NET framework dependencies from the user guide. I will duly update this.

What I would ask is, what version of the .NET framework do you have installed? Could you clarify this for me before I send you down the wrong path? Usually, for framework dependencies, they are found in the GAC but this seems to not be happening in your case.

If you can answer the above and come back to me, I will do what I can to assist you further.

regards

Geoff Hirst
Snr DX Engineer EMEA - SS&C Blue Prism

[RobWood]

Hi @Geoff Hirst

Appreciate your help with this, we are using vers 4.7 of the .Net framework with our current BP setup

Regards, 

Rob

​​

[GeoffHirst1 · Accepted solution]

Rob,

Thanks for the feedback here. Now, this is my suggestion to you. This is how I implement 3rd party assemblies into Blue Prism.  Do you have access to Visual Studio 2019? There is a community edition available if you don't have it. Now the trick here is to create a Windows console application, personally my language of choice is C#, however VB will work just as well. The reason I do it this way is because most assemblies have dependencies and unless you want to dance around the contents of nuget files and their contents its the easiest way to find all those dependencies.

In this windows console application, under the project choose manage nuget packages and add Adobe.PDFServicesSDK assembly to your project. Now, if you then do a build of the project, you will find that where your console application lives on your hard drive there will be a bin/debug folder. Inside this folder will be your console application, it may not do anything but the associated assemblies will be visible.

What I think may be happening in your case is that you have some .NET Core dills involved and this is causing the problem. Without direct access to your machine I cannot confirm this, I am just going off the fact that this asset generally works well and we have a number of users making use of this asset, there are some issues that can be addressed with Blue Prism 6.10.x but you are using 6.8, which is only a version behind the version I used to develop this asset.

So, can you give the above a try and come back to me. We know the asset has some issues converting PDFs into office documents other than Word, but I am working on a fix to resolve this problem. My general recommendation is not to copy over framework assemblies, until I have begun testing the asset and I then work thru the errors that occur, hence the fact they aren't included in the manual.

I will await your response.

regards

Geoff Hirst
Snr DX Engineer EMEA - SS&C Blue Prism

[RobWood]

Hi Geoff, 

I went with a clean slate creating a new console app, and followed your suggestion to do a build on the project. I've then copied across all of the DLLs available in the bin/debug folder and placed them into the automate directory. The PDF test process and toolkit object is now working correctly and I'm getting the expected result (docx output from converting a PDF file). 

As you mentioned, I did try and take some of the dependencies listed in the guide document straight from nuget, and along the way I've grabbed the wrong vers of a DLL (couldn't tell you which one though). In the end, no additional DLLs are required outside of those listed in the guide. Performing the Build of the project and grabbing the dependencies from their is much safer and eliminates the risk of getting that wrong vers.

Thanks for your help!

Rob

[GeoffHirst1]

Rob,

That is superb news sir, really pleased I was able to help and get you moving in the right direction. There will be updates to this asset in due course and I am hoping to come up with a better solution for the install.

So, all that remains is for me to say is, please come back to us if you have any further issues.

Thanks again for being a SS&C Blue Prism customer.

regards

Geoff Hirst
Snr DX Engineer EMEA - SS&C Blue Prism

[RobWood]

Hi @Geoff Hirst,

Just wanted to add that I've found some minor issues when working with APIs through BP, in conjunction with the updated DLLs from the PDF Toolkit Object. Specifically the Newtonsoft.Json.dll change in versioning from the default file available within the automate folder (11.0.0.0)​ to the updated version (12.0.0.0) caused errors when it came time to run various API calls.

This is only an issue since testing across various processes is being performed on the same TST VM, and with the separation of processing in PRD we won't be running into this issue. I imagine that an Assembly Redirect (similar what is being done with the System.Buffers.dll) can be applied to the API calls to resolve the issue. Just something to keep in mind.​

Regards, 

Rob

[GeoffHirst]

HI Rob,

Thanks for the heads up. It's interesting you are hitting this problem with Newtonsoft, as my version 6.9 has version 12 of newtonsoft and runs fine. So, I can't help but wonder if there was a change in 6.9 that revised the version of Newtonsoft in use, (or I have just replaced mine with V12, but if that was the case, I would get the same errors as you.) I have some revisions for the PDF Toolkit planned for the next quarter which I hope will resolve a few of the oddities that are occurring. The main issues lie with converting PDF's to other document formats, Blue Prism seems to have a problem, intermittently. So, I am looking to create an API wrapper around those calls to see if that resolves the problem.

However, many thanks for your input, most appreciated.

regards

Geoff Hirst
Snr DX Engineer EMEA - SS&C Blue Prism