"Orcas" .NET Framework compatibility

"Orcas" .NET Framework compatibility

Rate This
  • Comments 52

As you know, work is currently underway in my group for the next version of Visual Studio which we call internally as “Orcas”.  

 

Visual Studio “Orcas” is designed to enable customers to rapidly create connected applications on the latest platforms and with the highest quality user experience either individually or as part of a team.

 

We’re shipping the next generation programming framework that includes Windows Presentation Foundation (WPF), Windows Communication Foundation (WCF) and Windows Workflow Foundation (WF) in Windows Vista.  We’re also making this available for the Windows XP platform.  Both of these items will be available prior to the release of Visual Studio “Orcas”.  So we have been spending a lot of time thinking about how we should service these components.  We wanted to make sure that we are really customer focused on how this impacts you to ensure that your experience with the next version of VS is a seamless one.

 

Jason Zander wrote a blog on Framework compatibility last year in the VS 2005 context which is a good read on compatibility.  

  

The approach we are taking is aimed at minimizing the impact of delivering new features and functionality by servicing existing runtime components in-place and then advancing the platform with new assemblies.   Internally we’re referring to this as the “Red and Green” model which I’ll explain below.

 

“Red” assemblies include things like WPF, WCF and WF (which will ship as part of Windows Vista) and .NET Framework 2.0 that shipped with Visual Studio 2005. Our goal for dealing with “Red” items is to deliver service pack like compatibility.  We are going to try very hard to minimize the overall number of changes being done in "red bits" to help reduce churn and achieve very high levels of compatibility.  

 

“Green” assemblies are where we will be introducing new functionality into the platform.  The aim is to have any new feature be additive (for example new controls) rather than a reimplementation of an existing feature (outside of the servicing I mentioned above).  Finally we want to ensure that installing any new assembly will not impact an existing application.  For example, for C# language in Orcas, we will make a small "red bits" change to allow you to get at the new compiler and the new compiler is then a "green bits" addition.

 

If you write a component that depends on a “Red” assembly you can be assured that we’re going to do everything we can to ensure binary compatibility for your code even as we update the .NET Framework and WPF, WCF, WF as we move forward.  All the major new features you’ll see from us will appear in the “Green” assemblies so you can feel comfortable that both your new and old code will work on the target machine.

 

The “Red and Green” model will help us deliver a great new product that makes your experience adopting it as easy as we can.  Look forward to more details on this as we make more progress.

 

Namaste!

