Another extract from the same article:

* The Registry and RegistryKey classes make it easy to work with the Windows Registry, and make it possible for developers to avoid a number of API calls.

* The FileDialog, ColorDialog, FontDialog, and PrinterDialog classes make it easy to work with common dialog boxes in Windows. There's no need to call the Windows API directly nor use the dreaded CommonDialog ActiveX control.

* You can use the FileVersionInfo class to retrieve all the file version information embedded in executable, driver, and DLL files. This class replaces some difficult Windows API coding required in Visual Basic 6.0.

* The Environment and SystemInformation classes make it easy to retrieve system settings that otherwise required calls to several different API functions.


Why would I care if it was easier to call into the API in VB6 if I don't need to because it's already encapsulated in the framework?


>Read the article at the microsoft site:
>
>Replacing API Calls with .NET Framework Classes
>Upgrading to Microsoft .NET
>http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dndotnet/html/replaceapicalls.asp?frame=true
>Ken Getz
>MCW Technologies
>February 2002
>
>Abstract:
>< snip >
>Determine file version information?
>Read and write to any location in the registry?
>Determine user's special folders, such as the Microsoft Windows® Favorites, or Personal folders?
>Retrieve a list of all available drives?
>Find out the user's login name, or the computer name?
>Retrieve a list of all open windows?
>
>< snip >
>The .NET common language runtime is meant to be platform non-specific. Whenever you use a Windows API call, you're tying your code to the specific platform
>Calling the Windows API (or any unmanaged code in Dlls) from .NET isn't as simple as it was in Visual Basic 6.0.
>< snip >