Logo
HOWTO: Automating Visual Studio .NET from outside the IDE

Author: Carlos J. Quintero (Microsoft MVP) Applies to: Microsoft Visual Studio .NET 2002
Date: August 2005   Microsoft Visual Studio .NET 2003
Updated: March 2013   Microsoft Visual Studio 2005
      Microsoft Visual Studio 2008
      Microsoft Visual Studio 2010
      Microsoft Visual Studio 2012
Introduction

This article describes how to automate the Visual Studio .NET IDE from outside the IDE.

More Information

Visual Studio .NET exposes an extensibility model that can be used to automate it. This object model resides in the EnvDTE.dll assembly, which you can explore using the Object Browser. The root class of the object model is EnvDTE.DTE, and therefore you need an instance of this class to automate it.

You have the following ways to automate the Visual Studio .NET IDE:

  • Using macros: macros are procedures written in VB.NET that allow to automate some tasks from within the IDE. To write macros you use the Macros IDE (Tools, Macros, Macros IDE menu). To explore and run your macros you use the Macro Explorer window (View, Other Windows, Macro Explorer menu). Macros provide an implicit instance of the EnvDTE.DTE class named DTE.
  • Using an add-in: an add-in is a compiled DLL that through a special registration it is loaded by Visual Studio .NET and provides new commands, command bars and buttons to perform new actions. Visual Studio .NET passes an instance of the EnvDTE.DTE class to a method of the add-in when the connection takes place.

The previous methods automate the IDE from within, but there is a third method that you can use to automate the IDE from the outside, for example from other application or from a script. To do this, first you need to create an instance of the EnvDTE.DTE class. This is done using the CreateObject function of most COM-aware languages, passing the ProgID of the class. The list of available ProgIDs is the following:

  • For Visual Studio .NET 2002: "VisualStudio.DTE.7"
  • For Visual Studio .NET 2003: "VisualStudio.DTE.7.1"
  • For Visual Studio 2005: "VisualStudio.DTE.8.0"
  • For Visual Studio 2008: "VisualStudio.DTE.9.0"
  • For Visual Studio 2010: "VisualStudio.DTE.10.0"
  • For Visual Studio 2012: "VisualStudio.DTE.11.0"
  • For the highest installed version of Visual Studio .NET, you would use the version-independent ProgID "VisualStudio.DTE".

If you want to use late binding (for example, automating Visual Studio in VBScript) you just use the object returned by the CreateObject function. If you want to use early binding (for example, automating Visual Studio in a .NET application), then you need to cast the object returned by the CreateObject function to the EnvDTE.DTE type. To do this, your project needs to add a reference to the EnvDTE.dll assembly. Notice that there are two versions of the EnvDTE.dll assembly:

  • Version 7.0.3300.0: installed by Visual Studio .NET 2002/2003. Not installed by Visual Studio 2005 or higher.
  • Version 8.0.0.0: installed by Visual Studio 2005 or higher. Not installed by Visual Studio .NET 2002/2003.

As a consequence, using early binding you can't automate all Visual Studio versions at the same time, because even if your .NET application uses .NET 1.0 to run on all .NET Frameworks, if it references EnvDTE.dll version 7.0.3300.0 it won't work on systems with only Visual Studio 2005 or higher installed; and if it references EnvDTE.dll version 8.0.0.0 it won't work on systems with only Visual Studio .NET 2002 or 2003 installed.

There are two important properties that control the behavior of the IDE while you are automating it from the outside:

  • DTE.MainWindow.Visible: by default, when you create an instance of the IDE, it is invisible. If you want to make it visible, you must set this property to True.
  • DTE.UserControl: when set to True, the IDE remains open after you are done with the automation. This is useful if you want to open the IDE, perform some action, and keep if open for the user to continue using it. When set to False, the object is released after you are done with the automation and the devenv.exe process shouldn't remain in memory (use the Task Manager to verify it). If it stays in memory, it means that you are not releasing all COM wrappers used to automate it. See this related article for Office that can apply to any COM-based application such as Visual Studio: Office application does not quit after automation from Visual Studio .NET client

The following VBScript sample shows how to create an instance of Visual Studio .NET 2003 and show its name and version:

Dim objDTE
 
' Creates an instance of the Visual Studio .NET 2003 IDE
Set objDTE = CreateObject("VisualStudio.DTE.7.1")
 
' While the instance is still invisible, show its name and version
MsgBox objDTE.Name & " " & objDTE.Version
 
' Make it visible and keep it open after we finish this script
objDTE.MainWindow.Visible = True
objDTE.UserControl = True

The following VB.NET sample does the same:

Dim objType As Type
Dim objDTE As EnvDTE.DTE
 
' Creates an instance of the Visual Studio .NET 2003 IDE
objType = Type.GetTypeFromProgID("VisualStudio.DTE.7.1")
objDTE = DirectCast(System.Activator.CreateInstance(objType), EnvDTE.DTE)
 
' While the instance is still invisible, show its name and version
MsgBox objDTE.Name & " " & objDTE.Version
 
' Make it visible and keep it open after we finish this script
objDTE.MainWindow.Visible = True
objDTE.UserControl = True


Go to the 'Visual Studio Extensibility (VSX)' web site for more articles like this (Articles section)


Top