Having great samples to help you learn about any programming language or paradigm can be very valuable. In my opinion, a good sample can be characterized by:

Being easy to replicate

Having clear steps that guide the reader to replicating the behavior of the sample into their own code base is paramount. Without clear guidance and explanation on how to consume the sample, the sample is much less efficient and may lead to the reader becoming annoyed.

Being self-contained

The sample needs to contain the needed documentation, code comments and simplicity that makes it easy to understand. It must keep the concept count to a minimum to reduce noise.

Linking to additional resources

A sample is not a replacement for full documentation but shows how to implement concepts that can pan multiple sets of documentation. If the reader is interested in knowing more details about the various technologies and concepts used by the sample, links must be made available.

Being able to build and run

It should be possible to clone the sample to your machine, open it in Visual Studio and being able to run and debug effortlessly. Setting breakpoints and inspecting the code is a fantastic way to help understand how the sample works.

New samples

The Visual Studio extensibility team has a notable set of samples for various different aspects of writing extensions. However, they do not adhere to the rules outlined above and we are looking into updating them accordingly and adding new ones as well.

So, we’ve created some experimental samples on GitHub that addresses some pain points we’ve noticed over the years. They are:

1. Doing options the right way - This sample shows how to correctly specify and consume options for a Visual Studio extension that is both thread-safe and performant.
2. VisibilityConstraints - This sample shows how to use the <VisibilityConstraints> element in a Visual Studio extension to remove the need to use the ProvideAutoload attribute on a package class.
3. Protocol Handlers - This sample shows how to associate a URI protocol with Visual Studio and handle the passed in URI. For instance, a link with a custom protocol (such as vsph://anything/I/want) will open Visual Studio and pass the URI to the extension.
4. Textmate Grammar - This is a sample project that demonstrates how to ship Textmate grammars inside Visual Studio extensions.

Give us feedback

Please help give us feedback on these new types of samples by either commenting on this blog post or, even better, opening issues directly on the samples on GitHub. The more feedback we get, the better the samples get, and we can start writing lots more of them.

Also, what scenarios should the next batch of Visual Studio extensibility samples address?

In an episode of .NET Rocks from December 2016 I declared that Web Essentials would not be carried forward to Visual Studio 2017 and beyond. I’ve decided that was a bad idea, released a version for Visual Studio 2017 and here’s why.

Since Web Essentials was first released for Visual Studio 2010 it has grown and grown in both features and complexity. While providing a lot of functionality it became somewhat of a monolith to maintain. The size of the project was enormous and that probably was one of the main reasons only very few people helped out by sending pull requests. Another problem was that when a bug would crash Visual Studio in a feature you never used, you had to uninstall the entire extension instead of just the part that crashed. That was very frustrating for the affected users.

About a year and a half ago, I started on splitting all the features out into their own smaller extensions. The goal was to break up Web Essentials into smaller chunks that would be easier to maintain, have better test coverage, be very targeted and – most importantly – optional. That goal has been achieved and I’ve already seen the benefits in terms of more community involvement and higher quality. I get a lot more pull requests to the individual extensions than I ever did with Web Essentials and I’ve even made people contributors to several of the projects that they have shown a vested interest in. Success!

The process of splitting out Web Essentials into smaller extensions have taken more than 18 months and is now finally done.

Web Extension Pack –> Web Essentials

Having 20+ extensions instead of one presents a new challenge. How to make sure that Web Essentials users could find and easily install all those extensions. Enter Web Extension Pack 2015. It is a meta extension that does nothing but install all the new extensions. It was a great way to just point people to a single extension that would take care of adding all the features relevant to web developers.

Now that I’m done separating all of Web Essentials into smaller features, it felt like Web Extension Pack was pretty much the same thing Web Essentials used to be. Namely a single download that would add a bunch of helpful web development related features.

So I had a few options. Either keep the name “Web Extension Pack” and forever lose the good name and brand “Web Essentials”, or rename the Web Extension Pack extension to Web Essentials. I’ve chosen to rename in order to keep the brand, logo and generally positive associations people have with the name “Web Essentials”.

Web Essentials lives on, but with smaller optional pieces, higher quality, more focused functionality, more community involvement, simpler code bases, and a lot more fun for me personally to maintain.

Web Essentials 2017

I just updated Web Extension Pack 2017 with the renaming and branding change to make it Web Essentials 2017. The brand and logo is alive again and hopefully for many years to come.

Thanks to everyone who ever downloaded Web Essentials or any other of the smaller extensions, left comments, ratings, opened issues and sent pull requests. Keep the feedback coming.