It's Everett, Not Everest
Paul Litwin explains why there shouldn't be a brouhaha over thenext version of .NET.
October 30, 2009
DevNote
By PaulLitwin
It's Everett, Not Everest
The codename Microsoft has given to the next version ofthe .NET Framework and Visual Studio .NET tells you a lot about the magnitudeof the release. The name is "Everett," after a city in Washington state - notto be confused with Everest, the Himalayan mountain. Everett is about a 30- to40-minute drive north of Redmond, Wash. It makes for a nice day trip, but it'shardly worth a postcard. And so goes the Everett release of .NET: It representsa small, "dot" upgrade of .NET - 1.1 to be exact - so don't expect to see awhole lot that's new and exciting with this release.
With Visual Studio "Everett," Microsoft rolls severalcomponents that were separate downloads into .NET, including the MicrosoftMobile Internet Toolkit (MMIT), J#, and the ODBC .NET Data Provider. Everettalso will add the Smart Device Extensions (SDE) for building Windows CEapplications running the .NET Compact Framework (.NET CF), and a new Oracle.NET Data Provider. Of course, Everett also will have its share of the bugfixes, performance tweaks, and security patches you've come to expect. But allin all, expect a fairly minor update to the .NET Framework and VS .NET. It willcost you $29 and will be available when Windows .NET Server ships - probablyduring the first half of 2003.
Much more interesting to you will be the next release ofMicrosoft's developer environment and tools afterEverett, codenamed Yukon. The Yukonrelease will be synchronized with the next version of SQL Server. SQL Servergains the .NET Common Language Runtime (CLR) and thus you will gain the abilityto craft stored procedures in any .NET language. (Note: I'm not convinced thatthis is necessarily a good thing, but that's another editorial entirely.)Expect this release to be a majorupdate to the Framework and Visual Studio. Web Services will maturesignificantly, with Microsoft architecting many of the currently hot WebService standards such as WS-Security, WS-Routing, etc., into XML Web Servicesin the Yukon timeframe. We also should see a much smarter, more refined VisualStudio IDE and more distinction between VB and C# as the major Microsoftlanguages battle it out for developer mindshare.
If you were thinking we might see a managed code versionof Microsoft Office in the Yukon timeframe, think again - can you imagine howmany lines of icky legacy code Microsoft Office represents? All is not lost,however, because Visual Studio "Yukon" will offer developers the ability to add.NET managed code behind Microsoft Word and Excel documents. VBA will still bethere, but Yukon will give you the choice of writing Office document eventhandlers in either VBA or one of the .NET languages. Expect to see Yukonsometime in 2004.
The fact that the "Everett" version of Visual Studio andthe Framework is so minor actually points out a good thing: The current versionof .NET is pretty much rock solid and doesn't require a lot of major quickfixes. This fact gives Microsoft the luxury of moving .NET along at a slow -but - steady pace, along a well-defined path.
So maybe Everett isn't as exciting as it could have been,but I'll take stability over excitement any day.
Paul Litwin is editor and technical director of asp.netPRO. E-mailhim at [email protected].
About the Author
You May Also Like