That's Not ASP!
Traditional ASP developers may be in shock right about now. The greatest benefits of ASP.NET include being able to create DLLs without restarting the Web server, worrying about version conflicts, or registering the DLLs with REGSVR32.exe.
Previously, all COM objects needed to be registered manually, and the server needed to be restarted for changes to take effect. The first time you executed an ASP file that used a COM object, IIS would lock the DLL, meaning it was impossible to update it without restarting IIS. In effect, this prevented most types of remote administration of the server. The developer or an administrator had to be located at the machine to make changes. With ASP.NET, this is no longer necessary.
ASP.NET comes with a new configuration system that you'll learn about in Day 18 that can be modified easily by anyone with the proper permissions. The files placed in the /bin directory are loaded by the runtime automatically, and it's easy to make changes to these files because they're not locked by the server. Rather, ASP.NET makes shadow copies of these DLLs to execute, and leaves the original to be modified by you. You can just keep overwriting them without any worries. Changes are automatically picked up because the code is managed by the CLR.
This also means that Web application deployment is a simple process. Just copy the necessary files to the proper directories and the latest version is up and running. You don't need to restart the server or guide someone through the process if you're not on the premises.
Developing these DLLs in the .NET Framework is similar to the way you developed them previously. There are a few differences, such as the addition of namespaces and the new VB.NET compiler. However, much of the procedure for designing and writing the code remains unchanged.
If you're an ASP developer, you'll also be thankful that your libraries of COM objects aren't obsolete. ASP.NET can use these objects with the familiar Server.CreateObject method. This creates late-bound objects, just as in ASP. You can also use the Type Library Importer to provide these COM objects with some support for the CLR and early binding. However, in most cases you'll want to convert existing objects to take advantage of the many features of the .NET Framework.
Many of the concepts behind developing and using business objects remain the same in ASP.NET. It's the environment around the objects that has changed the most, which has caused a few welcome changes in the way you implement the objects.