The January/February issue of Component Developer Magazine (CODE) is focused on the upcoming version of Visual Studio codenamed "Whidbey", and contains several in-depth articles focused on that subject, as well as several general .NET articles.
When I was asked to write a few pages on what's coming in the next version of Microsoft Visual Studio .NET (code named Whidbey), the biggest issue I had was how to limit this article to a few pages.I opted to list a few categories and drill down into each. I'm not going to cover everything, just some key items in each area. Please note that not all of these changes are implemented in the PDC build that attendees are receiving, and that some of these features are still in the planning stages. That said, here are the categories that I'd like to discuss:
Catering to the strength of the third-party .NET component market and the power of the .NET Framework itself, Microsoft includes several powerful new WinForm controls in the Base Class Libraries for Windows application development.The WinForm controls provided by the .NET Framework 1.1 are extremely useful, and the framework for developing new custom controls provided in 1.1 is very strong, but sometimes the development community expects more out-of-the box. Many needs of the development community are satisfied by the basic collection of WinForm controls while some developers have voiced their need for more functionality. Microsoft appears ready to rise to the occasion with the inclusion of many new WinForm controls.
As the core API set underpinning managed application development in .NET, the Base Class Libraries, receive several long-awaited and notable additions in the Whidbey release.The Base Class Libraries (BCL) provide a standardized set of managed APIs to accomplish all of the common and most widely executed application tasks. BCL enhancements surface in as performance-based improvements, class-oriented feature additions, and the introduction of previously missing functionality through entirely new classes.
The next version of SQL Server (code name Yukon) has extensive support of the Common Language Runtime (CLR).Previous versions of SQL Server (2000 and earlier) had a mechanism for creating custom data types. These data types were nothing more than aliases to system data types. In Yukon, you can create your own fully functional custom data types.
ASP.NET Whidbey adds a huge number of productivity features and enhancements.Although it's still early in the development process, Paul and Ken dig in and start playing with some of the new features, passing along what they've found.
C# has always had a reputation as a clean language with lots of innovation.The Whidbey-release of Visual Studio .NET ships with a new version of the C# compiler that has a number of great new features. Some of them will be implemented as generic runtime features that will show up in other languages as well, and some are truly C#-specific. All of them originated in the C# camp. In this article, I will shed some light on my three favorite new features.
The recent Professional Developer Conference (PDC) fostered great excitement about the power of the .NET Framework v2.0. Unfortunately, it is going to be well into next year before most developers even get a whiff of all things Whidbey; and that's only in beta form. Some important .NET language and framework enhancements are in a big holding pattern, though, and I don't think that's right.
This article will demonstrate how you can design and build flexibility into your ASP.NET pages by adding controls dynamically at runtime.You'll learn to add simple controls to a page, progress to adding a user control into a Placeholder control, and then advance to using multiple Placeholder controls to build a template page that is flexible and easy to use.
Skinned controls make a user interface very flexible.With skinned controls, the functionality and the presentation of a server control are effectively separated, making it very easy to change the presentation of the control. If used properly, you can use skinned controls to change the look of an entire Web site by just selecting a separate set of skins.
ADO.NET has a strong and powerful disconnected model.It allows programmers to build a web of in-memory objects and relate contents coming from different tables and even from different data sources. When inter-related tables are involved with the process of query and update, code strategies are important to preserve scalability and maintain high performance. Sometimes compound queries can be more effectively accomplished splitting queries; sometimes not. Submitting changes in batch mode, exploiting the DataSet and its disconnected model, often appears as the perfect solution. However, what if you need to move dozens of MB? The serialization mechanism of the DataSet would increase that by a factor. Tradeoffs is the magic word.
The next version of C# will feature a code refactoring engine built into the Visual Studio environment.A term coined by Martin Fowler, code refactoring allows you to change the code structure without changing or affecting what the code itself actually does. For example, changing a variable name or packaging a few lines of code into a method are code refactoring. The main difference between C# 2.0 refactoring and a mere edit or find-and-replace is that you can harness the intelligence of the compiler to distinguish between code and comments, and so on. This article provides a preview of Visual C# 2.0 code refactoring, to be released with the next version of Visual Studio .NET, code-name Whidbey.