Visual Studio 2005 = "Whidbey"

Article
03/13/2004

I'm probably the last person to blog about this, but in case you didn't know, Whidbey will officially be Visual Studio 2005.

Date Slip
I wanted to take a second to respond to Frans Bouma and other bloggers who are “hooked“ on Whidbey and want to know why they can't have Whidbey now. Yes, the next release of Visual Studio will be a major release with lots of features that developers have been asking for and it will make your life easier. The problem is that you've only seen a partial view of what's coming down the road. The version of Visual Studio “Whidbey“ that was given to attendees at PDC was a technology preview. It is not feature complete. I think you can only really start to understand the scope of everything that Microsoft will be offering in Visual Studio 2005 by Beta 1. Until then, your basically looking at a car in an assembly line saying how you need the comfortable seat now, but we haven't welded doors on the car yet, we haven't done safety tests, and there's no turbo fuel injection (PS: you'll love the sunroof). To the specific point about Yukon delaying Visual Studio, I can assure you that the developer division isn't just sitting around waiting for Yukon to be ready, there is plenty of work to do, I just can't tell you about it until Beta 1 :)

I may be pointing out the obvious here, but I think that it's hard to judge timeframes for very large software projects and Microsoft doesn't do the best job at it. Features change and evolve, as do requirements, interdependencies, performance criteria, and much more. We have lots of smart people doing their best to manage this and we don't always make the exact software deadline. To give another recent example, Windows Server 2003 had around five different ship dates and about the same number of name changes. I'll do my best on keeping the name changes minimal:)

Go Live license?
If you are interested in deploying Whidbey pre-launch, I can't say for certain, but we might redo the Go Live license system that we did with the VS 2002 launch. I don't know the details on this (if any 'softie does, please reply), but when I do find out, I'll make sure to blog it.

Visual Studio Service Packs
WRT your point about why there have been no service packs for VS, first realize that we have several hotfixes up at https://support.microsoft.com if you have a particular problem to address, feel free to contact me directly. I think you should understand the context of what's going inside Microsoft as there has been a lot of work in making Windows XP Service Pack 2 a great service pack with a focus on security. As you can imagine, there are obviously lots of tie-ins and dependencies on the work being done in this service pack that would affect the developer division. You can read all about the developer implications of Windows XP SP2 here. I don't work on the Visual Studio servicing side (anyone who does chime in here), so I'm just giving you an educated guess here, but since there are specific developer implications for Windows XP SP2, the VS team would need to factor/depend on those changes for any future Visual Studio service packs.

Does Microsoft Give Access too Early?
After reading these posts on Whidbey and in thinking about the backlash on Longhorn (too much info too early), it occured to me that maybe its not such a good idea to give the broad developer community early access to code. I'm not saying this because we don't value everyone's opinion, but because it might be dangerous to set such high expectations. What happens when you see a great feature and you see that it won't be available until the next release? Some features you like may or may not make Whidbey, it's a technical preview, we really cannot give any guarantee as to what the final product will look like. As Jay points out, we're even starting to give developers interim builds in a continuous effort to make Microsoft more open to developers. I would assume this would be a good thing, but there is risk in this approach. The risk is that we over-promise and under-deliver which leads to developers being angry, which is the exact opposite of what we're trying to achieve. For example, Beta 1 of the original PDC builds of what became Visual Studio.NET 2002 had E&C support for VB, but due to the amount of work required to get it right, it didn't make VS '02 or '03 and is only now being be added to Whidbey. Maybe the other problem is schedule expectations. We announce software ship dates, and then have to change them, potentially multiple times. If we hadn't specifically said that Whidbey would be released at the end of 2004, would that have been better? I don't know the right answer to this, but if you have feedback, let me know.

Comments

Anonymous
March 12, 2004
I'm convinced that to ship things more often in smaller chunks is the solution.

Of course, the biz guys (both at Microsoft and the customers) might disagree with me!
Anonymous
March 12, 2004
The comment has been removed
Anonymous
March 12, 2004
"WRT your point about why there have been no service packs for VS, first realize that we have several hotfixes up at http://support.microsoft.com if you have a particular problem to address, feel free to contact me directly. "
This is absolutely bogus. Here's why:
Say there is a bug (I found at least 10 in .NET 1.1) which I need fixing for my own software to work correctly. Am I helped with a fix from PSS? NO! My own install perhaps works, but my customers who will use my software have to call PSS as well!

An ISV can't rely on that: "To get this piece of software working, you first have to call Microsoft for a fix". Most customers don't want to install hotfixes, they want service packs.

That's why a hotfix is nice for an internal application, however for ISV's it's absolutely nonsense: they can't ship the software with the patch, the customers have to call MS themselves.

I appreciate the time you want to take to fix bugs or communicate between developer and MS developer but please realize that hotfixes are unusable for ISV's. Support like this is not to be called support. Sorry that I might sound a little annoyed but I truly am annoyed about this issue. I'm getting pretty tired of all the blabla coming from MS about that there is no issue with support, that customers get the best support possible etc. while a massive amount of developers complaints about this day in day out (read the newsgroups f.e.).

So, please please PLEASE realize what the pains of the developer community are TODAY so address them a.s.a.p.

" You can read all about the developer implications of Windows XP SP2 here. I don't work on the Visual Studio servicing side (anyone who does chime in here), so I'm just giving you an educated guess here, but since there are specific developer implications for Windows XP SP2, the VS team would need to factor/depend on those changes for any future Visual Studio service packs."
This is pure CoverYourAss.exe, sorry. It's not my nor anyone elses problem that the design of Visual Studio relies on Windows XP's structure and changes on WindowsXP apparently change behaviour of Visual Studio.NET. Furthermore, VS.NET and .NET 1.1 are released in April 2003. That's almost a year ago. Are you trying to sell me the idea that in that year all bugfixing effort has been put on hold because of an XP service pack coming later this year? I hope not :)

A lot of bugs are already fixed, for a LONG time (hotfixes are available if you call PSS, but not for the public), however not released to the public.

What's wrong with: release the fixes NOW and release another fix for XP SP2 when it arrives? Why o why do we have to wait till Q4 2004 before any fix for vs.net 2003 or .nET 1.1 are released?

Let me take a wild guess: fixing stuff costs money and time. Putting developers on those fixes NOW is not productive because they can better work on whidbey as it is behind schedule as it seems.

Understandable, but again, not the problem of the customer. THe customer (the developer using VS.NET and .NET 1.1, you know, the people who do the hard work for Microsoft to get .NET accepted in the real world) payed for software and wants support, because he has every right for support.

I know that this rant will not make any difference, but so be it, at least some people now know the other side of the story.
Anonymous
March 12, 2004
WRT your point about not convincing you about Whidbey delays - Okay, you win, I can't convince you if you say so. Let's talk around beta 1 and I think you'll get an understanding about what I'm talking about though :)

