The SxS loader, also called “Fusion”, which I mentioned previously, is a new feature available starting with Windows XP that allows deploying multiple versions of the same DLL to a global store, “the next generation of system32”, where multiple versions of the DLL live side by side. Client applications use XML manifests to create activation contexts that specify which version is desired, avoiding a binary compatibility nightmare. You can read more about SxS here. This global store is known as “winsxs” and has a new name, “Component Servicing Infrastructure”, in Vista. For you managed developers, you can consider it as some sort of a native version of the GAC.
Until recently, the only documented way to install Win32 native SxS assemblies to the global store was by using MSI, the Windows Installer. The SxS DLL is described in a table in the MSI database and during package installation it is copied to the winsxs store. This may be a decent solution for those who already use MSI to deploy their projects, but it can be overkill for others. Even in larger projects, it is obvious that not everyone likes using MSI.
Microsoft recognized the need of .NET developers to deploy managed assemblies to the GAC without MSI and documented their previously undocumented GAC API, residing in fusion.dll, in blog entries, a knowledge base article and finally right in MSDN. This API is based around Fusion.dll’s IAssemblyCache interface.
It’s no surprise that the API for installing managed assemblies was documented first. Native SxS does not seem to be widely used (although its internal use by Microsoft has increased significantly – compare the Vista winsxs directory to XP’s and see what I mean) – which is unfortunate, since it can solve a lot of problems.
Recently, however, an API for managing native SxS DLLs in the winsxs store was documented. This API is basically identical to the GAC API in fusion.dll, but instead resides in sxs.dll, an OS component starting with Windows XP. The API is now documented in MSDN here.
While a welcome development, the documentation of this API leaves something to be desired. First of all, the API is documented for Windows Vista and Windows Server 2008, while looking at the export table of Windows XP’s sxs.dll illustrates that is definitely present in Windows XP in one form or another. When I asked about this here, the reason for this turned out to be the fact this API isn’t tested on XP and Windows Server 2003 (Hmm……)
Second of all, the SxS store’s reference counting isn’t described too much. I’d like to know the subtle meanings of the various schemes in FUSION_INSTALL_REFERENCE. I suppose up to this point, with MSI being the only name in town, FUSION_REFCOUNT_MSI_GUID was the only one actually being used.
Still, despite the downsides, the SxS API finally provides an alternative for those who would rather avoid MSI and still enjoy the benefits of isolation. I hope to see wrappers for the API becoming available online and coming to good use.
With this API, installing a SxS DLL becomes as simple as calling IAssemblyCache::InstallAssembly. Examples can be found online of using the nearly identical GAC API on managed assemblies – these can easily be used as the basis for a native SxS assembly installation routine.
Of course, the Visual C++ 2005 CRT and other runtime redistributables are native side by side assemblies themselves. MSVCR80.DLL is installed to the winsxs store and not to system32 like previous versions of the CRT. So I was hoping the availability of a documented API for SxS DLL installation would provide another supported deployment facility for the Visual C++ 2005 redistributables, in addition to the Windows Installer merge modules which of course are only suitable for an MSI installation. The second alternative of deploying all the redistributables, even those that you don’t need for your project, in the form of vcredist.exe, is even worse.
Unfortunately, when I asked a Program Manager in the Visual C++ team whether the availability of the SxS API means it is now supported as a way to deploy the runtimes, I got a negative response. The Visual C++ Team, for their reasons, prefer to keep restricting developers to the existing deployment methods, with all their problems, preventing seamless integration of runtime deployment into custom installers.
This stance is yet another motivation to use the OS CRT instead of the Visual C++ CRT when deploying projects. See my previous post describing this approach. If you like it, let Microsoft know you’d like to see this supported better.