Hi,

The redist is called "Microsoft Visual C++ 2005 Redistributable Package (x86)" available at

 http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=32BC1BEE-A3F9-4C13-9C99-220B62A191EE

Hi Jonas,

Could you please provide more details on the issue you hit with versions of C Runtimes?  We're seeing a rash of issues with our executables being unable to find C Runtime DLLs (MSVCR80.DLL being the most common one) on some XP SP2 machines and haven't found a solution yet.  The executables and most dlls are native C++ with one mixed-mode C++ dll and one C# dll.  The C++ code uses MFC and the C# dll uses WPF and COM interop, etc.

We also see the DWMAPI.DLL missing issue when we run dependes, but other forum threads indicate that's a false missing dependency.

We are embedding manifests in our executables and the manifests are correct, the Windows\WinSxS folder seems to contain the correct versions of the C Runtime DLLs (8.0.50727.42 and 8.0.50727.163), etc.  We do install the .NET 3.0 redistributable on machines as part of the install.  And on the machine where the executable is built, everything runs fine.  So I'm hoping you might have some information that would help us solve this problem.

For example, if the Visual Studio 2005 Extensions for WPF install something special on machines that they don't get from the normal VC redistributable, that would explain it.  I haven't tried that yet...

Thanks -Bob

Jonas Nordlund wrote:

Note that the redistributable above may not run applications compiled in Visual Studio 2005 Service Pack 1 as such executables want slightly revised versions of the runtime DLL's. It took us some while here to figure that out and thought it wasn't well documented. I'm unsure if a redistributable for that version is available online yet, but it's shipped with Visual Studio 2005 SP1 at: "%PROGRAMFILES%\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86"

Thanks Jonas, that looks promising. I was using the redist from the website but I have SP1 on my development machine so I'll try the updated version.

Jay.

It looks like there are several issues mixed up in this thread.

Jay K wrote:

I'm trying to get an MFC application compiled with VC++ 2005 to run on a machine with VC++ 2005 express.

Jay, is there a reason you are trying to do this? As Peter has already pointed out,  you cannot build MFC applications with VC++2005 Express, not matter you install or you do not install VC++ Redistributable Package.

Jay K wrote:

I've tried both the debug and release builds (I understand the redist doesn't include the debug libs).

You can only redistribute release version of VC++ libraries. Once you have built a release version of your MFC application, you can run it on a computer that does not have VS2005 installed after you have deployed MFC and CRT DLLs using ways described here, http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx

Jonas Nordlund wrote:

Note that the redistributable above may not run applications compiled in Visual Studio 2005 Service Pack 1 as such executables want slightly revised versions of the runtime DLL's. It took us some while here to figure that out and thought it wasn't well documented. I'm unsure if a redistributable for that version is available online yet, but it's shipped with Visual Studio 2005 SP1 at: "%PROGRAMFILES%\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86"

This is correct. VS2005 SP1 installs new versions of VC++ libraries that contain fixes requested by customers for the SP1 release. Once Sp1 is installed it updates all VC++ assemblies in WinSxS folder, vcredist_*.exe in bootstrapp packages folder, associated .lib and .pdb for VC++ libraries and many other source files. Once application is rebuilt with VS2005 SP1, it depends on SP1 version of libraries and SP1 version of VC++ libraries have to be redistributed. This is not new policy for VS2005. In all previous versions of Visual Studio and Visual C++, QFE and SP releases of DLLs replace previous versions of DLLs in place. VC maintains full backward binary-compatibility in hotfix and SP releases of VC++ DLLs if compared to RTM versions. Once an application is rebuilt with SP or a hotfix version of VC++ libraries, it depends on that version of libraries and have to use them at runtime. This is also described in docs, http://msdn2.microsoft.com/en-us/library/aa983349(VS.80).aspx

We have no plans of posting SP1 version of VCRedist for download. You should be using version of vcredist_*.exe installed by VS2005 SP1.

3d_developer wrote:

We're seeing a rash of issues with our executables being unable to find C Runtime DLLs (MSVCR80.DLL being the most common one) on some XP SP2 machines and haven't found a solution yet.  ... We are embedding manifests in our executables and the manifests are correct, the Windows\WinSxS folder seems to contain the correct versions of the C Runtime DLLs (8.0.50727.42 and 8.0.50727.163), etc.

Bob, I think you have a different issue. Perhaps start another discussion on this. Please be specific in description of your build environment and mention what versions of VS2005 you have installed. Identify specifically what VC++ libraries your application depends on, what versions of them, etcs. Make sure your application installs the same versions of the libraries on another computer by using VC++ redistributable MSMs or VC++ Redistributable Package,  http://msdn2.microsoft.com/en-us/library/ms235316(VS.80).aspx. You may find more information about how troubleshoot loading issues here, http://msdn2.microsoft.com/en-us/library/ms235342(VS.80).aspx

Nikola

VC++

Thanks Nikola.  I'm embarrassed to say that my problem turned out to be old application manifest files were sometimes being left in the same install folder as the executable, causing the embedded manifest to be ignored.  Once we fixed our install to remove the old manifest files, everything works great.

But I do agree with another poster that it would be great if Microsoft had a clear set of web pages explaining manifest files and with links to all the various versions of the C runtime listed explaining what changed for each and merge modules / developer installs for each available.  For example, I have versions 8.0.50727.163 and 8.0.50727.42 on one of my machines, but only version 8.0.50727.42 on most others.  I have no clue what install installed 8.0.50727.163 and nothing on Microsoft's web site has told me yet.  Additionally, I found that SQL Server 2005 installed its own copy of MSVC80 DLLs in their install folders, not in the WinSxS folders, which caused additional confusion as on those machines some of the DLLs were found.