Update: ZDNet, Slashdot & Ars Technica have more.

appdir\host.exe
plugindir\plugin.dll
plugindir\plugindependency.dll
plugindir\pluginresource.txt

where host.exe explicitly loads plugindir\plugin.dll, which in turn has a static dependency on plugindependency.dll.

As-is, this structure doesn't work, because the DLL search order has the directory of the application appdir in the search path, but not plugindir. So plugindependency.dll won't be found.

This is solvable by isolating plugin.dll. The way to do this is to embed a manifest under the RT_MANIFEST section of its resources as ID 2  (aka ISOLATION_AWARE_MANIFEST_RESOURCE_ID.) E.g.:

<?xml version='1.0' encoding='UTF-8' standalone='yes'?>
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'>
  <file name="plugindependency.dll" />
</assembly>

When plugin.dll is loaded, the loader automatically activates this manifest when resolving static dependencies and doing DllMain callouts. Files listed the manifest bypass the DLL search order and are directly loaded out of the directory of the manifest, in this case plugindir, which is what we want. Problem solved.

Notes

Beyond static imports, the embedded manifest isn't always active when code inside plugin.dll is executing. To have it be active, you either need to use ISOLATION_AWARE_ENABLED or manual activation/deactivation, as described in Junfeng’s post, for example if you want LoadLibraryEx to be able to find plugindependency.dll

Beyond dlls, you can also list all of your plugin's resource files in the manifest as well. They won't automatically be found, but SearchPath with a NULL first parameter while the appropriate manifest is active will find them in the correct directory (for files listed in the manifest, you can disregard the remarks section of the API documentation.) Unfortunately ISOLATION_AWARE_ENABLED doesn't wrap SearchPath, so you'll have to do manual activation/deactivation here.

Caution: if plugin.dll depends on some external redistributable components, don't list them directly as <file> elements in the plugin's manifest file, because it will prevent them from being serviced in the future (listing dependencies on other side-by-side assemblies is fine.) For example, a Microsoft dll might get updated by installation into the system directory -- if the dll is listed in the manifest, your plugin won't pick up the serviced version, opening you up to security issues.

Visual Studio 2005 & 2008 runtimes are shipped as Windows Side-by-Side assemblies. Determining whether these are installed isn’t as straightforward as checking for file existence, as outlined in this post. I promised to put those techniques to use, which I’m doing here, along with a checker for the non-side-by-side 2010 runtimes.

To help understand the install state of the Visual Studio 2005/2008/2010 runtimes, I’ve written the creatively-named "checkruntimes.exe", which you can find in the zip file attached at the bottom of this post.

Usage:

> checkruntimes.exe –help

Installation checker for Visual Studio runtime libraries
By default checks for versions 8, 9 and 10 of the runtime libraries on
all architectures, both debug & release

Usage:

  checkruntimes.exe [-quiet] [-help] [-8] [-9] [-10] [-debug] [-retail]
                [-x86] [-x64] [-ia64] [-crt] [-atl] [-openmp] [-mfc]

The command-line switches -8 -9 ... -x86 -mfc are restrictions. That is to say,
by default everything is searched, but if specified only those specific
libraries will be searched for.

The return value of the program is the number of libraries found.
If you pass the -quiet switch, no output is generated, so you can use this
program from a script to validate installation state of runtimes.

Examples:

  checkruntimes.exe -9 -retail -x86 -crt
  Check for the Visual C++ v9 (VS 2008) retail 32-bit runtime library.

  checkruntimes.exe -10 -x64
  Check for all Visual Studio version 10 (VS 2010) x64 runtime libraries.

  checkruntimes.exe -8 -ia64 -debug -quiet
  Check for all Visual Studio v8 (VS 2005) debug Itanium-architecture libraries,
  but don't display any output, only return the number found.

Samples:

> checkruntimes.exe -x86 -crt -8 -10

When called with no arguments, it lists runtimes it can find – calling checkruntimes.exe with no arguments is equivalent to calling:

> checkruntimes.exe -8 -9 -10 -debug -retail -x86 -x64 -ia64 -crt -atl -openmp -mfc

Of note, the return code is the number of runtimes found of the machine. For example, suppose you were checking for the 32-bit release of the VS2008 CRT & ATL. From a script you could invoke:

