Answered by:

VC++ 2005 redistributable

Question

I'm trying to get an MFC application compiled with VC++ 2005 to run on a machine with VC++ 2005 express. There seems to be a problem with the manifest (which I don't fully understand despite reading the info on msdn). The original error in the event log when I tried to run it said Microsoft.VC80.CRT not installed so I installed the platform SDK and also copied over the atlmfc directory from the development to target machine.

I also downloaded the VC++ 2005 redistributable and installed it. When I installed it, I didn't get any confirmation that the installation was successful, the installer appears to quit after displaying the progress bar. Is this the correct behaviour?

Now I no longer get any messages in the event log but when I try to run the app I get an "Unable to start program ... This application has failed to start because the application configuration is incorrect..."

This error occurs both inside Visual Studio and when I run the app directly. I've tried both the debug and release builds (I understand the redist doesn't include the debug libs).

Answers

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

it's possible that some of your compiled binary file manifests have listed BOTH the old and the new versions of the CRT. Open up each compiled binary (i.e. EXE, DLL, OCX, etc) in a resource editor and look at the manifest. There should be no references to 8.0.50608.0.

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:

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...

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

I thought Manifests were an end to DLL hell - but it just seems that now we have manifest hell. The CRT seems to change rapidly so there are new VCREDIST_x86 releases for each change - but where are the corresponding merge modules? The only merge modules I can find for CRT Version 8 are for old builds - is it the case that developers should ship VCREDIST_X86 as the preferred method of redistribution or are merge modules preferrable? From an installation (end user) point of view including merge modules is cleaner and adding new versions of the CRT to a target system shouldn't break any existing applications (providing they are strongly bound to the cache DLLs on which they depend). So why no merge modules for each corresponding VCREDIST_X86 et al?

Or should all deployments use private side by side installs of the CRT/MFC dependancies (sigh)?

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.

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

I like to kindly remind you that the SP1 does not install/upgrade a vcredist_*.exe for C++ Express Edition. My posting regarding this issue is not answered in the Express Forum. Microsoft should place an upgraded vcredist.exe on their websites, otherwise many express users will have to work with private assemblies.

And actually, the Microsoft documentation recommends that VCRedist be used for deployment of applications built with Visual C++ Express. That's ridiculous if the VCRedist binaries are not installed with SP1 and there are no plans on making an SP1 VCRedist available!

I have very similar symptoms to 3d_developer but I don't have old manifest files hanging around. Again this is all on the development machine. I have vc++ express with sp1 installed. I may have installed sp1 beta a while ago. All the dlls I build depend on msvcr80.dll and dwmapi.dll and do not load because they cannot be found.

Any ideas as to how I can find out what is wrong? I have tried rebuilding everything from scratch.

How can I uninstall sp1? Do I need to uninstall everything and start again?

But my experience is that SP1 does NOT install a vcredist_x86.exe in bootstrapper/packages, and neither does it install any pdb for MSVCR80D.DLL.Many others have reported in this forum that they, too, did not get any vcredist_x86.exe with SP1.

So, what's the story? and how do we get the missing redistributable package?Do we have incomplete installations of SP1?

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.

I have an MFC app that I want to run (not build) on a machine with VC++ express. When the redistributable didn't work, I tried copying parts of the full VC++ installation to the target machine but that was just to debug the problem, I don't need to be able to build the app on that machine.

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:

To summarize: for Visual C++ 2005 Express Edition users who have installed SP1, the choices are:

Change all the projects in your solution to use the static runtime libraries(/MT). If your solution contains many .dll's this can greatly increase the size of your installed application.

Change all the projects in your solution to define the symbol _USE_RTM_VERSION and point users to the (original version) Microsoft download: Microsoft Visual C++ 2005 Redistributable Package (x86). This causes your application to forgo any fixes in the more recent library versions, which may be a problem if future versions include security fixes.

