INFO: Assemblies used in Visual Studio Extensibility

Author:	Carlos J. Quintero (Microsoft MVP)	Applies to:	Microsoft Visual Studio .NET 2002
Created:	February 2007		Microsoft Visual Studio .NET 2003
Updated:	August 2011		Microsoft Visual Studio 2005
			Microsoft Visual Studio 2008
			Microsoft Visual Studio 2010

Introduction

This article explains the assembly DLLs used when creating add-ins for Visual Studio .NET.

More Information

When you create a Visual Studio .NET add-in using the wizard, several assembly DLLs are added to your add-in project. Depending on your needs, you may need to add some other extensibility assemblies. The common assemblies that you use in an add-in are:

Assembly	Visual Studio Version	Description
Extensibility.dll	2002, 2003, 2005, 2008, 2010	This assembly contains the definition of the IDTExtensibility2 interface (implemented by all add-ins) and some enums related to the connection and disconnection of the add-in.
CommandBars Assemblies
Office.dll	2002, 2003	This assembly contains the commandbar model for borrowed from Office.
Microsoft.VisualStudio.CommandBars.dll	2005, 2008, 2010	This assembly contains the commandbar model specific for Visual Studio 2005, replacing Office.dll. The model is the same, but this dll does not contain stuff that only applies to Office but not to Visual Studio add-ins.
Common (all languages) automation model
EnvDTE.dll	2002, 2003, 2005, 2008, 2010	This assembly contains the extensibility model of Visual Studio to manage the IDE, solutions, projects, files, code, etc.
EnvDTE80.dll	2005, 2008, 2010	This assembly does not replace EnvDTE.dll. Rather, it contains additional classes, interfaces and enums (typically ending with "2" such as EnvDTE80.DTE2) with additional methods. So, a Visual Studio 2005 add-in references both EnvDTE.dll and EnvDTE80.dll.
EnvDTE90.dll	2008, 2010	This assembly does not replace EnvDTE.dll or EnvDTE80.dll. Rather, it contains additional classes, interfaces and enums (typically ending with "3" such as EnvDTE90.HTMLWindow3) with additional methods. So, a Visual Studio 2008 add-in references EnvDTE.dll, EnvDTE80.dll and EnvDTE90.dll.
EnvDTE90a.dll	2008 SP1, 2010	This assembly does not replace EnvDTE90.dll. Rather, it contains additional classes, interfaces and enums related to the debugger.
EnvDTE100.dll	2010	This assembly does not replace EnvDTE.dll, EnvDTE80.dll or EnvDTE90.dll. Rather, it contains additional classes, interfaces and enums.
VB.NET/C# automation model
VSLangProj.dll	2002, 2003, 2005, 2008, 2010	This assembly contains an additional extensibility model for VB.NET, C# and Visual J# projects. For example, to manage references, that other projects lack. See the Related Articles section at the end of this article.
VSLangProj2.dll	2003, 2005, 2008, 2010	This assembly does not replace VSLangProj.dll. Rather, it contains additional enums (that previously you had to hardcode) and interfaces.
VSLangProj80.dll	2005, 2008, 2010	This assembly does not replace VSLangProj.dll or VSLangProj2.dll. Rather, it contains additional enums (that previously you had to hardcode) and interfaces.
VSLangProj90.dll	2008, 2010	This assembly does not replace VSLangProj.dll, VSLangProj2.dll or VSLangProj80.dll. Rather, it contains additional enums (that previously you had to hardcode) and interfaces.
VSLangProj100.dll	2010	This assembly does not replace VSLangProj.dll, VSLangProj2.dll, VSLangProj80.dll or VSLangProj90.dll. Rather, it contains additional enums (that previously you had to hardcode).
VsWebSite.Interop.dll	2005, 2008, 2010	This assembly contains the extensibility model for the new Web Site project type introduced in Visual Studio 2005. See the Related Articles section at the end of this article.
VsWebSite.Interop90.dll	2008, 2010	This assembly does not replace VsWebSite.Interop.dll. Rather, it contains additional enums (that previously you had to hardcode) and interfaces.
VsWebSite.Interop100.dll	2010	This assembly does not replace VsWebSite.Interop.dll or VsWebSite.Interop90.dll. Rather, it contains additional enums (that previously you had to hardcode) and interfaces.
Visual C++ automation model
Microsoft.VisualStudio.VCProject.dll	All	This assembly contains types for the Visual C++ automation model. Each Visual Studio version provides an assembly that completely replaces the ones of the previous versions.
Microsoft.VisualStudio.VCProjectEngine.dll	All	This assembly contains types for the Visual C++ automation model. Each Visual Studio version provides an assembly that completely replaces the ones of the previous versions.
Microsoft.VisualStudio.VCCodeModel.dll	All	This assembly contains types for the Visual C++ automation model. Each Visual Studio version provides an assembly that completely replaces the ones of the previous versions.

Notice that while the VB.NET/C# automation model assemblies (VSLangProj*.dll) complement the previous versions providing additional types, the Visual C++ automation model assemblies (Microsoft.VisualStudio.VC*.dll) completely replace the previous versions in each Visual Studio version.

Notice also that these assemblies are in two folders:

Visual Studio folders such as:

C:\Program Files\Microsoft Visual Studio .NET 2003\Common7\IDE\PublicAssemblies
C:\Program Files\Microsoft Visual Studio 8\Common7\IDE\PublicAssemblies
C:\Program Files\Common Files\Microsoft Shared\MSENV\PublicAssemblies
Etc.

These folders are intended for development purposes.

The Global Assembly Cache (GAC). The GAC is typically the folder C:\Windows\Assembly and although it is internally a set of folders, there is a shell viewer that shows the assemblies as a single list.

This folder is for deployment purposes, which means that you don't have to include these assemblies in your setup (they are already on the target machine) and that you shouldn't reference assemblies in this folder (you should use the previous folders).

Go back to the 'Resources for Visual Studio .NET extensibility' section for more articles like this

Top