Leave a Comment
  • Please add 4 and 6 and type the answer here:
  • Post
  • There is absolutely NO reason to maintain backwards compatibility with previous versions of .NET with new versions.  First you're artificially tying your hands, second, since the frameworks can live side-by-side (except the web.config bug between .net 2.0 and .net 1.1 virtual directories) there is absolutely no reason for for it. (ship the version that your application requires with your application!)

    You tried this with .NET 2.0 and failed to the point where you can't possibly assume that an application will work the same on a machine with .NET 1.1 or .NET 2.0. (i.e. all of the byte manipulation stuff breaks between versions)

    Go build the very best thing you can, and drop all of the crap that isn't needed and forget about backwards compatibility. This isn't about storage space anymore. Do it right, and forget MS's backwards compatible legacy that got it into the security mess.

    Oh and make sure VS.net isn't betaware when it's released like Vs.net 2005... (code editing at 1 cpm anyone????)
  • I have to agree with JohnGalt's comment.  I thought the whole point of .NET's versioning system was that you could run side-by-side.  

    You're already putting wiggle-words into your sentences like "we’re going to do everything we can to ensure binary compatibility for your code."  That's very definitely not the same as "we will assure binary compatibility."  You already have a versioning system that makes it so you never have to touch a version after release.  Why would you want to mess with that?

    This sounds like a really dumb idea, and the whole "Red Green" thing just makes it sound worse.  Ever seen the "Red Green" show?  Not the guy I want planning my version compatibility scenarios.

    -Don
  • I agree with the first two Posters.

    Jens Samson
  • I basically agree with the first two comments: why do you want to ensure backwards compatibilty at all costs?

    The Framework is relatively new, so this is the best moment in its history to introduce new features and do some heavy refactoring/replacing of the old ones.

    .NET is beautiful, so learn from your - inevitable - errors and take advantage of its early age to render it the best framework around. Look more seriously at the feedback center, there are a lot of great suggestions to consider.

    Remember that we, the programmers using .NET, are at the cutting edge, we are early adopters and experimenters, at this time we expect new features but, more than that, we expect improvement over the existing ones.

    You will have to ensure backwards compatibility in the future years, when .NET will be too widespread to change it heavily. That will be the time to focus on consolidation, but now it's  really just too early.

    Yes, like JohnGalt said you will end up tying up your hands: the product is new but you are already suffocating under the burden of legacy.

    You risk to raise a contorted tree.

    Let me say that we like the framework very much: that's why we are so passionate about it and its future.

    We are talking about survival of the fittest framework!
  • I think you're doing the right thing.

    Aim for compatibility and performance.
  • With the recent LINQ CTP, XLinq's feature set is getting close to what we plan to release in "Orcas". ...
  • Doesn't Side by Side Cure All?
    Soma posted in his blog how we plan to produce an updated version of...
  • I agree with the previous posters regarding backwards compatiblity.  One other thing I think that Microsoft should do is always make fields, properties and methods in base classes protected, not private.  This is a HUGE HEADACHE because you are only exposing enough that if I need to make a simple change, I have to rewrite half the functionality.  This is a poor example of how to write base controls.  I could have written two lines of code to add custom sort functionality to the GridView control, but because you didn't expose anything i had to rewrite about half the code.
  • To assist developers, Microsoft is assigning a traffic light color scheme - red and green - to assess .Net Framework updates. Or, if you prefer, a Christmas tree color combo. In a blog entry entitled, "Orcas, .Net Framework compatability," Microsoft's..
  • Even though I have a strong sense of pride in the level of backward compatability that 1.1/2.0 provides, I find myself agreeing with the previous posters.

    Lets step back and ask why someone would want to upgrade their application to a newer version -- probably the biggest reason is to take advantage of the new features in vNext -- keep in mind that when I say features, I primarily mean new functionality that the BCL provides, but be also aware that new features features includes things such as IDE improvements and things that increase productivity. By nature, using and incorporating new functionality requires refactoring -- stripping out and improving my existing code to take advantage of features introduced in vNext.

    When I'm upgrading my application to vNext I'm not concerned with total backwards compatability because I KNOW I'm going to have to change my code anyway to incorporate new functionality. In fact, I'd bet that most devs, as part of this effort, would be happy fixing breaking changes made in the BCL classes if they are an improvement in some way, consolidate functionality scattered elsewhere, or are a fix of a bad design.

    If I'm fat, dumb and happy with the current version and am not interested in new features and functionality, I'm probably not going to upgrade my application just to say that it runs on the latest version of the framework. This seems to be the story that most of the backwards compat. work is done for, and as indicated, I feel that it's not needed.

    As history has shown with 1.1 to 2.0, moving an application forward to a new major version of the framework is an undertaking that requires at least some effort. If part of that development effort is needed to reflect changes made to vNext of the BCL, so long as these changes are documented, and involve making the quality and surface of the BCL better in respect to new and existing developers alike, I think that engineering breaking backwards compat. between major versions is definately acceptable.
  • does 'orcas' support existing .net 2.0 coding?
  • So there you have it MS.

    Fix stuff. Make it work right, and screw backwards compatibility. We don't want, or need it (we being everyone except one person that has replied)

    Do the right thing instead of sticking to your broken "backwards compatible" mantra that got you in trouble with security in the first place and just give us the best possible thing you can and change things if you need to.

    As madening as development on WSE is, I like the fact that they change it and improve it and screw backwards compatibility. It makes me use the new system, but I get benefits, and it isn't tacked on, it's stuff that makes sense from the ground up.  That's the hallmark of the .NET framework and should be the mantra in MS.
  • During the past few months, the Visual C++ team allocated many of its development resources towards addressing...
Page 1 of 4 (52 items) 1234