Use Wix to build your own .msi installer from the merge modules in \Program Files\Common Files\Merge Modules per the instructions in Mr. Shah's CodeProject blog: Bootstrapper for the VC++ 2005 Redists (with MSI 3.1). If you have a code-signing certificate, you can sign this installer yourself - otherwise you will need to convince your users to install an unsigned package with administrator privileges.

Install the necessary runtime libraries and manifests as a private assembly along with your application. This is also described in Mr. Shah's blog entry. Unfortunately, the directory for the runtime libraries differs depending on the user's version of Windows.

Have I missed anything?

None of these are particularly good choices, especially for large open-source projects. In practice, it might be better for Express users notto install SP1, so the original Microsoft Redistributable Package remains the only prerequisite for the application.

I have to agree, this is not a big improvement over DLL-hell for Express users. A Microsoft-signed SP1 Redistributable Package would ease the pain considerably.

Excellent post TomD2 - one thing I should mention about the _USE_RTM_VERSION symbol: it doesn't forgo any fixes if you have installed a more recent version of the runtime libraries to WinSxS. It only allows your app to run with the originals if those are the only ones installed. As soon as the new ones are installed (e.g. the SP1 ones), your app starts using the new ones (even though you've defined _USE_RTM_VERSION)

It isn't clear how the application users are supposed to do this, in light of Nikola Dudar's comment: "We have no plans of posting SP1 version of VCRedist for download. You should be using version of vcredist_*.exe installed by VS2005 SP1."

Of course there isn't any SP1 vcredist_*.exe available to the application users, or even to the original developer if Express Edition was used..

Perhaps Microsoft will reconsider this policy if a security fix gets included in a future version of the VC runtime libraries.

It isn't clear how the application users are supposed to do this, in light of Nikola Dudar's comment: "We have no plans of posting SP1 version of VCRedist for download. You should be using version of vcredist_*.exe installed by VS2005 SP1."

Of course there isn't any SP1 vcredist_*.exe available to the application users, or even to the original developer if Express Edition was used..

Perhaps Microsoft will reconsider this policy if a security fix gets included in a future version of the VC runtime libraries.

-tom-

As far as I know they are security issues addressed in SP1, at least in the IDE. I don't know about the libraries--obviously there are changes. The security issue is still a problem, if an EE user was relying on vcredist before they can't upgrade the IDE to SP1 and are then open to security issues.

hi TomD2, I think the best for VC++ Express users is solution #3, since they're going to need some sort of installer for their apps anyway, most modern installers support merge modules, if not just use WiX and create your own wrapper installer. As for the redist, I have heard they are looking into it again (no promises though)

I considered option 3 carefully. It certainly is the most practical for initial installation, but since Express developers don't have runtime library source; we would be just blindly redistributing updated Microsoft software in unsigned (or signed by the developer) .msi installers. This probably wouldn't be the most comfortable solution for application users over time - even if it works OK for the initial installation.

Since Express doesn't include any provision for building .msi installers, I think .zip files will be more common that InstallShield or Wix installers for the foreseeable future among VS-Express-developed apps. As time goes by and vulnerabilities happen, users will expect libraries in WinSxS to be updated by Windows Update. The app developers will only be expected (and only be able) to deal with vulnerabilities in the code they can examine and change.

Do you know if Windows Update is expected to patch or update CRT libraries if (...when...) there are security issues in the future?

I have been on vacation and I am sorry for a delay in reply. Thank you for all your comments and workarounds. I would like to add some comments on my part in this reply.

- As Ted.has pointed out VS2005 SP1 package should be updating redistributable MSMs in all versions of VS and vcredist*.exe in Std, Pro and VSTS. If you see MSMs or vcredist*.exe not updated, either SP1 install has failed or you have found a bug in SP1 install. In both cases you need to report it to SP team on the Connect site, http://connect.microsoft.com/visualstudio/

