<a>msvcr100.dll</a>
this msvcr100.dll is the microsoft visual c++ redistributable dll that is needed for projects built with visual studio 2010. the dll letters spell this out.
ms = microsoft
v = visual
c = c program language
r = run-time
100 = version
if you create a c++ project in visual studio 2010, this file is probably needed.
this msvcp100.dll is the microsoft visual c++ redistributable dll that is needed for projects built with visual studio 2010. the dll letters spell this out.
cp = c++
the msvcr100d.dll is almost the exact same file only the d at the end stands for debug. this file has debugging enabled and is not considered redistributable.
ok, so recently i switched to visual studio 2010. i had a c++ application that worked perfectly in visual studio 2008. once i compiled it with visual studio 2010 and ran it on a clean 2008 server (fully patched but otherwise clean), it failed to run with the following error.
testwin32.exe – system error
the program can’t start because msvcr100.dll is missing from your computer. try reinstalling the program to fix this problem.
here is the screen shot:
the same things happens with the debug version of the file, only it is a the debug version of the same dll as noted by the fact that the dll name ends with d.
autorun – system error
the screen shot is identical except for the d in the dll name.
i create a new project in visual studio 2010 using the project type of c++ win32 project and without making a single change to the default project, i built the file and tested it on my clean machine and the same issue occurred.
so obviously that is not acceptable. it seems like this should just not happen by default, but unfortunately it does.
it was actually really easy to resolve for my one project.
here is what i did.
you can solve this any of the following ways:
statically link to the dll files so they are compiled into my executable instead of referenced as separate dll files.
included the dll in the same directory as the exe (i actually didn’t try this but i assume it would work).
forced everyone to install the vc++ runtime redistributable before running the app.
the first option seems the most stable and robust and easiest for a single executable. so that is the one i am going to use.
the second option doesn’t really make sense to me and i would probably never do it. maybe if i had dozens of executable files that all required the same dll and i didn’t have an installer, and i wanted to conserve size, which probably wouldn’t happen for me since i am pretty good at creating a quick installer. though you might be in this a situation.
the third option would make sense if i was planning on running my executable after an install. during the install i could include the vc++ runtime redistributable and all would be fine.
make sure you resolve it for both release and debug. the steps are slightly different.
in visual studio, i went to the project properties.
i changed my configuration to release.
i went under configuration properties | c/c++ | code generation
look at the runtime library setting. it is set to this: multi-threaded dll (/md)
change it to this: multi-threaded (/mt)
rebuild.
almost exactly the same as release.
i changed my configuration to debug.
look at the runtime library setting. it is set to this: multi-threaded debug dll (/mdd)
change it to this: multi-threaded debug (/mtd)
rebuild the debug
it might be a good idea for me to figure out how to change the project so when i create a new project of this type, those settings are the default.