My 2 cents on the Yukon-Whidbey delay

Are you kidding me? For what possible reason could a database hold up the release of a development tool? Is Visual Studio dependent on Yukon to work? If it is we are all in trouble. My client uses Oracle so Yukon makes no difference to me at this time.

As much as I love MS products this issue is really trying my patience. Only MS could cook up something this ridiculous. I am starting to get tired of the dependecy of every MS product to make other MS products work. Unbundle the Yukon features and fork over Whidbey!!!!

 

 

 

10 Comments

  • My thoughts exactly: www.xml-blog.com

  • Seems to be the consensus, and as a developer I have to admit I also want some of the Whidbey features (esp. the ASP.NET stuff; less so generics). But I also see that most of my big clients are still using VS.NET 2002. Mainly because VS.NET 2003 has an incompatible format for the .SLN file, and it's too much effort for too little benefit to upgrade everyone at the same time. So while we developers all want new toys, I do wonder how important it is to have them now. Patience is a virtue.

  • Then the Yukon runtime should be 2.1.



    VS gets a service pack or minor update. No problem.

  • Whidbey will include the new runtime.

    Yukon will include the new runtime.

    Therefore, the runtime must be finalized before either is released.



    Imagine Whidbey is released, and then a couple months later, Yukon is released. Yukon was later, because they had to finalize a behavior for the DataSet class (just an example). Now you have 2 different behaviors, depending on whether you are using the .NET Framework 2.0 "proper", or the .NET Framework 2.0 hosted in Yukon. Imagine the complaints THAT would trigger!

  • Everett was delayed because of Windows Server 2003. You guys need some perspective here. Just because Whidbey has ASP.NET enhancements does not mean that that's all Whidbey is. VS.NET 2003 is tied to Windows Server 2003, whether you use it as such or not. VS2005(Whidbey) is tied to Yukon, and VS2007(Orcas) is tied to Longhorn.



    Before that there will be 2 betas. No need to get overly emotional about it.

  • Everett came out 1 year after 2002. I don't see a delay there. If it was, when was it planned then? 6 months after 2002? ;)

  • Robert,



    I wouldn't mind if it were being held up because of Windows, which would be a strecth, but SQL Server? A database is not a product used by alot of people, and them only by some developers.



    So we are holding our breath for something most of us don't use? MS is in a catch 22 - they want to show us new features early but can't let us have them. I'm not sure what's worse - not knowing and being surprised or knowing and dying for it.

  • I have to chuckle at all this. Im currently porting an app from VC5.0 to VC6.0, and am having problems running DAO 3.5 debug mode in Visual C++ 6.0. Im having to find the source code for DAO3.5 in order to rebuild it.



    Google posts on the issue are dated 1998!



    [Cue Monty Python inspired 'you've got it easy' ranting]

  • SQL Server "Yukon" embeds the CLR, which version is the next version of the .NET Framework.



    -> Yukon has a dependency on the CLR



    Programming this next version of the .NET Framework will be done by using the next version of Visual Studio.



    -> Visual Studio has a dependency on the .NET Framework



    SQL Workbench, the next "Enterprise Manager" for Yukon will live inside Visual Studio.



    -> Visual Studio has a dependency on Yukon, or is it the contrary?



    To me, it's obvious that these two products are linked. So far, every .NET developer has loved the fine integration provided by the Microsoft products when it comes to software development. Please be patient, and allow some time so that the teams can offer us a still better integration.

  • Honest question to Microsoft: Is Whidbey really tied to Yukon, or is it just Yukon tied to Whidbey? If only the latter, would it not be possible to released Whidbey-A and later w/Yukon Whidbey-B?

Comments have been disabled for this content.