2005/2008/2010 的 Visual Studio 软件包？
我们希望将我们开发的内部工具转变为 Visual Studio 包，并将其出售给其他开发人员。该工具将影响自定义编辑器和/或自定义语言。 Visual Studio 2010 大力重新设计了 API，以简化这些类型的集成所涉及的大部分工作，但我们面临的关键问题是： 新 Visual Studio 版本的典型采用速度是多少？是否有任何关于基于历史记录的采用率的信息？有多少商店仍在使用 2005 年？
这将帮助我们考虑是否仅以 2010 年为目标使用新 API，或者是否尝试返回并支持 2008 年（也许是 2005 年）并对其进行测试。
We are looking to turn an internal tool we have developed into a Visual Studio Package that we would sell to other developers. The tool will impact the custom editor and/or custom languages.
Visual Studio 2010 has redesigned the API's heavily to simplify much of the work involved for these types of integration but the key question we have is:
What is the typical adoption pace of new Visual Studio versions? Is there any information out there on adoption rates based on history? How many shops are still using 2005?
This will help us to consider whether to target just 2010 using the new APIs or whether trying to go back and support 2008 (maybe 2005) and testing it forward.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
简短的回答：
我主要针对 VS2005（因为让 2005 特定的加载项在 2005/2008/2010 中工作应该不会有太大麻烦，从而最大化您的潜在市场）。
更长的答案：
随着从 2005 年到 2008 年再到 2010 年，编写插件会变得越来越容易。特别是，2010 年新的可扩展性功能使构建和部署扩展变得更加容易（2005 年和 2008 年使用的旧插件和包系统工作起来要困难得多）。
然而，相当大比例的用户仍然使用 2005（事实上，仍然有很多人使用 2003 和 VS6），但我猜现在大多数人都在使用 2008。不要指望 2010 用户的比例会特别高，直到至少是 SP1，因为很多公司甚至不会看它，直到它已经面世至少 6 个月并且任何初期问题都得到解决。所以目前如果你想要一个大的市场，我认为你别无选择，只能瞄准2005年和2008年。
作为一般规则，如果你的插件在2005年工作，它很可能在2008年和2010年工作得很好，所以瞄准2005年和2008年。如果你想要一个大的市场，2005年的附加产品是最好的选择。除非您需要 2008 年的特定功能，否则在大多数领域 2005 年和 2008 年之间几乎没有什么区别，因此我建议您从 2005 年开始，只有在发现问题无法解决时才跳转到 2008 年。除非使用 2008 API，否则很难解决。这在 2010 年应该可以正常工作，因为它得到了很好的支持，但不能保证未来的 Visual Studio 会继续支持加载项。
正如您所说，另一种选择是放弃旧的“添加”接口并使用新的 2010 年可扩展性 API。这将使开发变得更加容易，能够更多地了解 2010 年的内部情况，并且更加面向未来……但市场规模的形成需要数月/数年的时间。
The short answer:
I'd primarily target VS2005 (as you shouldn't have much trouble getting a 2005-specific add-in to work in 2005/2008/2010 and thus will maximise your potential market).
The longer answer:
As you move from 2005 to 2008 to 2010, it gets progressively easier to write addins. In particular, the new extensibility features in 2010 make it much easier to build and deploy extensions (the older add-in and package systems used in 2005 & 2008 are much more painful to get working).
However, quite a large percentage of users still use 2005 (indeed, there are still a lot of people using 2003 and VS6), but I'd guess that most are now on 2008. Don't expect particularly high percentages of 2010 users until at least SP1, as a lot of companies won't even look at it until it's been out there for at least 6 months and any teething troubles are sorted out. So at present if you want a large market, I think you have no choice but to target 2005 and 2008.
As a general rule, if your add-in works in 2005 it is likely to work well in 2008 and 2010, so targeting the add-in at 2005 is the best bet if you want a large market. Unless there is a specific feature of 2008 that you need, then in most areas there is little difference between 2005 and 2008, so I'd advise you to start by targetting 2005 and only jump up to 2008 if you find a problem that can't easily be solved unless you use the 2008 APIs. This should work fine in 2010 as it's well supported, but there is no guarantee that future Visual Studios will continue to support add-ins.
The alternative, as you say, is to ditch the old "add in" interfaces and use the new 2010 extensibility APIs. This will make development easier, gain much more access to the internals of 2010, and be more future-proof... but it will take months/years for the market size to build.
嗯，项目越大，从 2005 年迁移到 2008 年和 2010 年所需的时间就越多。
我知道很多项目仍停留在 2005 年，所以，如果你能负担得起 - 制作 2005 年版本、2008 年和 2010 年版本。大项目通常有资金购买人员...
如果你只能买得起一个版本的产品，就到2010年，从长远来看...这是最好的选择。
（2010 年将在几天/一周内开始获得市场份额，如果您可以在不到 6 个月的时间内提供产品，您应该首先瞄准旧版本，因为它们将统治市场至少一年）。
Well, the larger the project, the more time it will take to move from 2005 to 2008 and 2010.
I know many projects that are still in 2005, so, if you can afford it - make a 2005 version, 2008 and 2010. Large project usually have funds to buy staff...
If you can afford only one version of the product, goto 2010, in the long term... this is the best option.
(2010 will start getting market share in a few days/week, If you can offer the product in less than 6 months, you should target the older versions first, as they will rule the market for at least one more year).