none
VC++ 2005 redistributable

    Question

  • Hi,


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


    Any help appreciated.

    Jay.
    Tuesday, December 19, 2006 2:39 PM

Answers

  • 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++

    Thursday, December 21, 2006 7:25 PM
  • 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.
    Wednesday, March 07, 2007 12:45 PM

All replies

  • Express does not include MFC/ATL.  What "VC++ 2005 redistributable" did you install?  An Express redistributable won't have MFC/ATL...
    Tuesday, December 19, 2006 3:51 PM
    Moderator
  • 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

    From the description: " This package installs runtime components of C Runtime (CRT), Standard C++, ATL, MFC, OpenMP and MSDIA libraries."

    I also copied the mfc directory from a machine with VS 2005 professional so that I could try to recompile on the VS express machine. That didn't work either.

    Jay.

    Wednesday, December 20, 2006 1:28 PM
  • 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"
    Wednesday, December 20, 2006 2:54 PM
  • Your original message only mentioned running the application on the machine with Express installed.  Now you're saying you're trying to compile it with Express?  Express does not support MFC or ATL.
    Wednesday, December 20, 2006 4:16 PM
    Moderator
  • 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

    Wednesday, December 20, 2006 7:58 PM
  • 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++

    Thursday, December 21, 2006 7:25 PM
  • 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)?

    Thursday, December 21, 2006 8:01 PM
  • 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.

    Friday, December 22, 2006 3:49 PM
  • >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.

    Olaf
    Friday, December 22, 2006 8:08 PM
  • 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!
    Friday, December 22, 2006 9:27 PM
    Moderator
  • I've installed visual studio express 2005 SP1 and now some DLLs I build can't be loaded because of a msvcr80.dll dependency. DWMAPI.dll is also listed as missing as 3d_developer noted.

    I might also have installed this earlier:

    Visual C++ 2005 Express Service Pack 1 Beta

    could this be causing these problems?

    Please note this is all on my developer machine. I have not even tried installing this stuff on others' machines.

    Any ideas on how I can go about tracking this problem down. What more info might be relevant?

    Merry xmas!
    John.
    Friday, December 22, 2006 11:28 PM
  • Agreed, the SP1 vcredist files should be made available for download.
    Saturday, December 23, 2006 12:43 AM
  • 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?

    Thanks,
    John.
    Saturday, December 23, 2006 2:36 PM
  • Above, Nikola Dudar - MSFT wrote: "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."

    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? 

    Monday, January 01, 2007 2:51 AM
  • The new SP1 vcredist_x86.exe did install properly on my machine (Visual Studio 2005 Standard, Professional, and Team editions) in

    \Program Files\Microsoft Visual Studio 8\SDK\v2.0\BootStrapper\Packages\vcredist_x86

    Express doesn't include vcredist_x86.exe at all (RTM nor SP1)

    Monday, January 01, 2007 8:49 PM
  • I copied over the directories from the full VC++ 2005 installation (just as an experiment). It did actually compile ok but still doesn't run.

    Jay.

     

     

    Wednesday, January 03, 2007 5:10 PM
  •  Nikola Dudar - MSFT wrote:

    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.  

    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.

    Jay.

     

    Wednesday, January 03, 2007 5:30 PM
  •  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.

     

    Wednesday, January 03, 2007 5:38 PM
  • if your program is an EXE (no DLLs) then just define _USE_RTM_VERSION near the top of your stdafx.h

    see: http://msdn2.microsoft.com/en-us/library/aa983356(VS.80).aspx

    then you can use the original redistributable instead of waiting for a new SP1 one.

    Wednesday, January 03, 2007 10:07 PM
  • To summarize: for Visual C++ 2005 Express Edition users who have installed SP1, the choices are:

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

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

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

    4. 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 not to 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.

    -tom-
    Wednesday, January 10, 2007 3:19 AM
  • 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)
    Wednesday, January 10, 2007 3:25 PM
  • Thanks for the kind words, Ted.

    re: " As soon as the new ones are installed (e.g. the SP1 ones) "

    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-
    Wednesday, January 10, 2007 5:06 PM
  •  TomD2 wrote:
    Thanks for the kind words, Ted.

    re: " As soon as the new ones are installed (e.g. the SP1 ones) "

    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.
    Wednesday, January 10, 2007 5:52 PM
    Moderator
  • 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)
    Wednesday, January 10, 2007 7:34 PM
  • Hi Ted,

    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 decided the safest course is to uninstall SP1 for now, point users to the existing Microsoft Visual C++ 2005 Redistributable Package (x86) as a prerequisite, and watch which direction Microsoft decides to go with this.

    I certainly appreciate all the posts in this thread. They shed much light on this issue.

    -tom-


    Thursday, January 11, 2007 1:52 AM
  • Hello everyone,

    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.

    Thanks again for comments and suggestions!

    Nikola

    Friday, January 12, 2007 9:12 PM
  • Thanks for the follow-up Nikola

     Nikola Dudar - MSFT wrote:

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

    Friday, January 12, 2007 10:27 PM
    Moderator
  • One of them displays a license agreement, the other doesn't.
    Saturday, January 13, 2007 12:10 AM
  •  Ted. wrote:
    One of them displays a license agreement, the other doesn't.

    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.

    Nikola

    Tuesday, January 16, 2007 3:44 AM
  • Hi,

    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 ;)

    Tuesday, March 06, 2007 12:25 PM
  •  MikeMannion wrote:

    Hi,

    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.
    Tuesday, March 06, 2007 3:38 PM
    Moderator
  • As mentioned earlier in the thread, a Visual C++ 2005 SP1 Express user can use the merge modules that are found in:

    C:\Program Files\common files\merge modules

    to create a small self-extracting executable that is almost identical to the vcredist_x86.exe. 

    It's obviously not the easiest solution for a beginner, but it can be done (e.g. with WiX using the instructions found here: http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx )

     

     

     

    Tuesday, March 06, 2007 4:23 PM
  • 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.

    I've installed the latest redist package on the target machine http://www.apachelounge.com/download/vcredist_x86-sp1.exe

    As I've said the release version works fine, the debug doesn't.

    The target machine spec:

    win xp professional x64 edition
    version 2003
    service pack 1
    amdathlon 64 x2 dual core

     

    The manifest file looks like this:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <noInheritable></noInheritable>
        <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="amd64" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        <file name="msvcr80d.dll" hash="716999a1ab5ec3644e7b1d28b01bec7ef751f99f" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>8VY16Sxpd7AWi1N9a0wwZsUQKOM=</dsig:DigestValue></asmv2:hash></file>
        <file name="msvcp80d.dll" hash="afb1a4e71fd0bf5b3269730c372539c97db2ad92" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>01QJX0ayJEpIbyTOm1pbVYTvUYU=</dsig:DigestValue></asmv2:hash></file>
        <file name="msvcm80d.dll" hash="3bd015ada336dad63727bf56c344353347db3412" hashalg="SHA1"><asmv2:hash xmlns:asmv2="urn:schemas-microsoft-com:asm.v2" xmlns:dsig="http://www.w3.org/2000/09/xmldsig#"><dsig:Transforms><dsig:Transform Algorithm="urn:schemas-microsoft-com:HashTransforms.Identity"></dsig:Transform></dsig:Transforms><dsig:DigestMethod Algorithm="http://www.w3.org/2000/09/xmldsig#sha1"></dsig:DigestMethod><dsig:DigestValue>D6rvKs9Y4txKIKHvmlDcr96fwsk=</dsig:DigestValue></asmv2:hash></file>
    </assembly>

    Tuesday, March 06, 2007 4:39 PM
  • you're using AMD64 version of the manifest. your app is 64 bit?  (I know you mentioned the target machine is x64, but what about your binaries, are they compiled with x64?)

    Also the RTM versions of those manifests were a lot cleaner.  I don't know if it makes any difference but try:

    <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
    <assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
        <noInheritable></noInheritable>
        <assemblyIdentity type="win32" name="Microsoft.VC80.DebugCRT" version="8.0.50727.762" processorArchitecture="x86" publicKeyToken="1fc8b3b9a1e18e3b"></assemblyIdentity>
        <file name="msvcr80d.dll"/>
        <file name="msvcp80d.dll"/>
        <file name="msvcm80d.dll"/>
    </assembly>

     

    Tuesday, March 06, 2007 4:48 PM
  • 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 ...

    Ted: Tried the manifest you suggested but alas no luck ;(

    Thanks for all your continuing help ;)

    Wednesday, March 07, 2007 12:08 PM
  • 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.
    Wednesday, March 07, 2007 12:45 PM
  • 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?

    Thanks for your help ;-)

    Friday, March 09, 2007 10:46 AM
  • working now - there was a dll using an older version of the crt dll that I'd overlooked

    thanks a lot for your help, Ted ;)

    Thursday, March 15, 2007 5:10 PM
  • I may be beating a dead issue here, but......

    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?

     

    Chris

    Monday, April 02, 2007 3:44 AM
  • No, it has not been released yet as a downloadable redistributable.  It is supposed to be in progress right now for release some time soon. 

     

    Right now if you need it, It is only part of Standard edition or higher.

    Monday, April 02, 2007 2:16 PM
  • A downloadable redistributable for Express SP1 was "...being worked on and it is coming..."  back in mid-January, but apparently it has proved to be a really tough job!   No sign of it yet.

     

    It is possible to build an install kit from the .msm "merge" files which are included with Express using non-Microsoft tools.  See http://blogs.msdn.com/nikolad/archive/2005/09/02/460368.aspx

     

    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.

     

    -tom-

    Thursday, May 17, 2007 11:08 PM
  • Will the SP1 redistributable allow an app to run on Vista that was built on an XP system?
    Thursday, May 31, 2007 3:21 AM
  •  Douglas Jordan wrote:
    Will the SP1 redistributable allow an app to run on Vista that was built on an XP system?
    I was under the impression you need the Service Pack 1 Update for Windows Vista.
    Thursday, May 31, 2007 3:10 PM
    Moderator
  •  Peter Ritchie wrote:
    I was under the impression you need the Service Pack 1 Update for Windows Vista.

    No that Vista update is for the VC++ IDE itself, not for an app to run under Vista.

    Thursday, May 31, 2007 5:16 PM
  • The SP1 update did not allow my app to run on Vista.  The same msvc80 error occurs.

    I had my doubts since the download page did not state Vista was supported.

    Monday, June 04, 2007 12:05 PM
  • douglas, I suspect your app is a "debug" version rather than "release" version. Build a "release" version and try again.
    Monday, June 04, 2007 5:29 PM
  •  Ted. wrote:
    douglas, I suspect your app is a "debug" version rather than "release" version. Build a "release" version and try again.

     

    No not a newbie here, it is built for release.  I checked the resources and is does not have the debug version of the CRT in the embedded manifest - Microsoft.VC80.CRT" version="8.0.50727.762

     

    Besides the SP1 download does not state it supports Vista, is there a reason for that?

    Monday, June 04, 2007 5:49 PM
  • 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.

    Monday, June 04, 2007 6:31 PM
  •  Ted. wrote:

    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.

    Monday, June 04, 2007 6:46 PM
  • Are those built on an XP system or Vista system?

    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.

    Monday, June 04, 2007 7:44 PM
  • I found the problem - the Allow Isolation linker option was disabled.  Not sure why it was working in XP.  Now working on Vista with the SP1 DLL pack.
    Tuesday, June 19, 2007 2:39 AM
  • good to know that, Douglas, thanks.
    Tuesday, June 19, 2007 7:04 PM