#Active pdf toolkit pdf
#Active pdf toolkit full

The next step was to understand why the old version was being referenced.We then tried to replicate this locally, by replacing some of the installed DLLs. This confirmed that it was indeed because the version. With this, we noticed that the version on common environments was an outdated version.One of the great features that helped was checking the version of the toolkit, we used this to log the version of the API being used. To compare what was different across the developer workstation and shared environments, we then decided to log the version of the API being used.We found that it would fail consistently when the file had a password. With the new process in place, we tried multiple permutations and combinations and tried to replicate the issue consistently.This allowed us to make quick changes, deploy and test quickly. Then with help of the operations team, we setup a process that allowed quick deployment of this application (basically with direct access to the web root of the application).

#Active pdf toolkit pdf

We created a simple ASP.NET MVC that read a local PDF file to try and reproduce the issue.

We first decided to speed up the process. Since the environment was controlled, making any changes, deploying and testing required a lot of time.The Active PDF documentation indicates few reasons behind this but nothing conclusive (link below):

The OpenInputFile statement was consistently returning a non-zero input on certain environments. Inputfile = toolkit.OpenInputFile( ' MEMORY') Using ( var tookit = new APToolkitNET.Toolkit()) This seemed to work on local developer workstations, however on the shared environments INT, QA it was failing.

One of the features required reading a standard PDF template from a remote service, updating it with user data, and publishing it.

#Active pdf toolkit full

Since the environment where the application was failing was controlled, we had to create a sample test application that could be easily deployed and tested without a full build cycle.

Windows uses DLLs in two different folders based on System32, SysWOW64 folders based on the run-mode of the application.

The main reason behind failures was due to version conflicts, yes even though the DLLs were included as part of the web application.

While resolving the issue, we uncovered facts and tactics I wanted to share with the broader community, specifically with IIS and ActivePDF. The main issue was that the API was consistently returning a -1 on certain environments with no additional details related to the type of failure. My team recently encountered an issue related to Active PDF in an ASP.NET based application (which wasn’t cloud native and containerized) that was a bit tricky to identify and resolve.