WRT releases, I think its a good idea to do more often, but would you really want a smaller release that has less features? We released VS 2003 one year after VS 2002 and we didn't exactly receive the best reception from developers who were already writing code with 2002. There were articles questioning the value of upgrading and whether it was really worth it. To play devil's advocate a bit, imagine a scenario where you need to install 4-5 different versions of the .NET framework on your machine and you needed to remember which version generics was implemented in and if that version of the framework isn't installed, then install it. I'm not a versioning wonk but it just seems like it could get ugly based on Java's experience. There are still customers using JDK 1.1.4....Also, would you really want to install and uninstall VS multiple times? Or pay $600-800 multiple times a year (assuming you're not using an MSDN subscription)? Like I pointed out in my post, we are starting to release multiple builds and I think that's a good thing, but as Jay points out, they aren't necessarily the most stable builds.

We've also tried to make code as accessible as possible. For C#, we had a release of generics from research (gyro) publicly available for use with Rotor since May 2003. There are customers that have decided to start using Whidbey bits for their applications today. We're not stopping them, we simply can't support them unless they are in an early adopter program.

WRT support - It sounds like you're mainly talking about Visual Studio the tool, correct? I totally agree with you that customers want bugfixes. I don't work in support so I can't give you any definitive answers, but I went to support.microsoft.com and searched for "hotfix visual studio" and found several references to bug fixes that are available from PSS for VS 2003. I don't know what specific issues you are having so I can't answer definitively, but if you want, contact me offline (danielfe-at-microsoft.com). Aside - For enterprises that need rock-solid support, one option to consider may be our Premier level of support: http://support.microsoft.com/default.aspx?scid=fh;[ln];entpremier
You will literally have an MS employee who's sole responsiblity it is to make sure you are up and running.

