You might be interested in this topic if you experienced the following problem:

  • developed your VC++ application with Visual Studio 2005, it worked ok on your computer and when you put it on another it does not run, or
  • your application run both on your machine and other machines (without VS 2005 installed), but after installing SV 2005 SP1 and rebuild, it no longer worked.

Let me start with the first: any application has dependencies on assemblies (DLLs). An MFC application (in a release build) depends at least on the CRT (msvcr80.dll, msvcp80.dll) and MFC (mfc80.dll or mfc80u.dll) assemblies. You have them on your machine because you have VS 2005 installed. But a machine without it, may not have them. In order to be able to run the application on such machines you have to redistribute them (notice you can only redistribute release builds of the assemblies).

Visual C++ 2005 supports a new deployment model for Windows client applications based on isolated applications and side-by-side assemblies. Basically, assemblies can be:

  • shared (they are globally registered in the system, installed in the Global Assembly Cache – GAC folder in Windows – and available to all applications) or
  • side-by-side, described with a manifest, distributed with the application and available only to that application

In Visual C++ 2005, library assemblies (such as MFC, ATL, CRT) have been rebuilt as shared side-by-side assemblies and installed in the native assembly cache, WinSxS folder in Windows. That means they are not globally registered in the system, but are globally available to the applications that specify a dependency with a manifest file.

By default, Visual C++ 2005 builds all native C/C++ applications as isolated applications; such an application is a self-describing one, that uses a manifest file to describe its dependencies. A manifest is an XML file that describes the application and its dependencies.

Such a manifest should have the same name as the application and the extension “manifest” and should specify the version number of your assembly (executable or dynamic library), processor architecture, name of the assembly and platform type; a description of your assembly is also recommended. And example is shown bellow:

< ?xml version='1.0' encoding='UTF-8' standalone='yes'?>
< assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
< assemblyIdentity
  version="1.0.0.0"
  processorArchitecture="X86"
  name="CompanyName.ProductName"
  type="win32"
 /> 

 < description>Description of your application.< /description>

You specify a dependency in the manifest file by adding a dependency element. If you want to specify the use of Win-XP styles for your controls, you need to add a dependency to Microsoft.Windows.Common-Controls:

< ?xml version='1.0' encoding='UTF-8' standalone='yes'?>
< assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
< assemblyIdentity
  version="1.0.0.0"
  processorArchitecture="X86"
  name="CompanyName.ProductName"
  type="win32"
 /> 

 < description>Description of your application.< /description>

< dependency>
  < dependentAssembly>
   < assemblyIdentity
    type="win32"
    name="Microsoft.Windows.Common-Controls"
    version="6.0.0.0"
    processorArchitecture="X86"
    publicKeyToken="6595b64144ccf1df"
    language="*"
   />
  < /dependentAssembly>
 < /dependency>

< /assembly>

Now, going back the to problem: in the first case you either install the Microsoft Visual C++ Redistributable Package on the target machine, so that the assemblies are made available to your application from the WinSxS folder, or you put them in the same folder with your application and use a manifest file to describe the dependencies.

However, you have to notice that if the DLLs are also present in the WinSxS folder, the system will prefer these DLLs to the ones in the same folder with the application. This is different from the folder deployment model, that appear with Windows 2000, when the system first checked the working folder of the application and after that the system folder (system32).

