Plugins calling native code work on most computers, on some they don't


it seems there is a problem on some computers with plugins I have recently released- TetGen and SpoutControls. They work fine on most pcs, but on some there is an error saying dll not found.
As nobody reported problems with Triangle I believe it has something to do with TetGen/SpoutControls calling a native dll. I have followed the instructions here vvvv sdk to compile from the addonpack solution, ie added this code to the plugin:

static SystemSpoutSenderNode()
            var platform = IntPtr.Size == 4 ? "x86" : "x64";
            var pathToThisAssembly = Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location);
            var pathToBinFolder = Path.Combine(pathToThisAssembly, "dependencies", platform);
            var envPath = Environment.GetEnvironmentVariable("PATH");
            envPath = string.Format("{0};{1}", envPath, pathToBinFolder);
            Environment.SetEnvironmentVariable("PATH", envPath);

(btw @devvvv: the vvvv-sdk page is missing the round brackets in this code)

It looks to me like the folder is not added to PATH, but I don’t know why.

I have only found 1 computer with the problem, but I do not have constant access, so it’s quite hard to debug; also I ran out of things to try. I can confirm now that on that 1 machine both SpoutControls AND TetGen show the same error. When I remove the above code and copy the dll next to vvvv.exe the dll still can not be found.
Also I can tell it seems to have nothing to do with OS, OS platform or vvvv version (x32 or x64).

Any ideas on what could be wrong would be highly appreciated, thanks in advance!

thanks to the great help of @leadedge I can answer that post (partly) myself: compiling the native dll with /MT (=Multi-Threaded) instead of /MD (=Multi-Threaded DLL) and therefore without /clr seems to solve the problem.

According to msdn for /MD

Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that enables the linker to resolve external references. The actual working code is contained in MSVCRversionnumber.DLL, which must be available at run time to applications linked with MSVCRT.lib.

which is not the case for /MT

_Defines MT and causes the compiler to place the library name LIBCMT.lib into the .obj file so that the linker will use LIBCMT.lib to resolve external symbols.

So I assume now MSVCRversionnumber.DLL is not present on systems where /MD doesn’t work, but I’m also not sure which install would solve that (setup is ok)…?
Anyway, I don’t see a problem compiling with /MT, so all is good!

Well I guess you need to install the proper Visual C++ Runtime Library at the target computer. Depends upon against which one you compiled. Our setup.exe checks only from 2008 to 2013.

aha aha check. thank you ;)