我们希望将我们已经开发的内部工具变成一个Visual Studio套件，我们将向其他开发人员销售。该工具将影响自定义编辑器和/或自定义语言。 Visual Studio 2010重新设计了API以大大简化这些类型的集成所涉及的大部分工作，但是我们所面临的关键问题是： 新Visual Studio版本的典型采用步骤是什么？基于历史记录的采用率是否有任何信息？有多少商店仍在使用2005年？2005/2008/2010的Visual Studio软件包？
这将帮助我们考虑是使用新API还是仅仅针对2010年，还是试图回过头来支持2008年（也许是2005年）并对其进行测试。
简短的回答：
我会主要针对VS2005（你应该不会有太大麻烦2005年 - 特定加载到2005/2008/2010工作，从而最大限度地提高您的潜在市场）。
较长的答案：
正如你2005年至2008年到2010年移动，它就会逐渐更容易编写的加载项。尤其是，2010年新的可扩展性功能使得构建和部署扩展更容易（2008年使用的较旧的附加组件和包系统对于工作而言更加痛苦）。尽管如此，相当大比例的用户仍然使用2005年（事实上，仍然有很多人使用2003和VS6），但我猜测大多数人现在都在2008年。不要期望特别高的百分比2010年的用户数量至少达到SP1，因为许多公司甚至在它至少已经使用了6个月之后才会看到它，并且任何小问题都会被排除。所以目前如果你想要一个大的市场，我认为你别无选择，只能瞄准2005年和2008年。
作为一般规则，如果你的插件在2005年工作，它很可能在2008年和2010年，所以如果你想要一个大的市场，那么在2005年针对插件是最好的选择。除非您需要2008年的特定功能，否则在大多数地区，2005年和2008年之间几乎没有什么区别，所以我建议您从2005年开始，如果发现问题可能会“除非您使用2008 API，否则很容易解决。这在2010年应该很好，因为它得到了很好的支持，但不能保证未来的Visual Studios将继续支持加载项。
正如你所说，替代方法是放弃旧的“添加”接口并使用新的2010扩展性API。这将使开发变得更容易，获得更多的2010年内部使用权，并且更具前瞻性......但是需要几个月/年才能建立市场规模。
好了，项目越大，时间越长，将采取从2005年转移到2008年和2010年
我知道，仍然在2005年很多项目，所以，如果你能负担得起 - 做一个2005年版，2008年和2010年。大型项目通常有资金购买员工...
如果您只能负担一个版本的产品，转到2010年，从长远来看......这是最好的选择。
（2010年将开始在几天/周内获得市场份额，如果您可以在不到6个月的时间内提供该产品，那么您应该首先针对旧版本，因为它们将再次统治市场至少一年）。