@echo off
checkruntimes -crt -atl -9 -retail -x86 -quiet
echo Found %ERRORLEVEL% libraries
if %ERRORLEVEL% NEQ 2 goto :LibrariesNotFound
echo Success!
goto :EOF
:LibrariesNotFound
echo Some of x86 crt and atl v9 retail not found

Notes:

Visual Studio 2005 is referred to by the version number 8, VS 2008 likewise by the version number 9 and VS2010 by the version number 10.

Note also that while this program can check for their presence, the debug runtimes are not redistributable. You can find more information about those here: https://msdn.microsoft.com/en-us/library/aa985618.aspx

For the Visual Studio 2005 & 2008 runtimes, as they are side-by-side assemblies, there can be multiple versions of each assembly installed. This utility only displays the highest-version assembly installed, as dependencies on lower build/revision numbered assemblies can be satisfied by higher-versioned ones.

What about Visual Studio .NET 2002 and Visual Studio .NET 2003?

While on a development machine these redistributables may be placed System32 by the development environment,  they are not meant to be centrally installed on client machines. Instead, they must be included into each application’s local directory for private use by that application. For  this reason, there’s nothing for this tool to check – the  redistributables should never be centrally installed. For more information on redistribution policies for these versions of Visual Studio, please see here: https://support.microsoft.com/kb/326922.

checkruntimes.zip

Why not just probe the WinSxS directory for the expected files?

The existence of files in this directory should not be taken as an indication that the operating system considers these files to be installed. True to its designation of "cache", the directory may hold on to recently-installed or soon-to-be-installed files until they are installed or scavenged in bulk. Scavenging happens periodically, but it cannot be controlled or induced. It is important to note then, that uninstalling a Side-by-Side assembly may not immediately remove the associated files from the WinSxS directory. This is expected, and not a violation of Windows Logo requirements for clean uninstall.

Second, the internal layout of this directory is not documented as it changes with each release of Windows. For this reason, direct paths into this directory should not be hard-coded for probing anywhere. (They should not even be computed & stored – if the user were to upgrade their OS since the time a path was computed the information would no longer be accurate.)

Programmatically checking install state

The easiest method to check whether an assembly is installed is to simply try to use it. While trying to run a program that depends on an assembly and checking for failure to launch is certainly a (heavy-handed) way of accomplishing this, perhaps the best approach is to use the Activation Context APIs.
Given a manifest "CheckMFC.manifest":

<?xml version='1.0' encoding='UTF-8' standalone='yes'?> 
<assembly xmlns='urn:schemas-microsoft-com:asm.v1' manifestVersion='1.0'> 
  <dependency> 
    <dependentAssembly> 
      <assemblyIdentity name="Microsoft.VC90.MFC" 
                        version="9.0.30729.1" 
                        processorArchitecture="x86" 
                        publicKeyToken="1fc8b3b9a1e18e3b" 
                        type="win32" /> 
    </dependentAssembly> 
  </dependency> 
</assembly>

Use the following code:

BOOL fInstalled = FALSE; 
ACTCTXW acw = { sizeof(acw) }; 
acw.lpSource = L"CheckMFC.manifest"; 

HANDLE hActCtx = CreateActCtxW(&acw); 
if (hActCtx != INVALID_HANDLE_VALUE) { 
    fInstalled = TRUE; 
    ReleaseActCtx(hActCtx); 
}

Note that this code doesn’t check for version 9.0.30729.1 strictly – it will also flag success if there’s a compatible higher version installed (technically, if there is an installed assembly with a higher revision/build version that redirects 9.0.30729.1 through a publisher policy).

A second way to check is to use the Assembly Cache APIs directly, notably IAssemblyCache::QueryAssemblyInfo. Note that in general, these APIs are supported only on Vista and later, and may not be available or work as intended on earlier OSes. The difference with this method is that it requires you to know the exact details of the assembly you are looking for, including the full version number, Major.Minor.Revision.Build, which is overly restrictive if the question is "is there an installed assembly that will let my application run?"

In the next post, I will provide a simple tool to verify the installation of the Visual Studio redistributable assemblies.

It’s filled with rooms describing each aspect of Windows, from multimedia to security to gaming, and large lounges where you can try out the latest computers.
Since I was wearing a Windows-logo scarf from the last company meeting, I was given the royal tour from the friendly staff (with nicknames like Snapman for Aero Snap and Peekman for Aero Peek). Pictures below:

Moi je suis PC!

The Windows 7 Café is located at 47 Boulevard de Sébastopol, near the Châtelet.
Buying coffee is optional