From a bug feedback perspective, I'll try and say this in a way that doesn't result in disclosure issues, but we are actively looking at ways for developers to give us better feedback and for them to be able to rank in importance feature requests, bug fixes and more. If you have any specific suggestions for how we can fix support, let me know.
Anonymous
March 12, 2004
The comment has been removed
Anonymous
March 12, 2004
The comment has been removed
Anonymous
March 12, 2004
"There are still customers using JDK 1.1.4"

Isn't that largely due to the fact that it is the only one readily available? (Either in J++ or Internet Explorer) Make it easy to target higher versions of the framework and for end-users to upgrade, and developers will have no qualms about using higher versions.
Anonymous
March 12, 2004
"Also, would you really want to install and uninstall VS multiple times? Or pay $600-800 multiple times a year (assuming you're not using an MSDN subscription)?"

Install/Uninstall... If it's done right, it won't be that big of an issue.

Money: Isn't that what Software Assurance and/or MSDN is for? If I could point to the fact that there will be multiple upgrades, I'm sure it would be an easy sell. MSDN isn't much more than the price of VS.NET anyway.
Anonymous
March 13, 2004
You don't have to put out a new version of the framework with each release of Visual Studio.

You could release a new version of visual studio with enhancements on the IDE side, such as the refactoring and edit-and-continue support that's being talked about. Then in a later version, release the framework with generics and stuff.

That way you can give more frequent releases of visual studio, without having to over-version the framework.

Another option is to not make everything part of the framework. Sure, generics is a special case, and it has to go in the core. But lots of new functionality could be released as optional libraries that developers can just install with their products as needed, rather than being tied to a particular version of the framework.

You could do several library releases in between framework releases, before rolling them all into the next release of the framework. This way, you could provide new functionality very frequently without having to release the framework often at all.

Frankly I'm a bit disturbed about the framework-centric thought process surrounding .NET. The core language and libraries should hopefully be approaching stability, given that the third release is in planning. Surely lots of stuff can be built on top of it that doesn't need framework changes.
Anonymous
March 13, 2004
The comment has been removed
Anonymous
March 13, 2004
You know, I just want one thing fixed in VS.NET 2003 if I have to wait for Whidbey. I wish that changing from html view to design view and back to html view wouldn't destroy all the careful formatting I worked so diligently to do. I mean, don't you think it's a little strange to tout the fact that whidbey doesn't mess up your code, as a feature? I would love to be able to switch to design view to double click a button to help me build events quicker, but doing so requires me to make a copy of my html code so I can replace the broken code that changing to design view creates. Doesn't that sound like a bug? Shouldn't developers who use VS.NET 2003 expect that bug to be fixed? Is that too much to ask?
Anonymous
March 13, 2004
The comment has been removed
Anonymous
March 13, 2004
WRT to Chris's comments on JDK 1.1.4 - I can't comment on why we don't release future versions of the JDK. We have a web site dedicated to this at, and I copy/pasted relevant text below:
http://www.microsoft.com/mscorp/java/faq.asp

Q:Why is Microsoft discontinuing support for the MSJVM?
A:This change is the result of a settlement agreement reached in January 2001 that resolved a legal dispute with Sun Microsystems. After September 30, 2004, Microsoft will no longer be authorized to support the MSJVM.

Why are customers still using this functionality? I don't know why everyone hasn't upgraded, but for some, there is legacy code using specific functions that were available in 1.1.4 like WFC classes (ex using java to view or change registry settings). We are actively trying to get people to remove their dependencies from MSJVM...

WRT to MSDN subscriptions, I agree with you that it should be the way for developers to get tools.
Anonymous
March 13, 2004
To Chad, yes I hear you and I've felt your pain firsthand. Your point is totally reasonable...Even ScottGu in his PDC ASP.NET Overview talk says that not mangling html is sort of a bug fix feature -

send me your email address, mine is danielfe - at - microsoft.com and I'll get you hooked up with the ASP.NET team.
Anonymous
March 13, 2004
The comment has been removed
Anonymous
March 13, 2004
/
If you guys have same betaplace.com plan for Whidbey Betas, I asked for wish-list during VS2002 beta, and asking it again here
/

