Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Microsoft Makes Samples and Documentation Public for Concord, Visual Studio Debug Engine

Microsoft Makes Samples and Documentation Public for Concord, Visual Studio Debug Engine


Visual Studio debug engine documentation is now available online, along with two samples. This debug engine, codenamed Concord, is Visual Studio's new debug engine that originally shipped in Visual Studio 2012.

Concord’s design is made of different parts communicating with each other, instead of being monolithic like its predecessor. This new design makes it possible to offer a public API, providing entry points to extend the debugging features of Visual Studio like the breakpoints or the call stack. The design also enables the choice of using native (C++) or managed (C#) code for extension implementation.

The first sample is the classic HelloWorld. Compiling it requires the Visual Studio SDK. The HelloWorld sample outputs one line in the call stack, as shown in the image below.

The other extension sample is a .NET language (CLR) expression evaluator. Expression Evaluators are components allowing users to debug in the same language as the code was written. This is done by customizing debugger windows such as the Watch, Call stack, and Function breakpoints to the language of the code. In short, this extension provides an example of how to implement debugging in Visual Studio for a custom compiler.

The Concord API being rather large, hints are provided to make the navigation easier:

  1. When deciding what interfaces to implement, we have organized all the interfaces by the category of component that implements the interface. If you look in the native API header file (vsdebugeng.h) you can see each interface listed by section, as well as a description of what that category of component does.

  2. When looking for methods to call, ignore interfaces. The Concord API is exposed to callers as methods on classes rather than interface methods.

  3. Even if you are implementing a Concord component in managed code, sometimes the fastest way to find the method that you want is to look for strings in vsdebugeng.h. Since the API is the same between native and managed code, if you find the native API, it will work in managed also.

  4. Browse the references in Microsoft.VisualStudio.Debugger.Engine – this is the flip side of #3, even if you are consuming the Concord API from native code, Visual Studio ships really nice support for browsing through managed APIs.

Concord is not open source by itself, however the documentation project is. Contributions can be made by submitting new samples.

Rate this Article