Top Ten Things Dot Net 2.0

1. Classes can now be passed as parameters
Restricting array classes to types that meet an application's needs means one of two things: designing arrays that only hold types you want them to hold—cumbersome—or using generic arrays and living with the fact that they'll accept anything. The best of both worlds is to be able to use a base class array yet have a way to restrict it to types that we want. It's sort of possible to do this already, by writing wrappers for all the array class's methods, but that's a lot of blah-blah at the application logic level.
It is better to have a way of making arrays type-dynamic, so that we can tell the array that a particular object type is headed its way. You can design an array class that will accept any class desired by the client. This is done with the generic List class, which can accept type as a parameter, submitted by the client, and then will accept objects of that type. 10 things you should know about Visual Studio 2005 and the .NET Framework 2.0

2. "Generics" enables type-independent class design
A key failing of the .NET Framework has been its lack of some analog to Java's "template" mechanism, a means of parameterizing object types and classes (C++ has a similar template feature). You now have a similar mechanism called generics.
Using generics, you can design a class that is type-generic, permitting you to make use of whatever type is submitted, without generating an error; you now have syntax to create a class that sees type as a parameter. Generics are language-independent, and in addition to permitting you to create your own classes, the generic mechanism is available in collection classes included with .NET Framework 2.0.

3. Dealing with unmanaged garbage
Even if all unmanaged resources are freed when they aren't needed, the fact is that garbage collection, as in real world, only happens so often. Good wrappers do nothing more than set it out on the curb to be picked up. We get into trouble with this because the collection is scheduled, rather than dynamic (at least where accumulation of unmanaged resources is concerned). Up till now, we've been able to do this manually, with the IDisposable interface, but now we don't have to do it ourselves.
The CLR keeps tabs on the managed heap, but the problem with unmanaged resources is that they are taken up by wrappers in the managed heap, creating a Catch-22. Wrappers begin accumulating wrapping resources that need to be made available again, without waiting for scheduled garbage collection. You can run out of space as the managed heap allots memory for the wrappers but can't provide the resources they want to wrap—and you can't wait for the next garbage collection. You need to be able to trigger the reclamation of those resources. Garbage collection has been improved by the inclusion of two new methods to deal with these problems.
AddMemoryPressure and ReleaseMemoryPressure work as follows. AddMemoryPressure causes garbage collection to happen more often; a managed object using a chunk of unmanaged memory will call AddMemoryPressure, and the collector sees the object as being of a size equally itself plus its wrapped unmanaged resources. The object then calls ReleaseMemoryPressure after finishing with the resources it wrapped, creating a kind of memory management equilibrium. What's particularly nice about these methods is that the methods accept a parameter allowing you to plus- or minus- the "pressure."

4. Put user authentication into apps without having to build it yourself
Just this past week, a colleague came into my office and lamented that he would need to take a security course sometime soon because of problems he was having with a Web app. He's not alone; the biggest challenge of having to create infrastructure to manage user authentication concerns is that is it very complex, and most developers aren't trained in it (and shouldn't have to be).
It's common to respond to this problem by way of forms authentication—the application you're designing authenticates the client up-front, then cookies the client with an encrypted authentication, which it consults with each subsequent request for additional pages from the same server or group of servers. The problem was that even though you had all the tools for building such a system, you had to do exactly that—build it yourself. Now, by way of ASP.NET 2.0, we have classes provided to do most of the work.
As an extra, ASP.NET 2.0's authentication classes not only gives us built-in user account set-up and storage, password handling and look-up, but can also automatically add and retrieve user roles.

5. Manage user-based content display and user data persistence
In addition to built-in parts for managing user roles, we are now provided with a control—LoginView—that allows us to set up content-by-user, displaying the pages appropriate for whoever has logged in to an app, with almost no code. In addition, we have classes giving application program access to application configuration; with this capability comes storage of user-specific data in the configuration database, so apps can easily track user data between visits to a site—again, with almost no code. This feature can even be used with anonymous users.
Page 2 Copyright ©2005 CNET Networks, Inc. All rights reserved. For more downloads and a free TechRepublic membership, please visit 10 things you should know about Visual Studio 2005 and the .NET Framework 2.0

6. User choice of application interface
Creating Web apps and pages that give users the ability to customize is often desirable and almost invariably complex. Building infrastructure like this for individual applications is incredibly costly. The new Visual Studio suite reduces the complexity dramatically: leveraging themes for application interface (which Whidbey unfortunately demonstrated sparingly), an XML mechanism for presentation configuration is built into the LoginName control. IT departments can easily put together skins that bring their Web apps into stylistic conformity with their general corporate look and feel with little mess; but the real pay-offs are simple programmatic theme application to new pages via the property PageTheme, and the inclusion of theme in the "personalization" database described above, enabling the inclusion of user-theme-selectability in apps with only a handful of lines of code.

7. Team System
One of the variations of the new Visual Studio .NET 2005 is Team System, a productivity suite that leverages Solutions Framework 4.0 for life-cycle development and provides efficiency tools for team activity. Built on clearly-defined team member roles, it is driven by an architectural best practices paradigm, with work-item tracking, code analysis, unit testing, planned backup, UML and other features. A topic worthy of a 10 Things list in itself.

8. Independence from IIS, three cheers!
There are developers out there who shout at the sky, turn green and rip their shirts over IIS. This month I watched a co-worker fling dirty looks toward Washington State till nearly midnight over a permissions issue when trying to execute a Web service client that had run fine from VBScript from ASP.NET. Now we'll have a more favorable outburst over freedom from Internet Information Server.
This isn't total freedom, mind you—for final testing, we still need IIS, but we can get the bulk of our development out of the way without having to struggle with the corporate system cops over IIS installations and potential security gaps. Visual Studio 2005 can run on individual machines without IIS. We can run the apps we are working on without it, allowing most of the debug work to happen before worrying about IIS at all.

9. Web services authentication support
Web services, like any other Web-based data transaction, usually require authentication of the users trying to access the servers upon which services reside. We usually have to address this when designing and implementing a new Web service and it's a nuisance. Web Services Enhancements 2.0 provides classes for implementing Web service authentication support, with useful (and often business-critical) options in password-hashing, password return, and token handling, giving your VS Web services development more transport-protocol-independence than before.

10. Solution to the Web services XML problem domain
There are few more frustrating aspects to the otherwise action-packed world of IT application development today than emerging standards. XML Web Services hold incredible promise but are still very young, and common problem domain vocabulary is key. Microsoft would love to provide the standards here—they wish—but since the world isn't quite ready for that (as Passport attests), we now have the problem of selecting a standard to use when designing and implementing XML Web services.
What to do? Select a standard and code forever, turning it into an implementation? Life's too short. Until the dust settles in the critical-mass-standards for Web services showdown, we can leverage Web Services Enhancements 2.0, which lets us choose from the existing not-yet-canonized standards, downloading canned implementations, so we can get right to work with common Web services infrastructure that needs only our business logic. You can add WSE 2.0 to your Visual Studio 2005 arsenal from MSDN.

RECENT THIRTY POSTS (click on the link to read details)