Framing the (.NET) Question

The official branding of the next framework is 4, not 4.0 (just like Silverlight is 2 and 3). Many people in Redmond apparently didn't get the memo on the official branding as most call it ".NET 4.0." Version number, official branding, consistency, word choice...it's the stuff that editors' nightmares and jobs are made of.

Last week, I asked RDN Express readers: After four to five years, should Microsoft have made more changes to the core? Several developers "reframed" the question, noting that Microsoft was making "additions" to the framework -- or at least should be making "additions" to the framework -- rather than "changes." Jason wrote:

"Should Microsoft keep changing the core? I think not! Add to it? Sure, if necessary, but if the 'CORE' was a module, and improvements were 'additional' modules, then developers could code to the core -- write their own 'wrappers' and 'utilities' around it without fear of instant antiquation. Additionally, software that 'didn't have the correct support modules' could easily identify to the net admins exactly what 'modules' were needed and missing.

"I can compile 20-year-old GREP utilities in Unix and they run great while still using all sorts of new things in Linux. Why can't Microsoft, a 'leader in technology,' make a solid foundation that we can build on versus writing software we know won't run any longer when they decide it be so?"

This time around, developers won't be forced to migrate their apps to the new runtime, according to Microsoft. Last week, I explained that you can run different versions of the CLR in the same app:

"A new hosting model will allow developers to run apps in process side-by-side on either .NET 2.0 or .NET 4.0. The host will choose which version of the CLR to run components of the app in."

Joshua Goodman, Microsoft's group program manager of the Common Language Runtime, weighed in to clarify how this model will actually work:  

"Actually, in most cases, the component (especially COM components) will choose which runtime they run against, meaning they get to run against runtimes they were built and tested against. (We've evolved this story a little bit since PDC, and haven't publicly described the final model yet.) This is a big improvement to compatibility, compared to our previous model, where we often had to roll applications forward to a new runtime. There are still a few cases in which add-ins will be rolled forward to 4.0, but we've also worked very hard to make 4.0 as compatible as possible with 2.0, so even when that does happen, things should work fine.

"That said, we'd love it if you and Redmond Developer News readers would try out our Beta 1, which will be released soon, and see if you can find compatibility issues. If you do find them (no one is perfect) we want to hear about them so we can fix them before we ship."

Reader Mark wasn't impressed with the side-by-side CLR scenario. In response to the question of whether Microsoft should have made more changes to the core, he answered:

"Yeah -- like what people have always wanted from Windows: something lighter, streamlined. And like Windows, we aren't going to see it. It can't be from Redmond unless it has at least two ways of doing everything."

One of the pain points that the side-by-side scenario should ease is Office interoperability. Developers can write .NET 4 add-ins that run against the .NET 4 CLR that get loaded into existing Office apps that run against the .NET 2.0 runtime.

Check it out in Beta 1 and let Microsoft know what you think.

What are you most excited about in .NET 4? The June issue of Visual Studio Magazine will feature a .NET 4 preview and we want to make sure that we have your questions answered. Express your thoughts on the latest framework below or contact me directly at [email protected].

Posted by Kathleen Richards on 04/28/2009