Exit
  • Global community
    • Language:
      • Deutsch
      • English
      • Español
      • Français
      • Português
  • 日本語コミュニティ
  • 한국 커뮤니티
0

Acrobat DC version change to 17 broke our plug-in installer

Contributor ,
Apr 13, 2017 Apr 13, 2017

The change in the major version of Acrobat has broken the installer for our Acrobat plug-in.

My company, MarcomCentral (aka PTI Marketing Technologies), develops and deploys a plug-in to Adobe Acrobat called FusionPro VDP Creator, which is the design tool for our Variable Data Publishing engine.

We have built this plug-in for every version of Acrobat since Acrobat 6, on both Windows and Mac, though Acrobat DC.  We also build a plug-in for Adobe InDesign (since the pre-CS days, now through CC 2017).

In addition, we are a corporate partner of Adobe, and have also been members of the Adobe Developer Connection, as well as members of the plug-in developer prerelease programs for both Acrobat and InDesign, for many years.

One of the major challenges we have faced over these many years is programmatically figuring out where to install our plug-ins for various versions of Acrobat and InDesign, on both Windows and Mac, especially since different versions of these applications can require completely different plug-ins to be built, with different architectures and SDK versions.  (We need the installation program for our entire product suite to automatically install these plug-ins as appropriate, rather than relying on end users to manually locate the right folders and copy files to folders that they may not have permissions to.)

Unfortunately, for all of the documentation for the Acrobat and InDesign SDKs about how to build plug-ins, there's very little information about how and exactly where to install plug-ins onto end users' machines after they're built.  This lack of documentation has been discussed on the Acrobat SDK forum:

https://forums.adobe.com/message/8049304#8049304

(And on the InDesign SDK forum: https://forums.adobe.com/thread/885242 )

For Acrobat, on Windows, our plug-in installation strategy has been to look in the Windows Registry for the setting "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\Acrobat.exe", then calling the Windows API function GetFileVersion() on the path to Acrobat.exe, and examining the version to know which version of our plug-in (if any) to install to the Plug_ins folder in the same location.

So we have to hard-code into our installer what the minimum and maximum version of Acrobat is for each version of our plug-in.  This was pretty simple before Acrobat DC: Acrobat 9 had a major version of 9, Acrobat 10 was major version 10, and Acrobat XI was version 11.

With Acrobat DC, this pattern has been broken.  We had been looking for an Acrobat.exe with a major version of 15, which has worked fine since the initial release of DC.

But now that the major version has changed to 17, our installer no longer locates and identifies a version of Acrobat to which our plug-in should be installed.  This would be fine if the new 17 version of Acrobat DC required a new plug-in to be built, but that's not the case.  It also would not be as much of a problem if Acrobat did not automatically update itself to this new major version.

We can certainly change the version number of Acrobat that our installer is looking for, to install the same plug-in for versions 15 and 17.  But all existing versions of our installers out in the field will have this problem.

Also, it's impossible to know what the upper end of the version range should be.  We could change our installer program to not have any maximum version, but that will be a problem whenever Adobe decides that a completely new plug-in has to be built for a new version of Acrobat, where our old plug-in won’t work.  Then we’ll have the opposite problem, where we'll install the wrong plug-in.

So we face this dilemma, this Catch-22, where if we set a maximum version number to look for, that may break in the future when the version of Acrobat changes but it still can use the same plug-in, but if we don't set a maximum version number, that may also break in the future when a new version of Acrobat does require a new plug-in.

I would hope that Adobe would more carefully consider the needs of their partners and plug-in developers when making these decisions about version numbers and installation locations, or at least provide us with some guidance of how to properly determine how and where to install our plug-ins to various versions of Acrobat and InDesign.

Thank you.

TOPICS
Acrobat SDK and JavaScript
757
Translate
Report
Community guidelines
Be kind and respectful, give credit to the original source of content, and search for duplicates before posting. Learn more
community guidelines
no replies

Have something to add?

Join the conversation