Finally, on the contrary to what I posted some days ago, Microsoft announced yesterday that there will be a public VS 2010 Release Candidate, and that “the planned final launch date is moved back a few weeks”.

This is good news for developers of add-ins, because:

1) That release will be the first one where the automation model of the WPF-based commandbars will work without the many critical bugs of Beta 2.

2) Developers will be able to release add-ins compatible with VS 2010 RC for the end users to test them.

That said, there will be minor bugs that finally won’t be fixed
even in RTM because the bar to get them fixed is very high already today, but I
think there will be workarounds. I will post about them when the RC is released.

Channel 9 has now the video recordings of the talks that were given at the 2009 Developer Tools Ecosystem Summit:

http://channel9.msdn.com/tags/Development-Tools-Ecosystem-Summit/

I’d suggest to start with the keynote:

VSX100: Visual Studio Extensibility Keynote: Past Present and Future
http://channel9.msdn.com/posts/VSIPMarketing/VSX100-Visual-Studio-Extensibility-Keynote-Past-Present-and-Future/

Brian Harry, Microsoft Technical Fellow and Product Unit Manager for Team Foundation Server (TFS) has commented about my last post “No public VS 2010 Beta 3 or release”. (Brian is making a huge effort in transparency about the performance problems of VS 2010 Beta 2 and the work to get them fixed for RTM)

I reproduce his comments here:

“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 Candidate” and “Beta 3”.  I responded to one comment on this post: http://blogs.msdn.com/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”

It’s great that Microsoft is considering another public release before RTM. I know it would be to validate the performance fixes after Beta 2, not because add-ins are broken in the current Beta 2. I am fortunate enough to get the private Limited CTPs (LCTPs) after Beta 2 but I am under a Non-Disclosure Agreement (NDA) so I can’t blog about their fixes, workarounds or new problems as I did with the public Beta 1 and Beta 2 in the last months to help others, and my new Microsoft Connect bug reports are now private to Microsoft too. But other developers of add-ins would benefit from that public release, and working add-ins could finally be made available to end users for testing before VS 2010 gets RTM. I wouldn’t have any hope of getting fixes in the automation model between that public release and RTM, though.

I knew it privately but I have realized today that it is public (from a Microsoft source):

“There are no plans to release a Beta 3 for Visual Studio 2010. The official release date will be March 22nd. If you (or your company) are part of the TAP or VSIP program, a release candidate will be available in the near future. Dates are still tentative.”

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).

While VS 2010 Beta 2 has still an undesirable number of bugs as I have blogged a lot, Microsoft is putting a lot of effort to fix them. This one was fixed today (for the RTM release):

VS 2010 Beta 2 Bug: EnvDTE.WindowEvents.WindowActivated event not fired for window getting the focus after closing other window
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=515234

More than a year ago I wrote a popular post:

.NET Frameworks, CLRs and Visual Studio add-ins
https://www.visualstudioextensibility.com/2008/11/14/net-frameworks-clrs-and-visual-studio-add-ins

I stated that VS 2010 would install .NET Framework 2.0, 3.0 and 3.5 (all of them based on CLR 2.0) and, of course, .NET Framework 4.0 (based on CLR 4.0). You may have noticed in the betas of VS 2010 that .NET Framework 2.0, 3.0 and 3.5 are not installed by default, you have to download and install them separately for VS 2010 to use them in projects. So, I have updated the post.

BTW, in the December 2009 issue of MSDN Magazine there is a good article about loading multiple CLRs in the same process

In-Process Side-by-Side
http://msdn.microsoft.com/en-us/magazine/ee819091.aspx