I knew it privately but I have realized today that it is public (from a Microsoft source):
TAP is the Technical Adoption Program (TAP) and VSIP is the Visual Studio Industry Partner Program (VSIP).
Given the really horrible / bad / unusable / state of the automation / commandbars model for add-ins in public VS 2010 Beta 2, it is a pity that there isn’t a public Beta 3 available to everybody so that:
– All developers of add-ins (not just those invited to TAP of paying the fee of VSIP) can test that the reported bugs about VS 2010 Beta 2 extensibility are fixed without praying or crossing fingers waiting for the RTM.
– Better yet, consumers of their add-ins can test the add-ins for them also in real life. It is interesting that Microsoft itself is going to suffer the same problem of a lack of a public Beta 3 or RC to verify that their internal fixes / tests actually solve the performance problems of VS 2010 Beta 2 in real scenarios …
Since the bar for bugs to pass the triage and get fixed becomes higher and higher as Visual Studio reaches Release Candidate status. I don’t even think that a public Release Candidate would be of any benefit for developers of add-ins, since bugs discovered and reported at that point wouldn’t be fixed unless they are critical (that is, prevent launching the product or affect a large number of users).
In general, given the “application monster” that Visual Studio is becoming (with more and more features each release) and the huge internal changes that Microsoft is doing to migrate it from a native app to a managed app, what is required IMHO is longer cycles, maybe 3 years instead of 2 (as it happens with Windows / Office / SQL Server, etc.), where the beta 2 is “fully feature completed” and then you devote several months to a beta 3 to fix all the bugs, and then you release a product that you know that will work great rather than just being confident without actual external verification. Otherwise you end with things like Windows Vista or, to less extent, like Visual Studio 2005 (with its embarrassing performance problems in real scenarios), products that were fixed in the next releases (Windows 7, Visual Studio 2008).
Carlos, you are making me very worried. We use an AddIn to display our toolbar and things on them. I haven’t played at all with AddIns in VS 2010. I am wondering if they will still be worth the trouble.
We chose add-ins over packages to ease the installation burden. It worked well for a while. Now I am not sure we will still try to be integrated in Visual Studio. Perhaps we need a stand-alone editor.
Frank,
Rest assured that the commandbars of VS 2010 RTM will work fine with add-ins, all the bugs that I have reported will be fixed in builds before RTM. The Visual Studio team responsible for this area is very responsive.
I’m just criticizing Microsoft because the Beta 2 shouldn’t have had all those bugs with commandbars in the first place, and also they should release a public Release Candidate as they do with every other MS product.
But if your add-in just creates a single toolbar with buttons that are added only to that toolbar, that should work fine even in Beta 2. Bugs appear with buttons on more than one commandbar, or with popups, etc.
That’s really bad, given that VS2010 came without adding much to its coding tools (in comparison with Eclipse), being very fast and with few bugs is the least I would expect. It seems to me that Eclipse have pretty short cycles as well, how do they do that…
I’m very disappointed to hear this, though not at all surprised (the same arrogance happened during the VS2005 release – it needed a Beta 3 too, and as result the RTM was decidedly substandard).
As it stands, with VS2010 Beta 2 we effectively can’t create items on the main menu at all, and only get the toolbar working with some very messy bodging.
It seems the VS team hasn’t learnt that much from the VS2005 experience, which is a real shame.
I don’t know Quan but I can say definitively that this is not an official Microsoft communication. I’ve remarked before (on my blog) that when you have an organization of 2,000 – 3,000 people, you have to assume random stuff happens. Said another way “Don’t believe everything you read” 🙂
1) We’ve had an RC on the books from the beginning. We are investigating the possibility of making it a public release. We didn’t originally for that but the Beta 2 feedback has made us rethink it. We will ensure that there is time to incorporate customer feedback. Quan wrote this a while ago and, to be honest, I’m not sure we had reached that conclusion yet.
2) We haven’t decided what we are going to call the public release yet. We’ve discussed both “Release Canddiate” and “Beta 3”. I responded to one comment on this post: http://blogs.msdn.com/b/bharry/archive/2009/12/05/anatomy-of-a-performance-problem.aspx with some thoughts on this. Regardless of what we call it, we will be looking for customer feedback/validation and will allot time to get it before releasing.
3) March 22 is NOT the release date. It never was. March 22 is the marketing launch date. We generally don’t announce RTM dates ahead of time but we do communicate launch dates. Sometimes RTM happens before the launch, sometimes after. I think it’s fair to say that we are targeting an RTM in the general timeframe or we wouldn’t have set the launch date there but there are many considerations that go into launch dates – lining up with other events, hollidays, venue availability, … Further, it would make no sense for us to have set a final RTM date before getting Beta 2 feedback. We always say “we’ll ship the product when it’s ready”.
Am I the official Microsoft spokesman on this topic, well, um, no. However, I will say that I’m in all of the discussions about when we’ll ship, how do we know, what prereleases will we do, etc, etc. And those who do actually own the “official responsibility” know I’m writing about it and are keeping quiet. Maintaining plausable deniability, I think 🙂
If you want to learn more, please visit my blog at http://blogs.msdn.com/bharry. I’m passionate about shipping a great developer tool and partnering with all of you to accomplish it. I’m always listening and open for feedback. Nothing I like more than a productive debate.
Thanks for listening,
Brian
I’m mostly worried about performance in terms of speed and memory usage myself. It quickly piles up in special cases where you want to e.g. run two Visual Studios alongside each other.
Just something as that it seems to be already decided there’ll just be one RC despite the RC feedback is disheartening. Do Microsoft even understand what “RC” means? it’s a build that could just as well be the release, but if it’s not up to par, there’ll be another RC.
Wish and pray the RC will have good performance, indeed.