Redistributable Assemblies, WinSxS and VisualStudio 2005

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:

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:

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

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

you have to change it to:

Also, the change is necessary for the CRT manifest, that originally looked like this:

It should be modified to

16 Replies to “Redistributable Assemblies, WinSxS and VisualStudio 2005”

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

    why Visual Studio generates me such manifest:

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

    Thank you.

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

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


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

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

  8. Bună ziua !
    Pe un Windows 7 am instalat Visual Studio 2005 Professional Edition. Când compilez codul sursă (program C++ simplu în consolă), la final îmi spune că nu a găsit nicio eroare dar nu face fişierul exe. Dacă puteţi să-mi spuneţi unde ar fi problema ?
    Vă mulţumesc !

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.