This is an old revision of the document!
Summary: Discusses the distribution of Microsoft Visual C++ 2005 runtimes for C++ plugins
Updated: June 17, 2011
The Microsoft Visual C++ 2005 Redistributable Packages install runtime components of Visual C++ Libraries required to run C++ plugins developed with Visual C++ on a computer that does not have Visual C++ 2005 installed.
These packages install runtime components of C Runtime (CRT), Standard C++, ATL, MFC, OpenMP and MSDIA libraries. For libraries that support side-by-side deployment models (CRT, SCL, ATL, MFC, OpenMP) they are installed into the native assembly cache, also called WinSxS folder, on versions of Windows operating system that support side-by-side assemblies.
Any Rhino plugin that you build has dependencies on assemblies (DLLs). A Rhino C++ plugin, which is an MFC DLL, (in a release build) depends at least on the CRT (msvcr80.dll, msvcp80.dll) and MFC (mfc80.dll or mfc80u.dll) assemblies. You, the plugin developer, have these assemblies on your machine because you have Visual C++ 2005 installed. But a machine without Visual C++ 2005 may not have them. To be able to run your plugin on such machines, you have to redistribute these assemblies.
To redistribute the required assemblies, you need to know which version of the assemblies are required by your plugin. For example, plugins built with Visual C++ 2005 SP1 require a different version of the Microsoft Visual C++ 2005 Redistributable Package than a plugin built with a non-service packed version of Visual C++ 2005.
To know which Redistributable Package to include with your plugin installation, you need to know what is installed on the system that built your plugin. With the dozens of Microsoft Windows updates that have been available over the years, it can be a real a challenge to determine what version, service pack and security updates of Visual Studio 2005 you have installed.
One sure way to know what Redistributable Package your plugin requires is to examine your plugin's Manifest. A manifest is an XML document that can be an external XML file or a resource embedded inside an application or an assembly (plugin). The manifest of an isolated application is used to manage the names and versions of shared side-by-side assemblies to which the application should bind at run time. The manifest of a side-by-side assembly specifies its dependencies on names, versions, resources, and other assemblies.
One way to determine the required assemblies of your plugin is to use the Manifest Tool (MT.EXE) included with Visual C++ 2005. For example, from a Visual Studio command prompt, you can do the following:
C:\Plug-ins\cpp\PlugIn1\Release>mt -inputresource:plugin1.rhp;#2 -out:manifest.txt
Typically, EXEs have an embedded manifest in resource #1, while DLLs have the manifest in resource #2. If you do not find a manifest resource in #1, check #2. Here is the contents of “manifest.txt” created by MT.EXE.
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0"> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.CRT" version="8.0.50727.5592" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" /> </dependentAssembly> </dependency> <dependency> <dependentAssembly> <assemblyIdentity type="win32" name="Microsoft.VC80.MFC" version="8.0.50727.5592" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b" /> </dependentAssembly> </dependency> </assembly>
In this example, we can see that the required verison of CRT and MFC is 8.0.50727.5592. In this case, we need to include the Microsoft Visual C++ 2005 Service Pack 1 Redistributable Package MFC Security Update when distributing this plugin.
Besides the Manifest Tool (MT.EXE) included with Visual C++ 2005, there are other useful tools for helping determine required assemblies.
Dependency Walker, by Steve P. Miller, is a free utility that scans any 32-bit or 64-bit Windows module (EXE, DLL, RHP, etc.) and builds a hierarchical tree diagram of all dependent modules. Dependency Walker is very useful for troubleshooting system errors related to loading and executing modules.
Manifest View, by Kenny Kerr, is also a free utility for viewing an application's manifest. This tool is similar to the Manifest Tool but much easier to use.