I will publishing a series of blog posts describing how to extend Visual Studio (VSX in particular) to maintain a history of code changes or actions within the IDE. The audience for these articles would most likely be researchers who are trying to understand how to do interesting developer analytics, intelligent work summaries, or build interesting work history visualizations, or next-gen developer tools.

I will be starting out with how to set up an package which will be the core entry point into Visual Studio receiving events. It used to be prior to Visual Studio 10, you could only create a VSIP Package that allowed deep integration with Visual Studio if you jumped through all sorts of hoops and hurtles.

First, make sure you have the Visual Studio SDK SP1 installed. These will install some private assemblies and create some project templates.

Let’s create the project called VSHistory.

This will create a new file VSHistoryPackage.cs. One attribute that we will want to add that is essential for a history extension is an “autoload” attribute. This will make sure the package is loaded and initialized without having to launch it from a menu: in this case, it is autoloaded when an solution is available.

[ProvideAutoLoad(VSConstants.UICONTEXT.SolutionExists_string)]

Next thing we will want to add is an IVsSolutionEvents interface. This will make sure we can respond to events like a project or opening.

public sealed class VSHistoryPackage : Package, IVsSolutionEvents

public int OnAfterOpenSolution(object pUnkReserved, int fNewSolution)
{
   return VSConstants.S_OK;
}

The International Conference on Program Comprehension (ICPC 2011) was a charming affair, bringing together a diverse set of researchers from around the globe.

Here are some of my personal reflections:

Three Research Perspectives

Leon Moonen drew upon centuries of wisdom collected by architects and map makers to find design principles of wayfinding that could be applied toward software exploration and navigation interfaces.

Margaret Burnett showed how studying the barriers faced by a segment of a population (in this case gender) could be used to for making design improvements that benefit the whole population.

Margaret-Anne Storey reflected on the trials and tribulations of trying to bring a software visualization system (SHriMP) to become loved and adopted by professional programmers. In the process, she emphasized on the importance of working with cognitive theories, but also pointed out that our current set of program comprehension theories have long since expired.

Technical Program

The technical program was both interesting and strong with a nice mix of topics. Which was something, personally, I did not see at ICSE.

The program started out on a technical note: clustering, identifier splitting, smoothing filters to improve information retrieval (IR) tasks in software. The tradition of awarding best papers to IR papers also continued with “Improving IR-based Traceability Recovery Using Smoothing Filters” taking the price.

Another strong topic that emerged was the study of the interaction or work history of developers. Annie Ying looked at edit patterns and their relation of task difficulty. David Röthlisberger studying patterns of artifact relevancy for different types of programming tasks. Lile Hattori had an well-performed study studying the benefit of replaying code changes in the IDE in comparison to viewing differences in subversion.

There were also some really nice empirical studies and tools. Anja Guzzi gave a spunky presentation (one of the best talks) on collaborative bookmarks in the IDE (Check out Pollicino). Stefan Endrikat laid a critical eye over aspect-oriented programming (AOP) with a study that cast doubt over the purported benefits of AOP. Daqing Hou manually poured over newsgroup postings to get a better understanding of why developers have trouble about certain API methods.

Hunting Particles

Tasks, for the purpose of this post, are assigned units of work. In practice, this may be a “story” or “defect” from an iteration in the agile world, or a “work item” in TFS land, or even a “feature” in trackers such as trac. There are many names given to tasks, but for the programmer, ultimately they are externally assigned responsibilities.

Tasks are also broken down. For example, in version one, a “epic” is often broken down into several “stories”, and ending with “tasks” that may be split across multiple iterations or developers.

But does it end there? Are tasks indivisible atoms of software development? Survey says, not likely. When 414 professional developers were asked about the nature of assigned tasks, more often then not, developers felt the actual work had to be broken down much further, usually after exploration and experimentation and involved elaboration on many steps, issues, and TODOs.

Task-focused Interfaces

Although we have excellent tools for issue and task tracking, there is a gap in tool support for managing and tracking the knowledge and breakdowns beyond the initial assigned responsibility. Instead, these sorts of information are scattered on scraps of paper, white boards, source code comments, or human memory. Studies on interruptions of programmers show that after an interruption, programmers spend 15-30 minutes gathering loss information before making their first edit.

The most successful attempt at solving this problem has been, Mylyn, a “task-focused interface” available in Eclipse that will track the “task context”.

There are two weaknesses that can be improved upon: 1) The idea of “task context” has been mostly limited to the files and methods that were visited or edited during a particular task. Surely there is much more bits of “context” than places in code. 2) Breakdowns of tasks are a little heavy weight. Although the idea of “subtasks” are supported, they are not frequently used in practice. Eclipse usage data suggests that less than 10 users have created subtasks compared to the hundreds that have “activated” Mylyn tasks.

Task-focused Interfaces 2.0: Tasklets and Memlets

VSX extensions/packages published and installed through the visual studio gallery will automatically check for updates and allow you to install the newest versions.

If you’re not deploying your extension through the gallery, or just want auto-update capability for yourself, you can mimic this process yourself using the IVSExtensionManager interface. But when I wanted implement this, exactly how to do it was not documented anywhere.

The process is actually straight-forward:

You’ll need to reference:

Microsoft.VisualStudio.ExtensionManager.dll
Microsoft.VisualStudio.OLE.Interop
Microsoft.VisualStudio.Shell.Interop.8.0

Warning, the extension assembly isn’t published in the .NET components, you’ll have to manually browse to the GAC to reference it: C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.ExtensionManager\v4.0_10.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.ExtensionManager.dll

var manager = Package.GetGlobalService(typeof(SVsExtensionManager)) as IVsExtensionManager;

Using the manager, get a list of installed extensions