Custom Visual Studio Extension Feeds

I found this difficult to figure out so I thought I would write something up real quick. I recently created a Visual Studio extension for the team I am currently working with. The extension isn’t generally useful but it is useful for my team, so I didn’t want to deploy it to the public extension gallery. One of the things I wanted to figure out was how to distribute the extension to the people on my team so that they just get automatic updates like every other extension.

It turns out all you have to do is to make the extension available via http then create an ATOM feed for your extensions. I just dropped a static atom.xml file onto a webserver on my backup dev machine and update it manually when I get a new build of the extension and presto! You just give your team the URL and they can configure VS to also look at that URL when searching for extensions.

Here is the structure of the atom XML you need to create in your feed to make it work:

<?xml version="1.0" encoding="utf-8"?>
<feed xmlns="">
  <title type="text"></title>
    <title type="text">Example Extension</title>
    <summary type="text">An example of hosting a VS extension for my team.</summary>
    <content type="application/octet-stream" src="Example.vsix" />
    <Vsix xmlns:xsd="" xmlns:xsi="" xmlns="">
      <References>Visual Studio MPF 11.0\Microsoft.VisualStudio.MPF.11.0\[11.0,);</References>
      <Rating xsi:nil="true" />
      <RatingCount xsi:nil="true" />
      <DownloadCount xsi:nil="true" />

Test Budgeting

I ran across this concept in an internal discussion group a while back and thought it would be worth sharing. Arlo Belshee is the coiner of the phrase as far as I know. The idea is simply that you come up with a threshold of time that you find acceptable for your tests to run in. One which allows you to still maintain a TDD workflow. Below is Arlo’s recommended test budget.
Test Budget
  1. Up to 3 tests that take longer than 2 seconds.
  2. Up to 100 tests that take longer than .02 seconds.
  3. Infinite tests that take less than .02 seconds.
I also think that you should have a ratio of the three, #1 should not comprise more than 1% of your tests and #2 should not be more than 10% of your tests. The idea is that as you’re writing unit tests you need to design your code in such a way so that it is easily testable in order to meet your test budgets. If you’re writing slow tests early you end up hitting a wall and the friction caused by the tests degrades the value proposition of TDD.