My Account account_circle

Today I’d like to share my experiences of programmatically integrating .NET assemblies into a couple of IDEs, mainly Visual Studio and Delphi. I think it might be useful for some of you.

Originally, the integration of the SmartInspect .NET assembly into the supported IDEs was simple. There was just a single registry key which needed to be added and all IDEs recognized the new library:


Just replace <p> with the actual name of your product, set the default value of the new key to your library path and you’re done. This was the way we did it in the previous SmartInspect versions which had a single assembly only. Things got complicated when we decided to provide two different assemblies, one for .NET 1.x and one for .NET 2.0.

Well, we could have changed the setup to create an additional registry key for the .NET 2.0 library under the same parent and all IDEs would recognize both libraries correctly, but the problem here was that we didn’t want the .NET 2.0 library to be displayed in .NET 1.x IDEs. It couldn’t be used anyway and would probably confuse a few customers. So, we needed to find a way to integrate the assemblies on a per IDE basis rather than using the “global” AssemblyFolders registry key.

Borland Developer Studio

After googling a bit, I found the answer for the BDS family (C# Builder, Delphi) quite fast. Just create a registry key with the same characteristics as above under the following parent key:


Replace <v> with the actual version of BDS, either 1.0 for C# Builder, 2.0 for Delphi 8 for .NET or 3.0 for Delphi 2005. That’s simple and works well, even Borland lists its assembly folders there.

Visual Studio

Integrating assemblies into Visual Studio .NET 2002 and Visual Studio .NET 2003 works similarly. Like BDS, they walk through their “local” AssemblyFolders registry key to find thirdy-party assemblies. The AssemblyFolders registry key for them looks like this:


Again, replace <v> with the actual version of your target IDE, either 7.0 for Visual Studio .NET 2002 or 7.1 for Visual Studio .NET 2003. Since this works well with the 2002 and 2003 editions of Visual Studio, I assumed the same behavior for Visual Studio 2005 as well. But not so! It didn’t work. As I found out, using regmon, Visual Studio 2005 simply ignores the local AssemblyFolders registry key. Instead, it looks for subkeys with the usual characteristics under the so called global AssemblyFoldersEx key, an improved version of AssemblyFolders. The location for the parent key looks like this:


This time, <v> needs to be replaced with the version of the installed .NET 2.0 framework rather than taking the internal version number of Visual Studio 2005. As of this writing, the framework version looks something like v2.0.50215. The exact version can be found at HKLM\Software\Microsoft\VisualStudio\8.0\CLR Version.

Quite confusing in my opinion. So, if you need to integrate assemblies into one or more of the mentioned IDEs, I hope you find this posting useful. Corrections and additions are much appreciated.

How useful was this post?

Click on a star to rate it!

Stay ahead in Test Management.

Follow us on social media!

Help us improve this page!

What problem are you trying to solve?