How Visual Studio 2010 toolbox works

Alexander Vezenkov / Wednesday, May 2, 2012

How Visual Studio 2010 toolbox loads its items

Many of us may probably say that the toolbox is one of Microsoft Visual Studio’s weak points. Maybe the answer is yes, but the way it works seems the only option for the great extensibility Visual Studio toolbox provides. However, it is good to know what happens behind the scenes.

In order to optimize the toolbox loading time Visual Studio relies on a caching mechanism. This mechanism consists of two caches: a registry cache and a file cache (“.tbd”). The second one normally consists of four “.tbd” files which store the current visual state of the toolbox and its original visual state (for when you click “Reset Toolbox”). The visual state of the toolbox changes only if the user explicitly makes it take that action or the registry cache is refreshed.

The registry cache consists of two main keys:




The first one was introduced with Visual Studio 2010. It reflects the directory locations that need to be searched for toolbox metadata and design assemblies for each SDK or Framework. The second one reflects every entry that is installed/located here (note that  this is a 32-bit key located under Wow6432Node on 64-bit machines):


It contains a separate entry for each assembly to register in the toolbox. This requires more effort to implement and is the older (VS 2008) way of registering Visual Studio toolbox controls.


What happens every time Visual Studio loads its toolbox?


First the registry cache hash is compared to the actual toolbox registry keys that the cache is reflecting. Each SDK/Framework registry key  is inspected for changes. The following is an example of such a key:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\Microsoft SDKs\Silverlight\v5.0\AssemblyFoldersEx\Ria Services v1.0 Silverlight Libraries\Toolbox]

If the hash coincides with the original registries then the toolbox loads from the .tbd files in mere seconds. If any of the original registry keys have changed, then their cache key is rebuilt with a new hash value and the .tbd files are refreshed to reflect the change. All the design metadata of the assemblies is being reloaded as part of that operation. This could take minutes depending on the quantity of the third-party controls installed.

Visual Studio is actually loading and showing the toolbox items when a file is opened for editing in design mode. It shows the SDK/Framework items that only match the technology type of the file (only the compatible controls).


Toolbox Expert Mode = Super-Fast Load

You could manually add/remove items to the toolbox and preserve its state and even prevent the “ToolboxControlsInstaller” package to load and rebuild cache by setting the DWORD value of the following key to 0:

[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\10.0\Packages\{2c298b35-07da-45f1-96a3-be55d91c8d7a}\Toolbox\Default Items]

Note that it will prevent any tools to modify/install/uninstall items from your toolbox. You will have to manually handle it. The advantage is the toolbox loads in seconds.

Hope this helps people fight toolbox issues effectively.