Sunday, February 21, 2010

Redistribution of the shared C runtime component in Visual C++

There have been a couple of issues related to the CRT deployment with the MapServer and GDAL binary packages 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
For Microsoft Visual C++ .NET 2003, you should install the CRT DLLs into your application program files directory. You should not install these files into the Windows system directories. For Msvcr80.dll and for Msvcr90.dll, you should install the CRT as Windows side-by-side assemblies." For more information see KB326922 and Redistributing Visual C++ Files. According to the suggestions above I've copied the msvcrt71 dll-s in the packages compiled with MSVC2003. With regards to the MSVC2005/2008 packages you should probably install the corresponding Visual C++ redistributable (vcredist_) package (or incorporate the msm module in your application installer). Make sure to install the package for your desired platform/architecture (x86 or x64)

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.

9 comments:

  1. Tamas,

    It's worth to add that it only applies to Release binaries and that Visual Studio/Visual C++ EULA forbids distributing Debug versions.

    ReplyDelete
  2. Mateusz,

    Did you refer to the Debug version of the CRT libraries or the Debug version of the development target? I don't see any specific restrictions when distributing "your" code. With regards to the Visual Studio components - in most cases - the files enumerated in redist.txt can be redistributed within the terms of the Visual Studio license agreement.

    ReplyDelete
  3. I mean Debug CRT. I rather don't discuss debug binaries that are not linked to Debug CRT as such debug binaries are fairly useless for debugging purposes.

    ReplyDelete
  4. redist.txt doesn't enumerate the debug versions of the CRT dll-s so these files are not redistributable indeed.
    If we don't require advanced CRT debug features (like tracking heap allocation requests) it's not necessary to link against the debug versions using /MD /Zi for the development target would also be sufficient to step into the code in the debugger. However, when using the debug CRT options (like /MDd) it would also be essential to compile all of the dependencies with the same CRT setting to avoid the potential problems described in #1. Having a large number of the libraries in the package (more than 30 in my case) it would be quite a challenging task to modify all the corresponding makefiles or solution/project files this way.

    ReplyDelete
  5. It's really nice blog Its helps you to find error and fix them please go through this site and make good solution of your problem.
    How To Remove Rundll Error
    Thanks
    Aalia lyon

    ReplyDelete
  6. Your post helped me in solving one of my university assignment. Thanks for sharing. C++ in Urdu

    ReplyDelete
  7. I also had problem with Microsoft Visual Studio Msvcr71.dll file on my laptop. You can easily solve. Just download missed .dll library file from http://fix4dll.com/msvcr71_dll and add in into the system32 folder.

    ReplyDelete
  8. Do you want to know about NBA 2K18 video game? This is the really great game with new design and technology. Click here

    ReplyDelete