Other than having a public bugs-database, there can be a public wish-list (with votes per wish option), so you guys can have list of most wanted features in the next release.

BTW, is there any for Whidbey? I do have quite a number of ideas :)
Anonymous
March 13, 2004
Khurram,

Great idea, like I said, we're investigating, stay tuned :)
Anonymous
March 13, 2004
WRT releasing multiple versions of specific APIs - I don't work for the data team, so I'll just give you my personal opinion here

MS has released multiple versions of specific APIs before, one example being MDAC, and frankly as a developer outside of MS, I didn't like the work this ended up creating. There are several versions of MDAC flying around and it made developers life a lot harder to understand the implications for servicing, features, etc. I couldn't imagine having to develop software and understand how multiple versions of WinForms, ASP.NET, ADO.NET, Collections, regular expressions, file IO, and if they could all work together.

Just to see if I was the only one that had trouble with multiple mdac versions, I did a quick search on Google Groups for "multiple mdac" and found 2K+ results, several from frustrated customers that have to manage and test multiple versions.
http://groups.google.com/groups?q=multiple+mdac
Anonymous
March 13, 2004
So there's obviously been a TON of blogging in the last week over Microsoft's decision to delay Whidbey until 2005. Dan...
Anonymous
March 13, 2004
The thing I'm MOST looking forward to is having an HTML editor that doesn't constantly mangle my HTML. If Microsoft is claiming to save developers time by using .NET framework, then release a patch to save me the hours I spend each week fixing the HTML that the editor mangles. If we can't have the full blown Whidbey, how about a patch for Visual Studio 2003 that simply makes it not mangle my HTML?? Can we at least have THAT before the year 2005? (Exactly what was the purpose of that "Check for Updates" help menu item in Visual Studio, anyway? To let us know when Whidbey was ready to buy?)
Anonymous
March 13, 2004
Is there any possibility that the .NET Compact Framework v 2 could be released before Visual Studio 2005 ('cos we really really need it, honest!)?
Not having tool support for it wouldn't necessarily be a killer (After all, SP 2 isn't really supported by the designer by default, and that's not the end of the world).
Anonymous
March 13, 2004
"I asked you to contact me directly if you had a specific problem and I told you I would try and help. I still haven't received email from you on what specific issues you have. Help me help you :) I can't promise anything, but I'll try my best... "
Dan, first I'm sorry that I might have made you 'the messenger' but you were the ONLY ONE from MS who has said anything about this in public.

I find it very generous of you to help out with bugs, but as I tried to explain, I can't use hotfixes because my customers can't download them.

Furthermore, about the amount of servicepacks: bugs need fixes, and NO servicepacks and thus NO PUBLIC available bugfixes is bad, very very bad. Frankly I don't care if some person tries to make his job more easier so less service packs should be released. I really can't understand why someone actually would say that: "I want less service packs".. oh, so they want to keep the bugs in the OS? Apparently. So because some lazy people wine about TOO MANY service packs, there are no service packs released at all for .NET? :) Come on, Dan... :) But I forgive you, you don't work at support so it's not your call. I just want to illustrate that what MS thinks is right, isn't. It hurts productivity.

In 2002 I reported that the precision property in SqlParameter is hardcoded limited to 38. If I want to set the precision for a float parameter for SqlServer which has a precision of 53, I can't. It's still in the framework. My generic code which generates parameter objects on the fly has now workaround code which caps the precision of types to 38. I don't want that kind of code in my software but I have to, MS is simply not fixing it. As an answer I got: "It's not a bug, if you set the type to SqlDbTypes.Float, it will use 53 automatically". (I got this answer in the newsgroups after re-posting this issue) Oh? And what happened to generic code which wants to create parameter objects?

It's a small example of how MS looks at things and how developers look at things. These definitely don't match.

I gave you a list in a posting above what I think should change. YOu asked for such a list and I gave you one. I hope you can pass it on to someone who is responsible for this and can make a difference.

Thanks.
Anonymous
March 13, 2004
"To Chad, yes I hear you and I've felt your pain firsthand. Your point is totally reasonable...Even ScottGu in his PDC ASP.NET Overview talk says that not mangling html is sort of a bug fix feature -

