Installing plugins ?

[_Maximo_Balestrini_]

I have the following problem:
I can't make plugins to work on PCs different from the one I use to develop them.
I couldn't even make Skeleton or other samples work.

The error message is: "the plugin could not be loaded (14001) ( 48 :: 46 )"
(this is a translation from a spanish message)

Is there anything else I might need to install on the other machines, besides copying the .aex?

The PC that I use to develop has XP in english, and the others have XP in spanish. Could this have anything to do with the problem?

Thanks!
Maximo

[Bruce Bullis]

48::46 means After Effects couldn't load something required by the plug-in.

All the Windows samples are debug only, and rely upon the Microsoft DEBUG runtime DLLs.

To build plug-ins for use on a system that ISN'T used for development, you'll want to link to release DLLs.

See the Configuration Properties -> C/C++ -> Code Generation -> Runtime Library.

Let me know if that fixes it.

[_Maximo_Balestrini_]

I did that. Change Runtime Library to Multi-threaded DLL (/MD).
I've also made a deployment project that installs msvcr80.dll in Winsxs dir.

But nothing seems to work. I keep getting the same error when I try to apply the plugin.

Is there anything else I need to install or change in the Project properties?

[Bruce Bullis]

That's really weird; you did a complete clean & rebuild, right?

Use dumpbin.exe to find out what else your plug-in depends on.

[_Maximo_Balestrini_]

Yes... I did a "Clean Solution" and "Rebuild Solution" but that didn't work.
dumpbin throws these:
KERNEL32.dll
MSVCR80.dll

I did make a plugin work, but doing the following: I created a new Win32 DLL blank project, and the imported all the Skeleton files (already renamed files and content to the new plguin name), copied the custom building steps of .r, added AE headers, changed the output to .aex, etc. That plugin worked!

Then I tried to change all the project properties from the old project copying the ones from the new one, but that didn't work. I must be doing something wrong in VS.

But now that I've made something work, it will be a matter of time till I find the problem :), or create a new Skeleton based on a blank Win32 DLL.

Thanks!!

[Bruce Bullis]

Yikes.

[_Matt_Blackler_]

Are you using VC8? If so, I think this is to do with manifest files (whatever they are) that are now required when linking to the C-runtime DLLs. It's mentioned here http://blog.kalmbachnet.de/?postid=54 and also in MSDN somewhere (I couldn't find the link quickly). The gist of it is that it's not enough to have the DLLs on your PC any more, you must also install a manifest file with your plugin.

If I'm right, then the simplest solution is to link with the static libraries rather than the DLLs.

Matt Blackler

[_Maximo_Balestrini_]

Right now I'm working with a template project I've created from scratch, copying the PIPL building steps of the Skeleton sample. As I couldn't find the way to modify Skeleton to make it work (I'm not an expert in VC project/compilation settings), this was the only solution I've found.
This is working fine... at least in the tests I've been doing.

Thanks.
Maximo

[_rich_helvey_]

Is creating our own template project from scratch still the way to get plug-ins to run on non-development Windows machines or have any of you guys figured anything else out?

-Rich

[_rich_helvey_]

To answer my own question:

Copy:

msvcr80.dll
msvcp80.dll
msvcm80.dll
msvcr80d.dll
msvcp80d.dll
msvcm80d.dll

from the development machine to your non-development machine and put them into your system32 or winSxS folder.

At least it worked for me.

[Bruce Bullis]

The answer lies in the Project Properties --> C/C++ --> Code Generation settings. Change your Runtime Library settings to something NON-debug; Multi-threaded DLL usually serves.

[_rich_helvey_]

That didn't work for me, but I'm willing to bet that I'm doing something else wrong along the way.

Could I suggest including a non-debug sample in the next SDK release?

-Rich

P.S. Welcome back. :)

[Bruce Bullis]

We ripped out the Release configs a long time ago; developers were actually shipping not-terribly-updated sample projects.

[_mariobrosse_]

Maybe I've found an explanation: if you follow the sdk documentation (what I did), you start from the Skeleton project. You then create the release configuration if you don't want to install the visual debug runtime library on every machine. And it doesn't work... What I've found is that, in visual(2005), the properties of the files skeleton.cpp, Skeleton_strings.cpp, AEGP_SuiteHandler.cpp DO HAVE preprocessor definition with the _DEBUG symbol (even if your PROJECT properties do not). It worked for me nevertheless... I've removed these definitions (to be inherited now) and yes. I think it's a little messy to have these definitions by file (sometimes you don't have the choice...)

[Bruce Bullis]

Mario, were you checking the pre-processor stuff for the files while your current build config was debug, or release? Glad you got it to work.