A while back, a colleague of mine brought the concept of ADRs to my attention. The idea being that, when you make a decision on a project, you write it down, but you do so inside the code base, and check it into the source control system.
Even in the days when people believed writing long functional specifications was a good idea, having documentation that married up to the code it documented was a distant dream. Typically, you’d spend about a week writing a spec, and the minute you wrote the first line of code, the document was, essentially, considered dead (and only ever referred back to where the customer disputed what had been delivered).
Since I’ve never written a Visual Studio Extension, but always thought it would be a cool idea, I had an idea to start with this. My thought was that I could build something that would extract the ADRs from the main codebase. This isn’t one of those posts where I have a completed solution, and I’m just documenting it… it’s more of an ongoing journey… which may result in the conclusion that this either doesn’t make sense, isn’t feasible, or has already been done.
I’m going to upload the progress so far to this GitHub repo.
In this first post, we’ll create an extension capable of viewing the project it’s in.
Step 1 - Install the SDK
To do any extension development, you need to install the SDK - you can do this through the Visual Studio Installer:
Step 2 - Create a new (VSIX) project
VS Extensions are referred to as VSIX, because that’s the extension of the deployable product.
Step 3 - Add a new Tool Window and Test
Add a new Item (right click project -> add new item), and select the Tool Window:
There is no need to do any plumbing here - any eligible extension types in the solution will be compiled and used - try pressing F5 now. You should get a version of Visual Studio to debug:
As you can see, I’ve been here before. For the purposes of testing, I’ve set-up a convoluted project:
The reason for this will become clear shortly, for now, just launch the tool window that you created (View -> Other Windows -> Tool Window 1 (or whatever you called it):
Step 4 - Add some code to the Tool Window
For the purpose of this first stage, we’ll just analyse the project structure. When it’s finished, I’d like it to be able to identify the ADR docs based on a configurable location but, for now, let’s just show how many projects and files we have. For now, we won’t change anything, let’s just hook into the button click of the subtle button in the screenshot above:
private async void button1\_Click(object sender, RoutedEventArgs e)
{
await ThreadHelper.JoinableTaskFactory.SwitchToMainThreadAsync();
var dte = (DTE)Package.GetGlobalService(typeof(DTE));
var sln = Microsoft.Build.Construction.SolutionFile.Parse(dte.Solution.FullName);
projectsText.Text = $"{sln.ProjectsInOrder.Count.ToString()} projects";
foreach (Project p in dte.Solution.Projects)
{
projectsText.Text += $"{Environment.NewLine} {p.Name} {p.ProjectItems.Count}";
}
}
SwitchToMainThreadAsync is because any interaction with the solution needs to be on the main thread. After that, we parse the solution file and output the name and items in each “project”:
As you can see, it classes each top level folder as a solution project, which will be ideal for us.
Summary
In this post, we’ve seen how to create a Visual Studio Extension, and how to trawl the current solution and projects. In the next post, we’ll try to extract some ADR specific stuff.
References
https://msdn.microsoft.com/en-us/library/ms973240.aspx?f=255&MSPPError=-2147217396