KB2011022200: Redistribution of the shared C runtime component in Visual C++
There have been a couple of issues related to the CRT deployment with the GISInternals causing the application to fail to run properly, so you might have to keep a couple of things in mind when deploying your application on the target computer. Most of these issues are documented in the related MS articles so refer to these documents for the details.
1. Mixing dll-s compiled with different compilers/ CRT dependencies
This scenario is not supported by Microsoft and you should avoid this according to the following article: Potential Errors Passing CRT Objects Across DLL Boundaries
"When you pass C Run-time (CRT) objects such as file handles, locales, and environment variables into or out of a DLL (function calls across the DLL boundary), unexpected behavior can occur if the DLL, as well as the files calling into the DLL, use different copies of the CRT libraries.
A related problem can occur when you allocate memory (either explicitly with new or malloc, or implicitly with strdup, strstreambuf::str, and so on) and then pass a pointer across a DLL boundary to be freed. This can cause a memory access violation or heap corruption if the DLL and its users use different copies of the CRT libraries."
This issue not necessarily cause problems when each dll takes the responsibility to de-allocate the memory it has been allocated within the same dll or executable. However we cannot be certain about this for each dlls deployed along with the MapServer and GDAL binary packages, but we should keep this danger out of the door as the packages have been compiled the with the same compiler and CRT setting (/MD). Just make sure you won't mix the dll-s from different packages within your deployment.
2. Expected locations of the CRT redistributables
When you build an application in Microsoft Visual Studio, and the application uses the C run-time libraries (CRT), distribute the appropriate CRT DLL from the following list with your application:
- Msvcr100.dll/Msvcp100.dll for Microsoft Visual C++ 2010
- Msvcr90.dll/Msvcp90.dll for Microsoft Visual C++ 2008
- Msvcr80.dll/Msvcp80.dll for Microsoft Visual C++ 2005
- Msvcr71.dll/Msvcp71.dll for Microsoft Visual C++ .NET 2003 with the Microsoft .NET Framework 1.1
Microsoft Visual C++ 2005 Redistributable Package (x86)
Microsoft Visual C++ 2005 Redistributable Package (x64)
Microsoft Visual C++ 2008 Redistributable Package (x86)
Microsoft Visual C++ 2008 Redistributable Package (x64)
3. Application manifests
Upon establishing the option of the side-by-side assembly cache (as of Win2003 Server and Windows XP) the binaries (dll-s or executables) should declare their (CRT) dependencies in the application manifest file. Without this declaration the application is a candidate to have the following error: C Run-Time Error R6034.
"An application manifest is an XML file that describes and identifies the shared and private side-by-side assemblies that an application should bind to at run time. These should be the same assembly versions that were used to test the application. Application manifests may also describe metadata for files that are private to the application. Application manifests should be included as a resource in the application's EXE file or DLL." Fortunately the dlls and executables in the MapServer and GDAL binary packages contain these manifests embedded as a resource in the binary files (for MSVC2005/2008). This is not an issue with the packages build with MSVC2003 where the CRT implementation is located is the application directory (see #2 above) and not in the shared assembly cache.
Note: For some reason with Visual Studio 2010 Microsoft has reverted the behaviour to VS2003 and no manifests are generated by default. In these cases the CRT dll-s should be installed along with the applications.
4. Licensing issues
In general you should have a valid license for a "VC.NET 2003" product to be able to redistribute msvcr71.dll, please refer to the redist.txt file in your "Visual" product installation folder which files are allowed to be redistributed. This is not the case with the vcredist_ packages (for VS2005/2008) which are allowed to be installed on a per-user basis within the terms of the corresponding EULA.