Marius Bancila’s Blog

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:

• you provide the correct dependent assemblies in your application folder (assemblies with version 8.0.50727.762), or
• you install the Microsoft Visual C++ 2005 SP1 Redistributable Package (x86). That installs the new assemblies in WinSxS.

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>

Working correctly with the Windows Registry might prove a little difficult, especially for beginners. One thing one should care about for example is using the correct access rights (not just the default ones) when creating a registry key. To ease the burden of directly using the Win32 registry API, I decided to wrap them inside two classes and make them available for anyone that wants to use them.

The classes that I put together are:

• SecurityAttributesUtils: this is transparent for the developer, and is used to create the necessary access rights for creating a registry key;
• RegistryUtils: offers static functions for creating, deleting and closing a key, as well as reading and writing double words, strings and binary data to/from the registry;
• RegistryUtilsEx: a class based on RegistryUtils used for reading and writing strings and binary data, that uses STL’s std::string or std::wstring classes.

To create a key you should use RegistryUtils::CreateKey. It takes a handle to an open key (usually one of the predefined keys HKEY_CURRENT_USER, HKEY_LOCAL_MACHINE, etc. or an already opened key), the name of the subkey the function opens or creates and the desire access rights. It returns the handle to the opened or created key as the first argument, and a value indicating the success or failure.

HKEY hKey = NULL;
// create or open the key
RegistryUtils::RegResult OpenMode = RegistryUtils::CreateKey(HKEY_CURRENT_USER,
		_T("Software\Bancila\Test"),
		KEY_READ|KEY_WRITE,
		hKey);

To write a string use either RegistryUtils::WriteString or RegistryUtilsEx::WriteString string if you use STL std::string or std::wstring. It takes the handle to the key, the name of the value and the value to write.

RegistryUtilsEx::WriteString(hKey, _T("key1"), _T("value1"));

To read a string use either RegistryUtils::ReadString or RegistryUtilsEx::ReaderString, the later for working with STL’s strings.

tstring str;
// read a string
if(RegistryUtils::Success != RegistryUtilsEx::ReadString(hKey, _T("key1"), str))
{
  // if not present, write it in registry
  RegistryUtilsEx::WriteString(hKey, _T("key1"), _T("value1")); 

  // now it should be read
  RegistryUtilsEx::ReadString(hKey, _T("key1"), str);
}

Simillary, you can use ReadDword() and WriteDword() for reading and writing integer values, and ReadBinary() and WriteBinary() for generic binary data.

// read an integer
DWORD number;
if(RegistryUtils::Success != RegistryUtils::ReadDword(hKey, _T("key2"), number))
{
  // if not present in the registry, write it
  RegistryUtils::WriteDword(hKey, _T("key2"), 44); 

  // this time it should be read
  RegistryUtils::ReadDword(hKey, _T("key2"), number);
}

To close an opened key call RegistryUtils::CloseKey().

RegistryUtils::CloseKey(hKey);

Additionally, RegistryUtils::DeleteKey() can be used to delete a specified key, along with all its sub-keys and values.

The code is available for download here.

Recently, CodeGuru has published my article about customizing the Places Bar of the common file dialog. In this article I have explained how to twick the registry to display your own list of shortcuts in the places bar.

The folders are specified in registry under HKEY_CURRENT_USER in Software\Microsoft\Windows\CurrentVersion\Policies\ComDlg32\PlacesBar in two ways: either by IDs for a predefined list of folders, or by path. The name of the values must have the form PlaceX, where X is a numerical value. The key specified above does not exist by default. The operating system tries to read it and if it is find, it loads the enumerated places; if the key is missing a default list is displayed. The key affects the entire system, except for the application in the Office suite. To have a Places Bar changed only for a specific application, a temporary modification of the registry can be done, by mapping a temporary key to HKEY_CURRENT_USER with the use of RegOverridePredefKey() API. That basically implies:

• Creating a temporary key and mapping it for the HKEY_CURRENT_USER
• Putting the file dialog places there under Software\Microsoft\Windows\CurrentVersion\Policies\ComDlg32\PlacesBar
• Displaying the file dialog
• At the end, restoring the predefined HKEY_CURRENT_USER and deleting the temporary key

In the article published on CodeGuru you can read more details about this and see the code of a demo application that I created to explain how things work. The article is available at http://www.codeguru.com/cpp/misc/misc/system/article.php/c13407/.