- However, _USE_RTM_VERSION is not exactly what is described by Ted. and TomD2. It merely makes application manifest reference VS2005 RTM version of Visual C++ libraries. Your code still links against SP1 version of VC++ headers and import libraries. The application is going to load any version of VC++ libraries installed on the machine as long as they are RTM or newer. When #define is not used, an application built with SP1 is going to only load with SP1 or newer versions of VC++ libraries. Use of this #define should not be treated as a workaround to new version of VC++ libraries released in SP1. Same as in any previous release of Visual Studio before VS2005, applications should always redistribute the version of VC++ libraries they were built with on the developer's machine. If they were built with SP1 version of VC++ libraries, they should be redistributing SP1 versions of the libraries. Also it does not quite work for DLLs, only for EXE. This is a bug that has been reported recently and we are investigating what has caused this regression. Only advanced users who well understand setup of their applications may consider using it in some specific scenarios. Only regourse testing of the application may ensure that application works sufficiently well on both RTM and SP1 versions of VC++ libraries. Unless you had done deep testing of your application and you were well aware of your application’s behavior on pre-SP1 versions of VC++ libraries, I would re-consider using this switch.

- Yes, I agree with other posters that the situation with MSMs in VCExpress is quite unfortunate. I have had a long discussion about that before VS2005 shipped, however it was decided not to change layout of VCExpress. Primarily because it has size limit common to all VCExpress versions of VS; it was also an expensive change and resources were busy with other tasks. Same time I had created and posted a WiX workaround for VCExpress users (http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx) and I worked with VS release team on creating a web download of VCRedist.

In Orcas, the release team is reviewing a list of components in VC Express and re-defining what is in there. I argue for including vc\redist folder that enables xcopy deployment of applications built with VCExpress on other computers. There are voices in support of adding vcredist*.exe into VC Express install. However in both cases MSMs have to go because users of VCExpress have troubles building MSIs out of MSMs. Enabling them to redistribute libraries in applocal seems like the most efficient solution to me because they only redistribute what an application is using. The counter argument is that VC Express has to have a solution as simple as possible because users of VCExpress are hobbyist and students. I tend to agree with that also, however size restriction set of Express versions of VS may not allow us to add vcredist to VC Express. Close to Beta1 release of Orcas, VC release team is going to narrow down the final solution, which either they going to mention on vcblog or I am going to mention on my blog.

- As for a download of the version of VCRedist shipped in VS2005 SP1, there is a task on VC release team's schedule to add another download of SP1 version of VCRedist. It was not quite technically easy to build a downloadable version of VCRedist before SP1 is completely closed and shipped. Downloadable version of VCRedist has to start from the final SP1 version of VCRedist. Next there is a time consuming web-release process for preparing an official downloadable package with EULA localized in all supported languages, signed, etc. Release team is making progress on this process, however I am not aware of details this time this because I am not driving it this time and focusing on Orcas features. As soon as some details are available, it is going to be announced on vcblog and I am going to post a link from my blog.

...there is a task on VC release team's schedule to add another download of SP1 version of VCRedist. It was not quite technically easy to build a downloadable version of VCRedist before SP1 is completely closed and shipped.

I'm not sure I follow, if the SP1 install updated the RTM version of vcredist_x86.exe, what has to be built in order to provide a vcredist_x86.exe on download.microsoft.com? I'm assuming the RTM vcredist_x86.exe that is installed with Visual C++ 2005 is the same as the RTM vcredist_x86.exe currently available on download.microsoft.com.

This is one of them. It sounds simple, but it is time consuming if you consider that EULA is localized in several languages and that opening package resets deployment testing. But it is being worked on and it is coming.

I've read this thread with interest but I'm still not certain why I can't redistribute my app. I'm using MSVC 2005 pro with SP1 installed. To deploy on a machine without msdev I run vcredist_86.exe and copy across the relevant processor-specific files to the root of the folder with my exe (ie. c:\exe_folder\Microsoft.VC80.CRT, etc.)

Problem is; the release version of my exe runs, and the debug version doesn't. I need to run the debug version for internal testing. When I run the debug version I get the dreaded "The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem" error.