send me your email address, mine is danielfe - at - microsoft.com and I'll get you hooked up with the ASP.NET team."
MS already confirmed this is not fixable in current vs.net versions.
See: http://weblogs.asp.net/fbouma/archive/2003/05/15/7051.aspx
Anonymous
March 13, 2004
The comment has been removed
Anonymous
March 14, 2004
The comment has been removed
Anonymous
March 14, 2004
Dan, doesn't .NET's Side-by-Side versioning make your point about multiple versions of ADO.NET go away? Wouldn't you be able to bootstrap the version you need, check for it on installation and install if they have a different version? Wouldn't this prevent the problem you list above? Isn't that what we've been told for the last 2-3 years?
Anonymous
March 14, 2004
The comment has been removed
Anonymous
March 14, 2004
One last thing Shannon that wasn't clear in your response, are you asking for separate versions of all APIs?
Anonymous
March 14, 2004
The comment has been removed
Anonymous
March 14, 2004
It is interesting to see the different points of view placed here and I agree with some of them, one thing that sticks in my mind though as I read through is the release often mentality. I agree that when a cool new feature is offered in a product I would like to have it right away, however, with .net comes a whole new dilema. With each version comes a whole new framework and along with that comes a whole new investment requirement. No sooner have we gotten to grips with one version, we are then preparing for the next. I understand the need for updating the Framework but I would say a major update every 2 years with patches and minor updates available inbetween would be a better idea. Give us a chance to get our money's worth out of our current investment is all I ask.
Whideby being delayed till 2005 is great for my investment and current development, but do keep the patches coming.
Anonymous
March 15, 2004
Great thread - covers a lot of ground. A few specific comments:
- re: VS and XP being too tightly coupled - this isn't really true. The issue is that XP SP2 is making some significant security enhancements, and there are a couple places where that hits VS and the .NET Framework. The statement (way) up above that we don't really know all the impacts until XP SP2 ships is accurate, but as someone says, that doesn't preclude us from shipping a VS service pack now and another later.
- my personal view on more information/interim builds/etc. is that there will be a few glitches along the way (e.g. features that are seen once but then deferred until a future release) but that those glitches will be more than offset by people seeing the process, understanding direction, and having more ability to affect what happens along the way. Also, if we do it right, those features that get cut will have been cut because customers told us it was more important to ship than get that feature in.
- regarding VS service packs, someone above got it right - they are very expensive for us, i.e. the overhead of a service pack release is close to the same for a full release. That's not necessarily how it should be, and I'm not saying that we're making the right tradeoff in doing them very infrequently. We have a customer/community review with our VP in a couple weeks, and I'll bring this topic/thread up there.
Anonymous
March 15, 2004
The comment has been removed
Anonymous
March 16, 2004
http://www.microsoft.com/windowsserver2003/64bit/extended/trial/appcompat.mspx
describes Windows 2003 64 bit application compatibility. It explicitly states that managed code will not run on Win2003 64 bit until Whidby is available (i.e. the 32 bit CLR won't run). Is this still going to be the case?

We were hoping to begin develop and test on the 64 bit servers very soon, but this limitation will put us back a full 12 months.
Anonymous
March 16, 2004
The comment has been removed
Anonymous
March 16, 2004
Christian - WRT to code editors, I can't comment definitively (I don't work for the ASP.NET team), but Frans did say in other comments this wasn't possible:

[FBouma]
MS already confirmed this is not fixable in current vs.net versions.
See: http://weblogs.asp.net/fbouma/archive/2003/05/15/7051.aspx

