Using Components in ASP.NETBy Tribikram Rath
In any real-world Web-based application, the foremost role of a Developer is to normalize the business logic and encapsulate said logic in business components to extend the capabilities of application as a whole. In classic ASP developers turned to creating COM objects in VisualBasic, Visual C++, or Java to implement their custom business rules. For example, an eCommerce site might have a suite of custom business objects that had methods like
CalculateSalesTax(state, totalCostOfPurchase), etc. There are a plethora of articles on
creating and using business objects on 4Guys; for more information, be sure to read: Using
Business Objects in your Web Application.
Naturally, ASP.NET supports business object development in a similar vein to classic ASP. Before we tackle creatnig business components in ASP.NET, though, let's first discus implementing a COM component in classic ASP.
Creating a Simple Business Object in Classic ASP
In this section let's create a very simple component which can perform some mathematical operations, e.g. Addition, Subtraction, Multiplication etc.. To do this with classic ASP, launch VB6 and create an ActiveX DLL project. Next, give the project a name of
Math and the class a name of
Finally, add the following code into the class:
Then build the project with any suitable name, say -
Before we can start using this component in our classic ASP application we must register the DLL in the
registry. To do this, copy the DLL to
regsvr32 to register the DLL. (For more information on this process be sure to read:
Registering a Component on the Web Server.) Once the component has been
registered, we can build an ASP page that utilizes the methods of our component.
This is the traditional way of implementing a business object in a Web application. Everything is quite nice
here except for one thing: deployment of the COM component. First of all, we must register the any compiled
regsvr32. Furthermore, when we want to update our component version, we must
unregister the existing component, delete it, and reregister the new component version. How annoying! In fact,
there's an article here on 4Guys that examines some of these annoyances: Recompiling
ASP VB Components.
ASP.NET to the Rescue!
In ASP.NET these problems have been solved by placing the components in a well-known directory, which is automatically found at run time. This well-known directory is the
/bin directory, and is located
immediately under the Web application's root directory, as shown on the right. The benefit is that no
regsvr32 registration is required to make components available to the ASP.NET application --
components can be deployed by simply copying them to the
/bin directory. With ASP.NET these components
placed in the
/Bin folder are called assemblies, and these assemblies contain a gaggle of information
about themselves, their dependencies, etc.
Another advantage of using components with ASP.NET is that this assembly doesn't get locked on the disk at
run time, like the .DLL files in classic ASP do. Instead the assembly is duplicated by ASP.NET to a "shadow"
copy which is then locked and loaded. Hence, the developers have ample flexibility of replacing the original
components even while the Web server is running. Furthermore, any changes to the
/Bin folder can
automatically be detected by ASP.NET and, if it so happens, then the preloaded "Shadow" copy is unloaded
immediately from the Cache i.e. "Global Assembly Cache (GAC)". When this occurs, all of the new incoming
requests use the instances of the newly loaded component.
There is a catch, though. To use components in ASP.NET we need to build them into these assemblies. This is
done automatically when we build our components using C# or VB.NET, the new .NET-compatible languages, but if
we have an existing COM component written with, say VB6, that we wish to use in our ASP.NET Web page, we must
either register the COM component the old-fashioned way with
regsvr32 or build a .NET-wrapper using
tblimp.exe. Both of these topics are beyond the scope of this article; for information on utilizing
the former approach, though, check out: Converting
ASP to ASP.NET. Perhaps a future article will detail how to use
tblimp.exe. In this article,
however, we will be building the component to use in our ASP.NET page from scratch, which we'll examine in