I didn't have any problems before installing SP1.

I've read that vcredist may fail silently and that it only installs release dlls.

I've read this thread with interest but I'm still not certain why I can't redistribute my app. I'm using MSVC 2005 pro with SP1 installed. To deploy on a machine without msdev I run vcredist_86.exe and copy across the relevant processor-specific files to the root of the folder with my exe (ie. c:\exe_folder\Microsoft.VC80.CRT, etc.)

Problem is; the release version of my exe runs, and the debug version doesn't. I need to run the debug version for internal testing. When I run the debug version I get the dreaded "The application has failed to start because the application configuration is incorrect. Reinstalling the application may fix the problem" error.

I didn't have any problems before installing SP1.

I've read that vcredist may fail silently and that it only installs release dlls.

Thanks in advance for any help ;)

As far as I know VCRedist for VC2005 SP1 has not been release yet; so, you can't redistribute VC Express SP1 applications properly.

I'm not using VC Express, I'm using VC Pro. I've had a look at the event viewer at the debug app that failed to run and I find the error "Syntax error in manifest or policy file "C:\testapp\Microsoft.VC80.DebugCRT\Microsoft.VC80.DebugCRT.manifest" on line 4. This is odd, as I got it from the MSVC vcredist folder.

No I'm not using a 64 bit app, but I'm not sure that would be a problem as before installing SP1 the debug app worked on all machines (this was when we didn't have to copy processor-specific dlls to the target - the same dlls worked on every target machine regardless of processor). A32 bit app should work on 64 bit machines anyway.

This seems very odd to me - I am following msdn's advice and installing private side-by-side assemblies to the target so it should be working. I am thinking of trying Visual C++ Redistributable Merge Modules to install a particular Visual C++ library as shared side-by-side assemblies into the native assembly cache (WinSxS folder) but would rather not do this as I read it may interfere with other apps on the target machines. My app is a bit of a mare, btw, lots of 3rd party libs and dlls - I am wondering if one of these is relying on older dlls ...

it's possible that some of your compiled binary file manifests have listed BOTH the old and the new versions of the CRT. Open up each compiled binary (i.e. EXE, DLL, OCX, etc) in a resource editor and look at the manifest. There should be no references to 8.0.50608.0.

Found that some of the dlls were using the older versions of the CRT so made sure they are all using the most recent version version. Still doesn't work in debug. As I said, it all worked fine prior to service pack 1 - do I really have to go back to the previous version to get everything working again?

I just installed C++ Express with SP1 and Vista update onto my Vista PC. I take a look in the bootstrapper/packages DIR and still no "vcredist*.exe". Did anyone ever find this file in the Visual C++ Express SP1 install?

Including these merge files, but not the correct redistributable .exe (or better yet - a microsoft.com/download package) is a curious decision, since the Express edition excludes the tools to use msm's or to create msi's.

you're just gonna have to trust me when I say the VC2005 CRT SP1 works well under Vista and is fully supported (I have many, many users on Vista already using shipping commercial software that I'm involved with that makes use of VC2005 CRT SP1 )

I'm not sure why it was omitted from their release notes.

There must be some other reason why your manifest is not being generated properly. Try creating a brand new project and copy your source files into it.

you're just gonna have to trust me when I say the VC2005 CRT SP1 works well under Vista and is fully supported (I have many, many users on Vista already using shipping commercial software that I'm involved with that makes use of VC2005 CRT SP1 )

I'm not sure why it was omitted from their release notes.

There must be some other reason why your manifest is not being generated properly. Try creating a brand new project and copy your source files into it.

Are those built on an XP system or Vista system?

The manifest is generated at build time so I am not sure what a new project would do for me.

All builds are done on an XP system, and target all operating systems Windows 2000 and greater.

Even though they are generated at build time, the project configuration itself in your current project may be flawed in some way, so try using a simple wizard generated project and then see if what it builds still runs under Vista. Then that will at least narrow down the problem to being a project configuration problem.