WRT XHTML compliance, again I don't know, I'm not an expert in XHTML, but maybe this ebook on Enforcing XHTML Compliance in ASP.NET Applications would help (although the review didn't seem promising)
http://www.amazon.com/exec/obidos/tg/detail/-/B00006L8GV/102-0441150-8975308?v=glance#product-details
Anonymous
March 22, 2004
Great thread - I've written a long reply/open letter on the subject: http://dotnetjunkies.com/WebLog/mlevison/archive/2004/03/22/9735.aspx
Anonymous
March 22, 2004
The comment has been removed
Anonymous
March 23, 2004
Dan - how do we get the decision makers to read about the various reactions to the delay of Whidbey and give us some feedback. One of the frustrating things about working with MS is that the lack of a clear feedback loop. We make requests and they seem to go off into the ether. I've made several major batches of suggestions in the past two years to a couple of PM's (modified versions of my suggestions are in my blog). In both cases - the reaction "Great ideas" - but nothing has ever come of them. Even if the only reaction was "Not feasible anytime soon" - at least I would know I've been given real consideration.

Thanks for listening to my rant.
Anonymous
March 23, 2004
Mark - Good point, you aren't alone here....we are working on addressing this issue, stay tuned.
Anonymous
March 23, 2004
Hello all

I have read that in concert with Bill Gates speech tomorrow they will be releasing an updated release of Visual Studio 2005. I am wondering if anyone knows how somone who didnt go to the conference in San Fransisco can get a hold of one??? I am very excited to work with some of the feature in ASP.NET 2.0. Please email me if you know anything mackenziemi@skymailint.com

Thanks
MacKenzie
Anonymous
March 23, 2004
MacKenzie, good question, I recently blogged about the VSLive launch announcement and responded to the question about how someone else can get it in my comments -
http://blogs.msdn.com/danielfe/archive/2004/03/23/94622.aspx#94697
Anonymous
March 23, 2004
Thanks Dan you ROCK!!!
Anonymous
March 24, 2004
The comment has been removed
Anonymous
March 29, 2004
To Stephen who wanted to know whether Exhange was the reason for Yukon's delay, here's the response I received from Exchange:
No, this is not true, the Exchange team is committed to providing the best technology possible to our customers and, as we've said in the past, remain committed to using SQL in the next generation of the product.

Hope this helps,
-Dan
Anonymous
April 04, 2004
The comment has been removed
Anonymous
April 05, 2004
The comment has been removed
Anonymous
April 19, 2004
I don't know why there arew so much complains about VS.net...surely it has some bugs.....but anyway I like it and it's the best IDE I have been using so far...just a thought btw. Though I'm also a bit dissappointed that whidbey won't be released before 2005.....but anyway....I'm looking forward to these new features coming with it.
Anonymous
May 06, 2004
Eclipse?

4 out of 5 dentists who have used IDEA or even JBuilder recommend these targeted environments over Eclipse, which not only causes cavities, but will never (given the past trending of things) have the fully integrated and intuitive features of an IDE built to accomplish end-to-end development.

Just IMHO :)

Personally I'm so thrilled with ReSharper (jetbrains.net) which in beta already adds refactoring, auto importing, auto code-correction, and dynamic full error support - woohoo!
Anonymous
June 29, 2004
[ via <a href="http://del.icio.us">del.icio.us</a> ] <a href="http://lab.msdn.microsoft.com/express/">Microsoft
has made betas of "Express" versions of its programming languages/IDEs</a>;
these will appear in their final form in Visual Studio 2005. 
 <a href="http://weblogs.asp.net/danielfe/">
Dan Fernandez</a>, Visual C# Product Manager, <a href="http://weblogs.asp.net/danielfe/archive/2004/06/29/168417.aspx">writes</a>: 
As I had <a href="http://blogs.msdn.com/danielfe/archive/2004/03/13/89006.aspx">blogged before</a>, you finally get to see the big picture ...
Anonymous
April 12, 2005
I think that early access model helps Microsoft in future release marketing with no significant exceptions. As for developers and their interest to VS, they would be participated in Visual Studio anyway as they don't have a real alternative to it.

Does Microsoft gives access too early? - No. It is very important for any developer to manage his expectations as well as to make forecasts.
Anonymous
October 10, 2005
Although there hasn't been a large amount activity in this blog post for awhile, I thought I'd take the opportunity to post anyway. This post is commonly linked to in other blog postings upset about the state of servicing and service packs in Visual Studio.

I work on a team that is tackling this very issue inside of DevDiv. We are known as DDCPX, and a large number of us are devoted to improving the servicing picture around Visual Studio. If you are interested in talking with us, or simply learning more, please check out the URL posted above--it's a new blog we've formed that we'd like to become a two-way conduit between us and the community.
Anonymous
October 23, 2005
I had a first look at visual studio 2005 at MSDN day here are my views of it.
http://sanjaykattimani.blogspot.com/2005/10/visual-studio-2005-first-look-at-msdn.html

Partager via

Visual Studio 2005 = "Whidbey"

Comments

Ressources supplémentaires