Illustrator CC 2019 not loading Plugin

[StefanAchi]

Hi,

I have a plugin that worked fine till now. But when i updated Illustrator (to CC 2019), the plugin is not loading anymore.

What I found out during debuggin was, that i get an error message while initializing the Suites (Error: 1394689636).

The plugin works on most other Illustrator versions (2015, 2015.3, 2017, 2018), but not on the newest.

I use the CC14 SDK!

Somebody an idead, whats the problem here?

Thanks,

Stefan

[A. Patterson · Accepted solution]

Try using the CC2019 SDK. They only support older suite versions for a

couple of releases. I'm surprised it worked for CC2018 frankly.

[StefanAchi]

I updated to CC2019 SDK, and now my plugin works for Illustrator CC 2019! Thanks!

But now I have the problem, that it does not work for the CC 2018 and CC 2017 anymore.

Is the SDK not backwards compatible?

[A. Patterson]

Supposedly releases are backwards compatible for a couple of versions, but it's sort of on you to make that happen. To do it, you'll need to know what suites you're using and and which versions are available in each release.

E.g. The AIArtSuite gets updated in most releases. That said, it didn't get updated in CC2019, so the version for CC2018 & CC2019 is the same - 20. But CC2017 was version 19. So when you're loading that suite (which I assume you use) you'd have to make sure you don't ask for a version that's not available (i.e. 20 in CC2017).

If you wrote your plugin for CC2017 then you're not making any calls to APIs that were added in CC2018 or CC2019, so you don't have that problem. It can get complicated if you're trying to leverage functionality in the higher versions, because you need to account for that in the lower ones. I don't think that will affect you though from the sounds of it.

You can get the version of the application from the AIRuntimeSuite, but of course, it also has the same constraints, so be careful.

Thinking about it, a cheap & easy way to do this would be to modify the code that acquires suites so that it doesn't fail when it can't get the requested suite, but instead tries with the next version down. So it would start with kAIArtSuiteVersion and if that fails, it would try kAIArtSuiteVersion - 1, etc. If you're using code Adobe ships in their examples for loading suites, it shouldn't be too hard to modify it to do that.

[StefanAchi]

So now I modified my code to the following:

• Load all required suites
• If the suite can not be loaded, try with a lower version number (repeat this till suite can be loaded successfully)

This seems to be working for Illustrator CC 2019, CC 2018 and CC 2017.

But now in Illustrator CC 2017, the following call throws an Exception:

"AIErr error = sAIUser->GetUnitsString(kShortUnits, unit);" --> Exception thrown at 0x0000000000B9AFB0 in Illustrator.exe: 0xC0000005: Access violation reading location 0x0000000000000000.

The AIUserSuites I'm loading:

• v(16) for Illustrator 2019 --> working
• v(15) for Illustrator 2018 --> working
• v(14) for Illustrator 2017 --> crashing

The call is not new, so it worked with the Illustrator SDK 2014!

Any ideas, why I'm receiving this error?

Thanks!

[A. Patterson]

I don't have the CC2017 SDK locally anymore (we only support

CS6/CC2018/CC2019) so I can't compare the headers, but CC2019's AUser.h

header has a call, SetUpdateProgressCallback that is not present in the

CS6 version of AIUser.h. I don't know when that was added, but it was added

in CC2018, that would explain the problem.

Basically, the suite structs don't have to be exactly the same, but to work

in an older version using the newest headers, they have to be the same at

least as far as any function you're calling. Adobe used to add new

methods to the bottom of headers and renamed remove functions with

'_deprecated', but they stopped being so diligent in CC.

Compare -- carefully! -- the CC2017 AIUser.h & the CC2019 AIUser.h headers.

The preamble at the top doesn't matter as much as everything from 'struct

