"Orcas" .NET Framework compatibility

Somasegar s WebLog Orcas NET Framework compatibility | Green Tea Fat Burner

Somasegar s WebLog Orcas NET Framework compatibility | Green Tea Fat Burner — Tue, 09 Jun 2009 22:34:09 GMT

PingBack from http://greenteafatburner.info/story.php?id=2871

Somasegar s WebLog Orcas NET Framework compatibility | Cellulite Creams

Somasegar s WebLog Orcas NET Framework compatibility | Cellulite Creams — Tue, 09 Jun 2009 05:34:29 GMT

PingBack from http://cellulitecreamsite.info/story.php?id=8057

Somasegar s WebLog Orcas NET Framework compatibility | Paid Surveys

Somasegar s WebLog Orcas NET Framework compatibility | Paid Surveys — Sat, 30 May 2009 01:18:52 GMT

PingBack from http://paidsurveyshub.info/story.php?title=somasegar-s-weblog-orcas-net-framework-compatibility

Orcas and Highlander - Page 4 | keyongtech

Orcas and Highlander - Page 4 | keyongtech — Thu, 22 Jan 2009 06:07:10 GMT

PingBack from http://www.keyongtech.com/4485107-orcas-and-highlander/4

re: "Orcas" .NET Framework compatibility

TheCPUWizard — Wed, 07 Jan 2009 19:48:25 GMT

Old post, I the "issue" is going to come up again with .NET 4.0 (already in CTP).

Backwards compatibility is an abolsute requirement to the ISV [Independant Software Vendor]. I have a library of over 2 million lines of code (simple linebreak counter, includes non-code lines).

If I re-compile with a new version I "hope" that the code will function identically, but I "need" to know that if there is a breaking change in functionallity, that it will break the build.

Yes, I have ALOT of Unit and Functional testing code [actually included in the above line count], but even the most robust APPLICATION testing does not rigorously test the internal functioning of the vendor supplied code.

What does Windows Vista SP1 Mean for Developers?

Mirrored Blogs — Thu, 20 Mar 2008 04:24:47 GMT

As many people will have noticed, we released Windows Vista Service Pack 1 this week ( read about the

MSDN Blog Postings » What does Windows Vista SP1 Mean for Developers?

MSDN Blog Postings » What does Windows Vista SP1 Mean for Developers? — Thu, 20 Mar 2008 01:43:32 GMT

PingBack from http://msdnrss.thecoderblogs.com/2008/03/19/what-does-windows-vista-sp1-mean-for-developers/

What does Windows Vista SP1 Mean for Developers?

Tim Sneath — Thu, 20 Mar 2008 00:21:11 GMT

As many people will have noticed, we released Windows Vista Service Pack 1 this week ( read about the

re: "Orcas" .NET Framework compatibility

David Nelson — Fri, 09 Nov 2007 22:10:10 GMT

Late to the game as usual, but I just wanted to say that I agree with the majority of posters that backward compatibility should not be a primary design goal of a new version. Its not that is has no value, but its just not worth it if it means holding back other more important fixes or features. I completely agree with Sean McLellan's post; if I upgrade to a new version, I already know that I will have to make some code changes (especially since you can't guarantee 100% backward compatibility, no matter how hard you try). So what if I have to make some extra changes to deal with breaking changes? EVEN IF those changes are actually fairly extensive, its worth it if it means that the new version is better and more usable. And if its not worth it to people like Bill and his banking system, they don't have to upgrade! If you're so worried about your ancient mission-critical system, why are you upgrading to a new version in the first place? Shouldn't you stay with what you know works? In short, backward compatibility simply isn't worth the price you (MS) are forcing us to pay.

re: "Orcas" .NET Framework compatibility

Josh Einstein — Fri, 09 Nov 2007 09:12:37 GMT

There's one problem with the "screw backwards compatibility" approach. Add-ins. If you write an Office add-in, each process can only hold one version of the CLR. So if Winword.exe or Outlook.exe loads .NET 3.5, and .NET 3.5 isn't compatible with .NET 2.0, then the add-in written against .NET 2.0 breaks.

Now if you can make it so that a process isn't limited to one CLR instance, and Outlook.exe and Winword.exe, etc can run .NET 2.0 and .NET 3.5 add-ins side by side in the same process, then I agree with everyone else and screw backwards compatibility. That's how you wind up with stupid names like TimeZone2.