Operating system dependency of plugins ?


as I reported in an earlier post, I successfully created a plugin with Visual Studio 2010.

As build target I selected Win32 and then copied the resulting dll simply into the plugin folder of my EndNote X4.

When I start EndNote, I then get an additional menu entry under “Tools”, as expected.

I did all this on my 64bit Windows 7 machine.

Now I copied the dll into the plugins folder of an EndNote X4 running winXP SP3, 32bit.

And it does NOT work !!   That means there appears no menu entry.

What could be the reason ?  

Are there any special dependencies on the operating system ? 

Do I need any additional support file ?


It is possible that your project is set to do dynamic linking to some resources.  Since I use Visual Studio 2008 I cannot open your 2010 project.  I know that if you have 2008 set to build the Debug target this will happen unless the machine you copy the plugin to has 2008 installed also.


I also have a machine with 32-bit XP, SP3 installed and plugins work fine in that environment - it’s often the one I use when diagnosing plugin issues.  So that’s not your issue.  However, your plugin doesn’t appear in the tools menu on my machine either (I was able to download the package from FreeMind).

My guess is that your plugin has dependencies on other DLLs that are not present on the second machine.  That would be something your machine and mine would have in common.  If a DLL has a dependency that can’t be resolved, EndNote (or any program, for that matter) won’t be able to load it.

Likely your plugin depends on a DLL that’s installed on the Windows 7 machine, but isn’t on your (or my) 32-bit XP machine.  If I had to guess, I say it’s one or more of the DLLs from Visual Studio 2010, as I don’t have that installed on my XP box and wonder if you don’t either.  That would make the most likely culprit the C-runtime DLL.  Every version of Visual Studio has its own C-runtime, so programs/DLLs built with a given version of VS require the relevant C-runtime DLL to exist on the machine where the code will run.  This is one of the things that makes installers necessary when sharing the binaries, rather than the source, especially because older operating systems don’t automatically have the runtime DLLs for newer development tools (like XP won’t have 2010 bits and pieces until you put an app built with 2010 on it and its installer installs those pieces for you).

You should check your project settings and see to which libraries it is linking. That will let you know what needs to be installed on the XP box - or removed from your project setting if your plugin really doesn’t need them.  Since you shared your code as open source, other people can build the plugin using a version of VS that will work for their machines.  Or, if you want them to use your compiled dll, and not provide a installer, you could change your project settings so that the C-runtime is statically linked, rather than dynamically (via DLL).  That will bloat your binary size, but it should avoid hassles like worrying about whether all the pieces are installed on the target machine.


ah yes, statically linking the C-runtime solved the problem !

Many thanks,