Visual Studio 2005 = “Whidbey”



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 http://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 (57)

  1. Shane King says:

    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!

  2. Frans Bouma says:

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

    I wasn’t blogging about the fact I want it now :) I blogged about the absurd reasoning behind the ‘ship them together (yukon and whidbey) because customers want that’.

    Ship whidbey when it is done and ship yukon when it is done. It’s a public known fact that Yukon has slipping release dates since early last year. Whidbey on the other hand hasn’t. You can’t convince me with that whidbey is holding back Yukon or that they’re on ‘the same release track’.

    I second Shane’s comment, release more often. Open Source does that, some other companies do that too, like mine. My experience is that customers love it, because they can, if they want, use new features sooner.

    For Microsoft it is also key to get support back on track. At the moment support for VS.NET 2003 customers is absolutely the most CRAPPY support I’ve ever seen. NO bugfixes, NOTHING. I understand that if whidbey was released in October 2004, a lot of people would simply upgrade to .NET 2.0 and whidbey, however that’s now not the case.

    You are also not going to convince me that customers don’t want bugfixes (or that VS.NET doesn’t have bugs which are really annoying).

  3. Frans Bouma says:

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

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

  5. Frans Bouma says:

    WRT support I talk about .NET and VS.NET. Both have issues which need addressing and some have been addressed already (as you said, the hotfixes).

    I tried to make a point from an ISV’s perspective. I understand that if I call PSS I get support, but that’s not helping me because I can’t use the fix they construct for me as my CUSTOMERS don’t have that fix installed. So if I write code which will work IF you have the patch (hotfix) installed, I can’t distribute it to customers because they don’t have the patch installed nor can I sell my work to potential customers because they can only use my product if they get the patch from MS.

    So a hotfix is bogus for me. It’s nice my internal app works, but it’s useless for my customers, and to avoid having issues with installments on the customer’s machine, I can’t install hotfixes on my development box because hotfixes will make my code work on my machine but it will break on a customer’s machine.

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

    * Release service packs at least once per 2 months. This will allow ISV’s to ship code which works with a patched system as customers can freely download the service pack themselves

    * Make the bugdatabase browsable online. Now it’s impossible to see what bugs are reported and acknowledged. It’s also impossible to say: "this bug needs a fix a.s.a.p.".

    * IF a developer files a bugreport, ALWAYS respond. I’ve filed 3 bugreports in a row in 2003 and never got any response. With the 4th I decide to publish it in the newsgroups so people could read about it and MS personell could respond. No reaction too (only from people who had the same issue). Do you think I did anything with the 5th I found? No, why should I invest the time? I file bugreports using the bugreport forms on the MS site. I don’t call PSS because as I said, hotfixes are not useful to me as my customers don’t have these fixes nor can they download these fixes.

    What’s however more important is that MS needs to write their software more modular. Everything is tied together. I mean, you really have to start thinking when an XP service pack breaks an IDE. Also is it remarkable how a .NET version is tied to a VS.NET version. As if the compiler is part of the editor. It’s easier to tie everything together and take a lot of shortcuts however I really wonder why I had all those classes about good software design back on the university while MS does the complete opposite. I know that by creating an universal IDE which can use any .NET compiler and debugger (just plug it in!) will cause a drop in VS.NET sales, but this has to stop. In the end, there will be only loosers, no winners in this.

    But with the more tied in integration of Yukon with whidbey I think instead of less integration and more modular design, everything is less modular and more tied together ‘because this release is just for this .net version anyway’. I find that particular sad, especially because the software, whidbey, is more than a year away!

    Just my 0.02$

  6. Frans Bouma says:

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

    I want features I need. Let’s say VS.NET is setup as modular as it is sold to be. What I then want is an option to buy the functionality I want, and if new functionality is made available, I can buy these new functionality when I feel like it. Need a refactoring engine? Buy it. It can be done now, there are 3rd party developers who do this, so why do I have to buy a complete new vs.net ?

    When I look at whidbey (I’m in the alpha testers group) I see a lot of goodies that seem really nice. There are a lot of things too I’ll never use however, but others might use these features extensively. And vice versa.

    With the power of a modular system, you can, as a software vendor, add new functionality by adding modules or replacing modules with newer ones. Why should an Oracle developer have to buy all the fancy Yukon tools in Whidbey? Isn’t that absurd? I think it is. I think Yukon’s installer should install the add-ins for Yukon in whidbey, they shouldn’t be part of whidbey per se.

    The vs.net 2003 upgrade to vs.net 2002 was the perfect example why a big monolithic tool won’t work: it killed .NET 1.0 developers off and forced them to migrate to .NET 1.1. While this was often a good scenario to do, it was also a think they were forced to do. Furthermore, you couldn’t compile a class library with the .NET 1.0 compiler so .NET 1.0 users could use it. Also the 1.2 year period it took to get fixes for bugs in VS.NET 2002 and .NET 1.0 was way too long and because there weren’t any fixes to VS.NET 2002, VS.NET 2003 became the service pack for VS.NET 2002.

    Would everything have been modular, this wouldn’t have happened.

    After more than 30 years, MS makes a hell of a lot of money each year, but at the same time they have forgotten that thinking in money figures first and what’s best for the software second is not always bringing you the best product available. It won’t be this year perhaps, but if a system like Eclipse is taking off for .NET, VS.NET will not be able to keep up, especially when f.e. stuff like .NET 2.0 are introduced and people do not want to upgrade to .NET 2.0 yet (or can’t upgrade yet) but do want to upgrade to the new editor/IDE because of the vast amount of bugfixes it brings.

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

  8. "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.

  9. Shane King says:

    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.

  10. denny says:

    OK I’ll Add to this:

    I have been reading about the wonders of "XCOPY DEPLOYMENT" for a long time now…. the so called "ENd of DLL HEll"

    so put that idea into practice……

    for example: Vs.Net 2002 can’t use .Net 1.1

    and I bet VS.net 2003 will not be able to use .NET 2.0 ither….

    now Granted the older toolset will not "Understand" new features but……

    we need to have all of the developer comunity "Eat our dogfood" as the saying goes.

    ties between VS versions and .NET versions need to be reduced.

    and as .NET has "side by side" and other versioning features then we *SHOULD* be able to for example get releases of say "ASP.NET" seperated from relases of say "ADO.NET" and from say "WINFORMS.NET"

    if the framwork and namespaces today can’t do that then Microsoft is shooting it’s self in the foot every day that continues.

    if the framwork *CAN* then do it for crying out loud!

    why not have asp.net 1.1.4xxxx and 1.1.5xxx and 1.1.6xxx etc… all running in the 1.1 GAC set??

    isent that why we have version numbers and public keys?????

    isent that why we have the GAC????

    and then stuff like the patterns and paractices sets that *BREAK* the main rules!!

    ApplicationLogging Block that works with EIF for example has on it’s download list

    that it *REQUIRES* WSE 2.0

    WHAT KIND OF EXAMPLE IS THAT??????????

    WSE 2.0 is a tech preview….. so how am I supposed to build and ship code based on using it to anyone?

    this is why we are getting angry folks….. cause the *ONE THING* that the open source guys have got right it how to push builds out to the folks who need them….

    the logging block for example should never have the wse 2.0 link, that should have been a "in the next relase we will add web service logging …. that will ship when wse 2.0.xxx has been made public"

    I wasted a bunch of my time trying to get the logging block ready to use , found the wse thing then found out how to not use that part but then had to dump it due to time (lack of) so now i am back to my own logging code ….

    that kind of thing is happening too often guys…..

    like the ADO.NET Datareader bug that I have to tell new coders about so they can add the CLoseConenction flag…..

    WTF! not ship an ADO.NET 1.1.xxxx update that fixes that and some other ADO.NET problems….

    this is why we are all jumping up and down….

    and the model of "Nothing for 2 years and then 10 new things to learn in 6 weeks"

    it’s like a roller-coaster ….

    let’s have a "release a build every 6 months" kind of system where perhaps one build adds ADO fixes

    the next adds asp.net 1.6 stuff

    then later an Winforms update and so on….

    "SOftware as a Service that you buy like a magazine subscription"

    I think Bill and STeve wanted to do that right???

    so what magazine do you buy that only publishes 1 issue in 24 months??

    thats what we are "Hooked on"

  11. Chad Thiele says:

    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?

  12. This conversation has totally rat-holed Microsoft support, and frankly I’m not the right person to discuss this as I don’t work in support. My post wasn’t supposed to be meant as *the* explanation for why we don’t have service packs. I don’t know the answer to this, I don’t work for support. I don’t know the answer to the servicing questions and I’m not trying to make excuses, I was simply trying to help :)

    My point *was* that VS 2005 has quite a bit of work that still needs to be done before it will ship.

    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…

    I think the PSS suggestions Frans outlined below are totally reasonable and good ideas.

    * Make the bugdatabase browsable online. Now it’s impossible to see what bugs are reported and acknowledged. It’s also impossible to say: "this bug needs a fix a.s.a.p.".

    * IF a developer files a bugreport, ALWAYS respond. I’ve filed 3 bugreports in a row in 2003 and never got any response. With the 4th I decide to publish it in the newsgroups so people could read about it and MS personell could respond. No reaction too (only from people who had the same issue). Do you think I did anything with the 5th I found? No, why should I invest the time? I file bugreports using the bugreport forms on the MS site. I don’t call PSS because as I said, hotfixes are not useful to me as my customers don’t have these fixes nor can they download these fixes.

    I also think it sucks that you filed 3 bug reports and didn’t get any feedback. I think that’s unacceptable and shouldn’t have happened.

    **Warning: I am not a Support person**

    WRT ISVs – You do need to make the distinction between VS.NET and .NET framework service packs as there is nothing blocking an ISV from applying hotfixes to developer tools in their organization. The other point on multiple service packs is that we got flack from customers saying that we were releasing too many service packs for Windows and that their customers didn’t want to patch all of their systems once every six months, let alone once every two months. ISVs complained that multiple service packs for Win 2K increased their test matrix and they found themselves requiring a specific version of a service pack, say SP3 for their customers to install the software. Once ISVs required a specific version of a service pack, that createe a barrier for customers/organizations who are not ready to upgrade to a specific version of a service pack. In large organizations, a service pack is tested quite thoroughly before it is rolled out on all machines domain administrators lock down machines so that users can’t patch unapproved machines. The pain that we’ve heard from ISVs is that we are forcing them to choose – create a release that works with a specific service pack and lose customers that can’t/won’t/haven’t upgraded to that SP, or create multiple releases that work with multiple service packs and the additional dev/test/QA/support work this entails. I don’t know the right answer to this situation….

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

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

  15. David Nicholson says:

    I hope you don’t drop the early releases and the background info (from blog’s, etc) that’s been happening lately.

    I can see you’re getting grief on this, and some people are suffering from bugs in released products, but I don’t think that cutting off the information will solve any real problems. The position seems clear to me – early information and pre-realeases are not products, they provide direction. I for one value that.

  16. Khurram At SharpCoders Dot Net says:

    /*

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

  17. Khurram,

    Great idea, like I said, we’re investigating, stay tuned :)

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

  19. So there’s obviously been a TON of blogging in the last week over Microsoft’s decision to delay Whidbey until 2005. Dan…

  20. Michael Carr says:

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

  21. Kevin Daly says:

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

  22. Frans Bouma says:

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

  23. Frans Bouma says:

    "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

  24. Frans Bouma says:

    "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 "

    You have bugfixes and you have new features. Those are separate things. Bugfixes are required to make the software work as advertised. You can’t leave them out, customers NEED them. New features is something different as these can be ‘handy’ but do not make the current crop do their thing as advertised because the current featureset is what’s advertised, not the new stuff.

    I’ve done MDAC related development since 1996. I never had issues with ‘multiple mdac versions’. THey’re COM components. If a new version is coming out, the NEW objects had a new interface GUID. The old ones kept the same one. So a new MDAC version could be installed at any time, fixing bugs in the older objects and installing new features if they were required. Developing software against ADO 2.1 will not make the software run against ADO 2.5 if you install a later MDAC version with ADO 2.5. THAT’s what most of these people don’t understand.

    Signed assemblies can work the same: if you patch a bug internally, is it appropriate to update the version number? Not everyone agrees on this (some of the fusion team members even). If you keep the version number the same, you can keep current software working and immediately use the bugfixes. You can also solve this by using policy files of course.

    So if MS releases .NET 1.2 (I know whidbey’s version number is .NET 1.2) as an upgrade to .NET 1.1, policy files can point the compiled code to the new versions which have the same interfaces but internally bugfixed code. The same with the MDAC versions and other COM libs.

    In a way, the COM model is more powerful in this than the strong versioning in .NET as it doesn’t require policy files: simply install an update over the old one and it works, new stuff is installed immediately.

    IMPORTANT.

    ==========

    Now we come to the real issue. An update can contain a bug. A developer faced with the bug can do 2 things: wait for an update or work around it. Because MS has a policy to release updates very rarely for a lot of software (except the COM+ guys, they release updates on a regular basis, they are an example how things should be done), the developer is most likely going to work around the issue. Workarounds have the bad habbit to break regularly when an update is released which DOES fix the bug: the workaround often assumes the code behaves badly and fixes it at runtime. If teh code suddenly works correctly, the workaround fixes too much.

    The longer the delay between bugreport and fix, the more workarounds are introduced. And the more workarounds are introduced, the more code breakage will occur once a fix is released.

    It is thus KEY that bugfixes are released often and to the public. Fixes which simply FIX code and not necessarily update an interface. Like in COM, dump the new dll over the old one, run the app, it’s fixed.

    I fully understand that if you have a lot of parts which change and a big framework has this, you get a lot of small patches over time. Isn’t that where service packs are for? -> people who do not want to install a lot of patches one by one, install a service pack at once. We’re not talking an OS here which has issues with drivers and other things, we’re talking .NET, which has a clear API spec and bugfixes simply should make the code do what the API spec advertises. If the service pack installs these fixes and makes that happen, it’s ok. I.o.w.: a 3 month testperiod for a .NET service pack is thus not necessary.

  25. WRT Frans & MDAC, my post was about how releasing multiple versions of APIs as Denny had suggested (Winforms, ASP.NET, ADO.NET) may introduce quite a bit of complexity and not about actual fixes (I know you’ve heard it before, I’m not support, but I’ll say it again). I am in total agreement with you on the differentiation between bug fixes and new features.

    Back to the multiple API issue – and my [personal] thoughts on this:

    Let’s say that we did release ADO.NET, Windows Forms, and System.XML, and Collections in multiple versions. How do you support customers that are not on your version of Windows Forms? Do you force everyone to upgrade? What if you can’t databind to ADO.NET objects because your customers aren’t on the latest ADO.NET release that your application needs? What if they’re collection classes are newer then yours and your code uses a deprecated method? Do you create a version for one release and another for another? You end up with a Frankenstein model that introduces quite a bit of complexity and a large test matrix. This isn’t laziness on the development company, its cost and time taken to test that all the interdependencies actually work. The well-known example is the Middleware company that implemented Petstore 2.1. They had to test multiple CPUs (2,4,8), multiple Operating systems (Windows, Linux), using multiple application servers using multiple JVMs using multiple JDBC drivers, using multiple databases. They also had to understand how to profile, tune, and optimize every single scenario. Read more here: http://www.middleware-company.com/documents/j2eedotnetbenchmark.pdf

    Imagine your one goal is to try and optimize the # of server threads for the application using different CPU profiles with a goal of seeing what the best performance. You would have to test each and every different configuration and adjust the # accordingly.

    1) App Server A on Windows with JRocket, and driver version 1.2 (let’s not forget we may have multiple versions of drivers, does the old one outperform the new one?) against Oracle 8

    2) App Server A on Windows with JRocket and JDBC driver version 1.3, against Oracle 8

    There test cycle was 10-man weeks per app server or a total of 20 weeks. Microsoft testing took two weeks. Frankly I’m impressed that the J2EE testing was that short. They even found that a specific version of a specific JVM (SunSoft 1.4) on a specific app server (A) couldn’t be used for the web services benchmark, or at all with App server B.

    I can only imagine trying to setup all the hardware that you would need to test all of these pieces.

    WRT the COM model, the model where you replace an old dll with a new dll was called DLL Hell. There was no side-by-side, it was last-in-wins and everyone hated this. Imagine that you’re deploying a dll, you replace the version that’s on a user machine say 2.0 with 3.0 and your app works fine. The user then installs an application that uses an outdated version say 1.0 of the same COM component, and it replaces the version on the user machine that you installed (v3.0) and now your app doesn’t work. Its a very brittle process and I don’t think last-in-wins is a good way to version applications.

  26. 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?

  27. Shannon – My point isn’t that it won’t work its that you have a whole new level of complexity for testing to make sure you are choosing the right versions.

    Complex Testing

    The TMC report shows how painful it can be to actually choose which versions of which APIs are the best, the example I used is trying to find out which combination gives the best performance. Once you’ve actually gone through testing each and every combination of APIs work the best together (if some work at all together), then yes, you can deploy side-by-side assuming you have "permission" to.

    Deployment Barriers

    As I mentioned before, in some large enterprises, rolling out code that could alter the behavior of a server or a PC is only allowed after an approval process where the application is tested and made sure to not cause breaking changes. There could theoretically be situations where the new version of an API could change in the underlying OS behavior causing a side-by-side version to break. Or if your app uses a particular version of say ADO.NET and an update/bug fix/whatever to ADO.NET makes it incompatible with the non-patched version that you have. Frans also brings up some scenarios that would need to be addressed like if an update introduces a bug. I’m sure there are more scenarios for this… Frankly, there are still companies that have not upgraded from Fx 1.0 to Fx 1.1 because of perceived issues with side-by-side installations.

    CLR Issues

    There are other issues as well, mainly several APIs may require a different version of a CLR (to say understand generics) and you would also need to make sure your combinations have the right mix of CLR and APIs to work successfully.

    Tool features

    [NOTE: Please don’t respond to this saying that our tool should be decoupled from the framework, we’ve heard it, thanks ;)]

    Let’s say you want refactoring support (read more about C# refactoring support at http://blogs.msdn.com/jaybaz_MS/) in your application. That means you will have to have a specific version of the C# compiler with Visual Studio. Why? Because we wanted to make sure the refactoring engine is safe and trustworthy. When you use that rename refactoring for a method used 500 times across multiple source files, you want to rely that the engine updated all 500 references correctly. The key to our refactoring engine, and the difference from our competitors (and an advantage of being able to use both the tool and compiler together) is that the refactoring engine uses the intelligence of the compiler to find the *exact* references that need to be changed. The compiler has all the smarts about understands which references to which code are correct under which context.

    Namespace1.Foo() and Foo() are different, and if you, say had a refactoring engine based on text matches, and you invoke the rename refactoring and want all references to Foo to become "Bar", a text-search refactoring engine (a bad one at least) would incorrectly rename all references of Foo to Bar regardless of context. Because the refactoring engine uses the compiler, you’ll know that if the code can compile, the refactoring is changing the *exact* references it should. Just one example small example of how tool/compiler integration is a good thing, but I’m sure there are plenty of others…

  28. One last thing Shannon that wasn’t clear in your response, are you asking for separate versions of all APIs?

  29. I wasn’t asking for anything; I was wondering why you used that example. Side-by-side is my reason (excuse?) for not supporting both v1.0 and v1.1, I am not a component developer, I don’t think I have to cater to v1.0 users because they can install v1.1 sxs.

    I am completely happy with long waits before releases of the framework and tight coupling of framework and IDE. The only thing I don’t like is the hotfix issue. You can’t say "we have a hotfix, use that" and then also say "it hasn’t really been tested so we’re not releasing it" and say "don’t complain about this bug, we’ve released a hotfix for it" and say "you aren’t allowed to distribute this hotfix with your apps, it isn’t tested enough" all in the same conversation and expect anyone to be happy about the situation.

  30. Shaun Newman says:

    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.

  31. Mark Cliggett[MS] says:

    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.

  32. blog coward says:

    My frustration over M$ has been blogged, still this can’t be said enought: thank you very much Dan Fernandez for having the guts to finally break the M$ silence and for the classy and respectful way you are doing it. It will not be forgotten, even if we disagree and/or still have major issues with your bosses.

    Frans keep up the heat, you’re a well spoken and calm voice for those of us boiling over.

    Mark thank you too, please oh please let your bosses know that their locking us in and sticking it to us isn’t simply angering hot headed programmers, these issues run very deep and wise biz people will act accordingly.

    One last note, even if M$ saw the light and made .NET modular, made VS stand on it’s own two legs, and release Yukon on it’s own time schedule, none of it matters because IE still breaks it all. Fire the senior boss of IE and bring it out of the dark ages.

    Cheers.

  33. Blake Ryan says:

    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.

  34. Can I have a hot-fix that will make the ASP.NET/HTML code editor emit XHTML and not mess with the code I’ve already writtten? Oh and perhaps one that will make the server controls emit xhtml as well. Gimme these two items and I’ll wait until 2017 for whidbey.

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

  36. Mark Levison says:

    Great thread – I’ve written a long reply/open letter on the subject: http://dotnetjunkies.com/WebLog/mlevison/archive/2004/03/22/9735.aspx

  37. Stephen Johnston says:

    "if the framwork *CAN* then do it for crying out loud! "

    The framework allows this for specific situations where it is needed and it is prudent. I do not think it is prudent to spin VS.NET or the Framework into a million stupid little version merely because we *can*. Because you "can" is the worst reason to do something.

    We have seen with other language the hell that is caused by spitting out code into version after version after version. Yeah, ‘the open source community does it’ SO!! WHAT!! The bigger question is "Does it have a beneficial effect?" and I say that releases every 2 months and versioning every 2 months for non-critical features is not beneficial to any of us.

  38. Mark Levison says:

    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.

  39. Mark – Good point, you aren’t alone here….we are working on addressing this issue, stay tuned.

  40. MacKenzie Mickelsen says:

    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

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

  42. MacKenzie Mickelsen says:

    Thanks Dan you ROCK!!!

  43. Isn’t it true that Yukon is getting hold ups due to the development of the next Exchange version that will get rid of nasty EDB & STM files and directly integrate into SQL 2005 (Yukon) as the backend database for Exschange Server.

    At least this is what I was told by the Yukon SIG Group meeting at MS a few months ago!!!!

    Looking around everyone’s info there is very little on this subject except to the very close knit Yukon team.

    Regards,

    Stephen

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

  45. Jay Smyne says:

    If you want to do it properly, look at Eclipse! Truly an amazing IDE and release process. I am getting back into C# and VS so I’ll have to get used to all these problems people here are referring to.

    DF Quote:

    <—–>

    Namespace1.Foo() and Foo() are different, and if you, say had a refactoring engine based on text matches, and you invoke the rename refactoring and want all references to Foo to become "Bar", a text-search refactoring engine (a bad one at least) would incorrectly rename all references of Foo to Bar regardless of context. Because the refactoring engine uses the compiler, you’ll know that if the code can compile, the refactoring is changing the *exact* references it should. Just one example small example of how tool/compiler integration is a good thing, but I’m sure there are plenty of others…

    <—–>

    Coming from a Java and Eclipse place I was impressed with Eclipse’s built-in simple text "rename refactoring" support. It was never a problem as you could restrict it to packages. Eclipse is not integratated in the compiler! Using VS before, I had a 3rd party VS refactoring plugin that didn’t seem to need the framework!?

    Its the old problem of whenever installing MS software I always/mostly need to reboot! Why does installing Office 2003 or Internet Explorer or similar, update the operating system? Doesn’t it make sense to decouple the OS from the apps?

    DF Quote:

    <—–>

    The framework allows this for specific situations where it is needed and it is prudent. I do not think it is prudent to spin VS.NET or the Framework into a million stupid little version merely because we *can*. Because you "can" is the worst reason to do something.

    We have seen with other language the hell that is caused by spitting out code into version after version after version. Yeah, ‘the open source community does it’ SO!! WHAT!! The bigger question is "Does it have a beneficial effect?" and I say that releases every 2 months and versioning every 2 months for non-critical features is not beneficial to any of us.

    <—–>

    Using Eclipse with multiple versions of JDK concurrently was a breeze. Some of my team used Eclipse 2.x and I used multiple versions of 3.x as they were released depending on what I needed resolved. If I wanted to play with Java Generics JDK beta 1.5 then I could plug this in and flag it on or off and not notice anything. They release versions often and like someone else said here, I don’t like getting 100 features at once 1 year later – isn’t it better to progress steadily and smooth the learning and bugs curve?

    Having IDE detached from framework makes sense since the framework designers are forced to design and provide an interface.

    Please don’t dismiss "the open source community does it’ SO !! WHAT!!" just shows ignorance and naivety. It has worked so well! Surely there are things to learn!

    Eclipse is free, open and releases often. It is the best Java IDE you can get. They have no problem worrying about losing customers (excluding the fact its free) because its detached from the framework. Because if it is good then it will be popular. I couldn’t imagine paying for a Java IDE when you have Eclipse. MS shouldn’t worry if VS is good.

    But then again, look at the monster of features in VS. No wonder it takes so long to release new versions – crazier still if you need to update the framework! What joke. I’m not here putting down VS as it is still one awesome IDE but simple and clear it aint!

    I hope I’m not as abgry as some of you now that I’m going back into Microsoft’s world given the freedom, "freenness" and "openness" of the Java world.

    P.S. Where can I get a .NET 1.2 SDK that supports Generics? Can I just plug it in like I did with JDK 1.5 and have it co-exist with other SDK’s and/or run-times?

  46. Response to Jay Smyne

    Quote #1 on refactoring: C# can have multiple classes in one single file, and VS has the concept of projects where developers can refactor across multiple projects (let’s say 30 projects for example). If you want more information on the benefits of integration, check out Jay Bazuzi’s post http://blogs.msdn.com/jaybaz_ms/archive/2004/02/26/80518.aspx.

    Quote #2 on splitting versions: Just FYI, the second quote you included is not mine, that quote is from Stephen Johnston, so please don’t attribute your assumptions to me :)

    Do you disagree that testing is an issue with multiple versions? What did you think of the middleware study that I referenced above?

    http://blogs.msdn.com/danielfe/archive/2004/03/13/89006.aspx#89401

    WRT Eclipse, there are a couple of advantages that Eclipse has on us that you mentioned

    Decoupling

    1) Eclipse doesn’t build both the framework and the tool, Microsoft does. Whether we decouple or not is up for debate, but as you mentioned, its a lot easier to create just the tool then both the tool and the framework. For example, developers could code to the ObjectSpaces API, but the team has gotten feedback that an ObjectSpaces visual designer is required. For example, an old Java web designer couldn’t understand JSF if JSF was created after the designer was finished.

    Easier Bar

    2) Eclipse is a non-commercial product and makes no guarantees on quality, especially with point releases. I’m not saying there is bad quality, only that being a non-commercial product is a lot easier then being a commercial product. Microsoft must support the product for its lifetime. We are still releasing service packs for Visual Studio 6.0 even though it released circa 1998. If I want another service pack for Eclipse 1.0 to fix bugs, the answer is to upgrade.

    Feature comparison

    3) Eclipse is great for editing code, but out-of-the-box, it doesn’t include features like designers or tools for web, XML Web services, Windows apps (or swing), database integration, database modeling multi-language support, ORM, load testing, and more. I know you can download add-ins that add some of this functionality, but comparing Eclipse by itself to Visual Studio isn’t a fair comparison to Eclipse.

    Releasing often

    4) We are looking to release often, in fact VS 2005 is now releasing about every six weeks. We went from 6-12+ months to six weeks based on customer feedback.

    You mentioned VS isn’t simple or clear – do you have any suggestions for improvement?

    <quote>

    Where can I get a .NET 1.2 SDK that supports Generics? Can I just plug it in like I did with JDK 1.5 and have it co-exist with other SDK’s and/or run-times?

    </quote>

    If you want to play with generics, you can download the source code for the SSCLI and Gyro, the open source implementation of generics – http://research.microsoft.com/projects/clrgen/

    If you are looking for the official .NET 1.2 SDK, you can download it from MSDN if you’re an MSDN subscriber. Or you can also attend Dev Days or TechEd to get a copy of VS 2005.

    The runtimes do co-exist on the same machine, for example I have FX 1.0, 1.1, and 1.2 on the same machine.

  47. sebastian says:

    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.

  48. Dave Goldstein says:

    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!

  49. [ via <a href="http://del.icio.us"><span style="font-style: italic;">del.icio.us</span></a> ] <a href="http://lab.msdn.microsoft.com/express/"><span style="font-weight: bold;">Microsoft

    has made betas of "Express" versions of its programming languages/IDEs</span></a>;

    these will appear in their final form in Visual Studio 2005.<br>

    <br><a href="http://weblogs.asp.net/danielfe/"&gt;

    Dan Fernandez</a>, Visual C# Product Manager, <a href="http://weblogs.asp.net/danielfe/archive/2004/06/29/168417.aspx">writes</a&gt;:<br>

    <p style="margin-left: 40px;">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 …

  50. DeKin says:

    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.

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