This is one of the causes of the second problems I mentioned above: you developed your application with VC++ 2005, deployed it as I explained above and it worked. But then, after installing VS 2005 SP1 and rebuilding and re-deploying the application no longer worked on the other machines. The root of the problem are the assemblies version: prior to SP1, the assemblies version was 8.0.50727.42. You deployed them on the target machine or had them installed with the redistributable package (downloadable from http://www.microsoft.com/downloads/details.aspx?familyid=32bc1bee-a3f9-4c13-9c99-220b62a191ee&displaylang=en). But after SP1 on your machine a new version was avaiable: 8.0.50727.762. Your new builds now depends on this version of assemblies (CRT, MFC). If you run your application in debugger, you’ll see that the DLLs from WinSxS are loaded:

'testapp.exe': Loaded
'C:WINDOWSWinSxSx86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_257740a4mfc80d.dll', Symbols loaded. 

'testapp.exe': Loaded
'C:WINDOWSWinSxSx86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9fmsvcr80d.dll', Symbols loaded.



The listing shows that MFC80D.dll was loaded from folder x86_Microsoft.VC80.DebugMFC_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_257740a4 in WinSxS and MSVCR80D.dll from x86_Microsoft.VC80.DebugCRT_1fc8b3b9a1e18e3b_8.0.50727.762_x-ww_5490cd9f. These are the debug builds for MFC and CRT. The behaviour is the same with the release ones. The name of the folder includes the platform (x86), the assembly name (Microsoft.VC80.DebugMFC, Microsoft.VC80.DebugCRT), the public token (1fc8b3b9a1e18e3b) and the version number (8.0.50727.762). On a machines with VS 2005 SP1 you have both versions 8.0.50727.42 and 8.0.50727.762, but when you redistribute it to one without the later, the application does not run, unless:

As I explained earlier, in case you have the required assemblies both in WinSxS and your application folder, the ones from WinSxS will be loaded. However, there is a workaround for that, as found by Andre Stille: removing the publicKeyToken attribute from the manifest files. For your application manifest that looked like this

< ?xml version='1.0' encoding='UTF-8' standalone='yes'?>
< assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
< assemblyIdentity  version="1.0.0.0"
  processorArchitecture="X86"
  name="CompanyName.ProductName"
  type="win32"
 />
< description>Description of your application.< /description>

< dependency>
    < dependentAssembly>
      < assemblyIdentity
       type='win32'
       name='Microsoft.VC80.CRT'
       version='8.0.50727.762'
       processorArchitecture='x86'
       publicKeyToken='1fc8b3b9a1e18e3b' />
    < /dependentAssembly>
  < /dependency>   

< /assembly>

you have to change it to:

< ?xml version='1.0' encoding='UTF-8' standalone='yes'?>
< assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
< assemblyIdentity  version="1.0.0.0"
  processorArchitecture="X86"
  name="CompanyName.ProductName"
  type="win32"
 />
< description>Description of your application.< /description>

< dependency>
    < dependentAssembly>
      < assemblyIdentity
       type='win32'
       name='Microsoft.VC80.CRT'
       version='8.0.50727.762'
       processorArchitecture='x86' />
    < /dependentAssembly>
  < /dependency>   

< /assembly>



Also, the change is necessary for the CRT manifest, that originally looked 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.CRT"
      version="8.0.50727.762"
      processorArchitecture="x86"
      publicKeyToken="1fc8b3b9a1e18e3b">
    < /assemblyIdentity>
    < file name="msvcr80.dll"
          hash="10f4cb2831f1e9288a73387a8734a8b604e5beaa"
          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>n9On8FItNsK/DmT8UQxu6jYDtWQ=
        < /dsig:DigestValue>
      < /asmv2:hash>
    < /file>
    < file name="msvcp80.dll"
          hash="b2082dfd3009365c5b287448dcb3b4e2158a6d26"
          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>0KJ/VTwP4OUHx98HlIW2AdW1kuY=
        < /dsig:DigestValue>
      < /asmv2:hash>
    < /file>
    < file name="msvcm80.dll"
          hash="542490d0fcf8615c46d0ca487033ccaeb3941f0b"
          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>YJuB+9Os2oxW4mY+2oC/r8lICZE=
        < /dsig:DigestValue>
      < /asmv2:hash>
    < /file>
< /assembly>



It should be modified to

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

   < file name="msvcr80.dll">< /file>
   < file name="msvcp80.dll">< /file>
   < file name="msvcm80.dll">< /file>
< /assembly>


Hits for this post: 30618 .
Trackback

15 comments untill now

  1. Gravatar

    Hi Marius,

    hope i spelled it correctly.

    I would like to have some guidance on this article.

    The version which i am getting is 8.0.50608.0,

    is it correct or something is wrong

  2. Gravatar

    You’re getting it by what? In WinSxS there is a folder called Policies. It contains XML files called for example 8.0.50727.42.policy and grouped by assembly categories (x86_policy.8.0.Microsoft.VC80.CRT_1fc8b3b9a1e18e3b_x-ww_77c24773, etc.) which could redirect the dependencie on 8.0.50608.0 to 8.0.50727.42. Please check it.

  3. Gravatar
    Vladimir @ 2007-09-14 22:25

    Hi,

    why Visual Studio generates me such manifest:

    There is no information about msvcr80d.dll at all ???

    Thank you.

  4. Gravatar

    And what manifest is that? If you want a quick answer to such problems I suggest asking in a dedicated forum (such as http://www.codeguru.com/forum).

  5. Gravatar

    Brilliant! This was exactly the problem I had been having, thank you for the explanation & fix.

  6. Gravatar
    Minh Nhá?­t @ 2008-06-23 22:29

    Hello! I have just read your article and I tryed to fix the problem. But I have no success. Can you guide me more details. I use Windows Vista OS. Thanks so much!

  7. Gravatar

    We are converting an embedded XP product from VS2005 SP1 where we were succesful xcopy deploying the redistributables to VS2008 SP1. When we try the same xcopy deployment of C:\Program Files\Microsoft Visual Studio 9.0\VC\redist\x86\Microsoft.VC90.CRT, none of our executables run.

    Depends.exe indicates that the CRT DLLs are being found but we still get “The system cannot execute the specified program”.

    Since this is an embedded system, we do not host an installer server so we cannot just run vcredist_x86.exe and install the CRT in \Windows\WinSxS.

    We can convert to /MT from /MD and use statically linked CRT, but this bloats us.

    We have tried all of the suggestions in this thread and others but none seem to work.

    Any help would be appreciated.

    Thanks.

  8. Gravatar

    I have opened case SRX081104601315 with Microsoft to investigate this since I can reproduce it it on a desktop.

  9. Gravatar

    It’s not enough to copy that manifest. You have to make sure that the version numbers of the DLLS in the manifest are the same with the version number of the DLLs your application depends on.

    Here are some links:
    http://connect.microsoft.com/VisualStudio/feedback/Workaround.aspx?FeedbackID=361682
    http://www.codeguru.com/cpp/v-s/devstudio_macros/visualstudionet/article.php/c15611/

  10. Gravatar

    The fix from Microsoft is:

    Add “_BIND_TO_CURRENT_VCLIBS_VERSION=1″ to the preprocessor of all /MD C++ projects (release and debug) per http://msdn.microsoft.com/en-us/library/cc664727.aspx

    This resolved the problem.

  11. Gravatar

    Hi!

    I’ve found this message to be very useful, though the information is not rather new.
    I’m your permanent reader now!

    p.s. BTW, what happened to your site template? Or is it just my browser? :)

    http://hubpages.com/hub/yoursamsungln46a650

  12. Gravatar
    mariusbancila @ 2008-12-16 14:30

    My template is just fine. Sometimes the loading takes longer, so perhaps that’s why you saw something wrong.

  13. Gravatar

    [...] Marius Bancila’s Blog ” Redistributable Assemblies, WinSxS … You might be interested in this topic if you experienced the following problem: … Add “_BIND_TO_CURRENT_VCLIBS_VERSION=1′′ to the preprocessor of all … [...]

  14. Gravatar

    thanks for a great article describing a dimly lit subject – Visual Studio should come with a disclaimer warning developers about this problem! There’s no immediate or obvious answer!

  15. Gravatar

    Awesome explanation…mystery of manifest files revealed…Good Job !

Add your comment now