CODEWITHSUNDEEP
c++visual-c++visual-studio-2013
Dave
Dave

Reputation: 8641

Visual C++ / Visual Studio settings. What is calling for MSVCR120D.DLL

enter image description hereBackground. I ran a release version of my program on another computer and immediately got a message, "Could not find Your_DLL.dll or one of it's dependencies". I believe I've tracked this down to the fact that "Your_DLL.dll" makes use of MSVCR120D.DLL . I checked this using Dependency Walker (Depends.exe). On my original computer, all is well because I have the full Visual Studio (2013) and MSVCR120D.DLL is present. However, it is not present on another machine, nor should it be as it's a Debug version of MSVCR120.DLL. I'm pulling my hair out trying to figure out where in my project for "Your_DLL" I am making use of MSVCR120D.DLL or have any debug settings under the release build. A search for MSVCR120D.DLL in the whole directory turns up nothing. Of course, perhaps something in the settings for the release build is somehow making use of a debug dll that in turn calls this debug dll. Can someone give me a clue where to look for the problem?

Thanks,

Dave

Upvotes: 1

Views: 490

Answers (2)

Dave
Dave

Reputation: 8641

Thank you for all the answers. We found the problem, and I must admit that I'm the one who caused it! "Your_DLL.dll" was building just fine in Debug and Release. The problem was how I was using it from another dll. The other dll was a C# project and under references, I added "Your_DLL.dll". Unfortunately, I left the "Copy local" to True. By company policy, we build everything to a central place C:\bin\debug or C:\bin\release. Also, by company policy, when we add a reference, we pick the debug version (you have to pick one!) but make sure to have "Copy Local" as FALSE. So when our build script builds, it correctly builds "Your_DLL.dll" and puts a release version in C:\bin\release. However, when CSharp.dll is subsequently built, it was putting a debug version of "Your_DLL.dll" in C:\bin\release. We finally noticed the problem when we saw that the version of Your_DLL.dll was the same size in c:\bin\debug and c:\bin\release.

I've always had a sinking feeling about the way we handle references. Perhaps there is a better way? But that's probably a whole other stack overflow question.

I hope this helps someone in the future. Thank you, Dave

Upvotes: 0

Vlad Feinstein
Vlad Feinstein

Reputation: 11321

The flavor of a run-time library is specified in the compiler switch /M...

For dynamically linked CRT, it should be /MD for release config, and /MDd for debug. I would check that first, by looking into:

Project Properties -> Configuration Properties -> C/C++ -> Code Generation -> Runtime Library

[added] The Depends tool has a "Profile" command (Profile -> Start Profiling), where you can see a run-time information for dynamically loaded DLLs. Hope that will point you to the offender.

Upvotes: 1

Related Questions