Tutorial Table of Contents: Part 1: Introduction to VS extensibility Part 2: Add Menu Item Part 3: Add command to context menu and get selected code Part 5: Highlight code in Editor part 6: Follow a span of code with TrackingSpan Part 7: Insert buttons between text characters with Adornments Part 8: Add UI in the indicator margin with Glyphs During the tutorial we are going to build a VS extensions called CodyDocs and place it on GitHub .

In part 2 of the tutorial we created a simple VS extension with a single Menu item. The extension will eventually be able to add code documentation in a separate file (.cs.cdocs) and view it in a nice Heads-Up display. The tutorial explains every step of the way to build such an extension. For starters, we need the ability to select a piece of code and add documentation, which is what we’ll be doing here.

The previous blog post introduced the wonderful world of Visual Studio extensions. Let’s start and do some coding. During the tutorial we are going to build a VS extensions called CodyDocs and place it on [GitHub](https://github.com/michaelscodingspot/CodyDocs). CodyDocs will save code documentation in a separate file and the extension will allow to view and edit the documentation in the editor itself. In the first part, we’ll start with a simple “Hello World” program.

Ever used Resharper , CodeMaid , WebEssentials , OzCode or CodeRush ? Those are pretty incredible tools, right? Ever thought about developing an extensions for yourself and your team? Maybe a little something that edits the very difficult configuration files your company invented? Or how about an extensions that automatically performs a localization merge? There are a lot of advantages to in-house VS extensions and some big companies even have a dedicated team to work on in-house VS extensions.

In my previous company, we experienced a reoccurring nightmare. It went something like this: New critical bug arrived from QA: Program suddenly crashed. Reproduces 1 / 10 times. Reproduce steps – unclear. The development team, after realizing they are unable to reproduce the bug on their development machine would claim the bug doesn’t reproduce, moving the ticket back to QA. In return, the QA team reproduced the bug, moving the ticket back to dev.

Did you ever feel like Visual Studio is rebuilding projects every single time, even when there were no changes to the code? We can build, change nothing, build again and there we go… VS is starting a build instead of saying all my projects are up to date. Also, there’s that nagging feeling that even when we do change something, VS is building way more projects that it needs. Like most things I do in life, frustration led me to look further into this matter.