1

I've written a DLL, using C++/CLI, which runs fine on my Windows 7 x64 PC. Its only dependencies are VC++ (msvcr120, msvcr120_clr0400 and msvcp120) and some of OpenCV's modules (opencv_core2410, opencv_high2410, opencv_imgproc2410).

I've tried running the code that consumes this DLL on a Windows Server 2008 R2. This server has both versions (x86/x64) of MSVC++ 2013 Redist installed, and I verified that the DLLs are present in the C:\Windows\System folders.

I've tested it both through a IIS service and through a Windows Form, and in both cases it fails to find MSVCP120.dll. I checked using Process Monitor, and it looks for this file in C:\Windows\SysWoW64, C:\Windows\system, C:\Windows and lots of other folders, but not on C:\Windows\System32.

So I copied the MSVC*120 files from the System32 folder into the executable folder and it executed normally. So, how do I fix this? It is easier to just copy the DLLs, but I'm considering this wouldn't be the best practice, is there anything I should do to ensure it looks for the DLL in the right folder?

Eric Omine
  • 489
  • 4
  • 15
  • Your assumption that this is x64 code is just wrong. Process Monitor tells you what happened, only a 32-bit process ever looks in c:\windows\syswow64. Don't change anything, local copies of these DLLs is best. – Hans Passant Oct 16 '15 at 21:55
  • @HansPassant The software consuming the dll is 32-bit, and my guess is it should work with 32-bit C++ Redist, usually it does work. I didn't understand why it worked with the dlls from the 64-bit one. – Eric Omine Oct 19 '15 at 12:19
  • @HansPassant So I did try and do what you've said: I copied the x86 dlls into the binary folder and it ran, and also fixed another error I was getting somewhere else. Still, I wonder why it didn't open the dlls from the SysWOW64 folder. I'll start deploying the package with these dlls inside, even though target machines have the C++ redist installed. – Eric Omine Oct 20 '15 at 17:53

1 Answers1

0

Use Statically link to the VS runtimes, instead of using dynamic linking to the runtime DLLs.

for do this you can set RunTime-Library to Multi-threaded for your DLL project:

in the IDE through project settings under C/C++ > Code Generation > RunTime Library > Multi-threaded (/MT) or (/MTd).

then compile the project and use your dll anywhere without any problems!.

Note : You should compile your project in the release mode.

Maria
  • 344
  • 8
  • 30
  • I'm sorry, I think I've given incomplete information. What I'm doing is a C++/CLI wrapper for a native C++ project (compiled to a .lib). I can't use /MT with the wrapper because it's incompatible with the /clr flag, which is necessary for the C++/CLI project. Also, C++/CLI projects depend on MSVC*.dll files, so I guess it wouldn't matter if I used static linking on my native project. – Eric Omine Oct 19 '15 at 13:43
  • I've found this discussion here where someone explains why /MT and /clr are incompatible: "Considering that it is not recommended to statically linking to VC libraries and dynamically linking should be used whenever possible, it was decided to not enable /MT /CLR VS2005". Is this wrong? http://www.windows-tech.info/17/5f0fd2024b850de5.php – Eric Omine Oct 21 '15 at 12:05
  • Unfortunately, I'm not sure this is true or not ,May be I am wrong, so please see [this](http://stackoverflow.com/questions/15386749/mt-and-clr-not-compatible) and [this](http://stackoverflow.com/questions/938539/why-is-clr-incompatible-with-mt-and-mtd-in-visual-studio) – Maria Oct 22 '15 at 19:12
  • You see I'm not disagreeing with you, I'm just in doubt. I think the person at the link I posted above hasn't given a full explanation, as he hasn't said why it wouldn't be recommended. Sure, when /clr is used, that's not even an option, how could someone recommend it? But when there's no CLR, I think it would only make sense to disallow static linking if MS automatically updated MSVC on clients' machines, but I don't think they do that. – Eric Omine Oct 22 '15 at 19:59