AIUserSuite {' on. It's important that:

1. Functions remain in the same order (this also means no new functions

are added or removed from the order)

2. That parameters are the same types.

If either is violated you'll get an error like the one you're experiencing,

because CC2017 only knows (internally) about the CC2017 version of the

struct. But you've described the CC2019 version, and it's trying to overlay

the former on the latter. If they're not the same, Bad Things Will

Happen(tm). I'm guessing that's what happened in this case.

Assuming I'm right, and the CC2017 header is different, you need to do a

couple of things:

1. Make a copy of the CC2017 header, renamed as something like

AIUser2017.h

2. You really only need the struct so you probably can eliminate

everything else; just include the CC2019 version of the header (i.e.

#include "AIUser.h") -- that will get you most of the same enums, etc.

3. Rename the struct to something like 'struct AIUserSuite2017'

4. Conditionally load the CC2017 version of suite if running CC2017, and

don't try to load the other version if you're not

5. Anytime you make a call on the user suite, you'll have to check the

AI version and run the appropriate suite (i.e. AIUserSuite2017 for CC2017

and AIUserSuite for CC2018/9)

If you make a lot of calls to a small number of methods in the user suite,

you could always wrap all this behind a class intenrface, say, CUserSuite

and then expose ontly the functions you call. I've done this in the past,

but it's a pain. Basically, if you want to create a single binary to run on

multiple versions of Illustrator, this is the reality. This is why we opted

to just build separate plugins for each version. It's not painless; it

means we have to #ifdef stuff sometimes, but in this case, I wouldn't have

to because each binary would be pointing at the explicit version of it's

SDK headers.

Good luck. I miss the days when safe-to-use versions of all the previous

suites were included with every SDK. But I also understand what a PITA it

probably was to maintain.

On Wed, Nov 14, 2018 at 6:55 AM SstefanAchi <forums_noreply@adobe.com>

[StefanAchi]

Thanks for this answer, but this is to much work, so I decided to not support AI 2017 anymore.

But, anyway I'm facing a different problem now:

On my machine, AI starts without an error, and loads my plugin successfully.

But on other machines, AI can not load my plugin "Error on loading plugin."

What I found out now: If Visual Studio 2017 is installed on the machine, the plugin loads, if it is not installed, it fails.

Any idea what I'm making wrong?

[A. Patterson]

The first and most obvious culprit is usually the runtime. Installing VS2017 implicitly installs the VS2017 runtime, but most other computers won't have it. This creates a dependency on the runtime and when a dependency is missing, you will just get 'Error loading plugin'. If you're not installing the VS2017 runtime as part of your installation, you should. You should be able to find it on the Microsoft website if you search.

[StefanAchi]

This does not seem to fix the problem.

Is it somehow possible to get a detailed error message about what is missing on startup of the plugin?

[A. Patterson]

There's no way to get more information out of Illustrator. These are the worst kinds of problems, but I can tell you what I do:

1. Determine if your plugin is ever loaded. We have a log into which we can dump trace statements; if you have something like that, make that the very first thing your plugin does; basically, find out if your plugin *ever* executes. That said, I suspect it's *not* executing, but it's a waste of time to do #2 until you can verify that.
2. If your plugin isn't executing, it's almost certainly a dependency issue. My previous answer is a form of this problem. The best way to check it is to use Dependency Walker. It's a free utility that will show you what any executable or DLL is expects/requires to be present to run. Best of all, it's small, so it's easy to run it on the machine having the problem!

It can be a bit tricky to use Dependency Walker, especially for an Illustrator plugin. A plugin is really a DLL, and likely isn't located next to the executable that loads it. So to work around this issue, when you launch the Dependency Walker, there's an icon on the toolbar that looks like a folder with a magnifying glass on it (Configure Module Search Order). Click this and it will bring up a dialog that shows where Dependency Walker will look for dependencies; it's a way to simulate how Windows would search for them. In the bottom right there's a 'Browse' button -- click that and select the Support Files\Contents\Windows folder inside your target Adobe Illustrator folder. Once you've picked it, it will populate the path into the line edit next to the 'Browse' button. IMPORTANT: you need to click the 'Add Directory' button to the left of the line edit and then hit OK in the upper right before it will take effect.

Once you've done this, you can use the open button on the toolbar to browse to your plugin. After picking it, it may take a minute or two to work. When it's loaded, I recommend right-clicking on the root tree item and picking 'Collapse All' -- this will take a few seconds to run. After that, you can expand it slowly, step by step and see what's missing.

The first set of children will be direct dependencies on your plugin. If there's a yellow ? next to the dependency, it means it couldn't be located. In all likelihood, if there is one, you'll recognize it and the next step will be to figure out why it's considered missing. Was it not installed? Was it installed somewhere Illustrator couldn't find it?

If you expand each dependency, you can see their dependencies in turn. Maybe all your direct dependencies are fine, but one of them is missing something it needed to load. If that's the case, it wouldn't load either, which in turn would mean your plugin would fail to load.

The other really useful thing Dependency Walker does is show you right in the icon if the dependency is 32 or 64-bit. If it says '64' next to the icon, it's 64-bit; otherwise, it's 32-bit. I've had cases where I accidentally installed a 32-bit version of a dependency when I meant a 64-bit, or the opposite. Dependency Walker is great for spotting that.

At any rate, it's usually at this point that I find my problem and give myself a hard slap for doing something stupid. Hopefully you find it helpful too!

[user8013581]

Hi, do you have experience how to solve these kind of dependency problems on macOS?

[StefanAchi]

Hi Patterson,

thanks for your very helpful answer.

When I started to search for the problem with dependency walker, I found out, that my plugin tries to load some debug-dlls. Then I checked my Visual Studio Settings for the Release build one more time and found out, that under "C/C++ > Code Generation > Runtime Library" I used the "Multi-threaded debug DLL", which is fore sure not correct for a release build. When I changed it to "Multi-threaded DLL" it all worked!

And yes, as you said: "at this point that I find my problem and give myself a hard slap for doing something stupid"!

Thanks a lot!

[A. Patterson]

Glad to hear you figured it out!

Dependency Walker is a great tool once you've got the hang of it. I used to have this headache all the time on & off, and once I had this tool in my repertoire, I fixed that problem much, much faster when it happens.