Solution Overview

The application logic in the solution is contained in four projects, described below.

• WorkingFilesList

  Code and resources to support and integrate the tool window and additional Tools -> Options page as a Visual Studio extension, including the package icon and preview image, VSIX manifest, as well as IoC bindings.

• WorkingFilesList.Core

  Classes and interfaces used by both the tool window, and the Options page.

• WorkingFilesList.ToolWindow

  UI declarations, resources, and logic for the tool window itself.

• WorkingFilesList.OptionsDialoguePage

  UI declarations, resources, and logic for the page that is added to the Visual Studio Tools -> Options dialogue.

Each has its own tests project with the same name, but with a .Test suffix. The layouts of the tests projects follow the structure of the project they test, making it easier to find tests for any given class. The remainder of this page describes WorkingFilesList.ToolWindow

Architecture Overview

The overall architecture used within the solution follows the MVVM pattern. Broadly speaking the View and Model folders correspond with the respective MVVM layers, with the remaining folders corresponding to the view model layer; custom controls (e.g. NumericUpDown are in the view layer. The Interface folders contain interfaces used throughout the various projects: to promote loose coupling (through IoC) and testability, many of the classes implement an interface. The DesignTimeData folder in WorkingFilesList.ToolWindow contains files useful during development

Composite View Models

To minimise the responsibilities of each class, the conceptual view model of the tool window has been broken into smaller separate classes; a service locator class was created to facilitate view model assignment through XAML. Image 1 illustrates the concept of using multiple objects as part of the whole view model.

Image 1: The view model of the tool window consists of multiple objects

The separation of view model classes has created a number of discrete namespaces, including ViewModel and Services. The general distinction between these is that the former includes application state, while the latter are stateless functions.

Tracking the State of Open Document Windows

This extension makes use of the Visual Studio automation object model. By subscribing to various events made available through the EnvDTE.DTE interface it is possible to update the tool window to reflect the state of the currently open solution.

Within WorkingFilesList.ToolWindow, the class responsible for subscribing to these events is the DteEventsSubscriber. In the interest of minimizing class responsibility, DteEventsSubscriber only subscribes to events; it then calls methods on the event relay services ProjectItemsEventsService, WindowEventsService, and SolutionEventsService, passing all event data. It is the responsibility of these service classes to process any of the event data (if necessary) and invoke methods on other classes within WorkingFilesList.ToolWindow. Image 2 illustrates this interaction.

Image 2: The interaction between EnvDTE.DTE and classes within WorkingFilesList.ToolWindow