Ex.No.2 Develop at least 5 components such as Order Processing, Payment Processing, etc. using .NET component technology.

Using COM Components with Visual Basic .NET

A .NET component always compiles to a dynamically linked library (DLL), which is invoked and loaded into memory at run time. What has not been explained is that DLLs are always loaded into the same process space occupied by the host application (that is, the consumer). This means that Windows manages the consumer application and component as a single process. The component shares memory and other computer resources with the consumer. In-Process vs. Out-Of-Process Components The .NET in-process component architecture results in very fast and reliable communication between the consumer and component. Because they share the same process space, Windows does not have to pass messages between the consumer and component. The consumer is able to read and write the consumer's properties very quickly. However, not all service providers run as in-process components. Thousands of legacy applications conforming to the Component Object Model (COM) architecture have been built over the years. These service providers use an entirely different mechanism (built on Microsoft's ActiveX specification) to communicate with their client applications. A COM-based ActiveX server publishes its interface as a type library, which is roughly equivalent to a .NET application's manifest. The type library contains the definitions of classes exposed by the COM server, including the properties, methods, and events supported by each exposed class. Integrating COM Components with .NET Integrating a Microsoft ActiveX component with a .NET application is very similar to incorporating a .NET component into the same application. First, the COM component's type library is added to the .NET application's references. Next, objects are created and instantiated

from the classes exposed by the COM component. Visual Basic .NET code then manipulates the COM object's properties, methods, and events. COM components run in their own process thread, outside of the .NET application's process space. This means that Windows independently manages the COM component's resource requirements, and passes messages between the component and its consumer. Although the COM out-of-process integration architecture is bound to be a somewhat slower than .NET's inprocess design, most users will never notice the difference. Follow these steps to create a .NET Windows application that incorporates Microsoft Word as a COM-based ActiveX component (Microsoft Word must be installed on your computer in order for this example to work):
1. Open Visual Studio .NET. On the File menu, click New, and then click Project. 2. In the New Project dialog box, under Project Types, select Visual Basic Projects.

Under Templates, select Windows application. Name the new Windows application project COMComponentIntegration and click OK.
3. In Solution Explorer, right-click References, and on the context menu, click Add

Reference.
4. In the Add Reference dialog box, click the COM tab and locate Microsoft Word in the

list of components. (The exact version of Word is relatively unimportant for this demonstration.)
5. Highlight Microsoft Word, click Select to add it to the Selected Components list, and

click OK.
6. .NET responds by asking you whether you would like a wrapper (described below)

generated for the Word object library. Click Yes to indicate that you want .NET to build the wrapper for you.

Understanding Interop Assemblies

Because a COM type library and a .NET assembly are very different internally, .NET applications cannot directly use the information provided by a COM component's library. .NET uses either a wrapper around the COM type library or a primary interop assembly built from the

information in the type library to provide an interface between a .NET application and a COM component. A primary interop assembly is a DLL prepared by the COM component's vendor and is intended to be used when the component is integrated with a .NET application. In the absence of an interop assembly, .NET will prepare a DLL that includes references to each of the classes exposed by the component's type library. The DLL is created by importing the class interfaces that .NET finds in the COM component's type library. The COM type library wrapper is added to the Visual Basic .NET project as a new reference. In Solution Explorer, right-click the wrapper DLL and select Properties from the context menu to see a number of interesting property values. Among these properties is the path to the wrapper DLL. You'll see that .NET has placed the DLL in the same obj directory containing the other component libraries included in the consumer application's assembly. You may see other wrapper DLLs in the obj folder in addition to the component's wrapper DLL. These other DLLs provide interfaces to secondary type libraries used by the COM component. In the case of Microsoft Word, you'll see both a Microsoft Office and a VBIDE interop DLL in addition to the DLL created for Word.

Programming COM Objects From Visual Basic .NET

The code required to integrate with COM components is very similar to working with .NET-built components. The following procedure (which is the Click event handler behind a button name btnCreateWordDocument) creates an object from the Application class exposed by the Word type library. It then creates a new document from the default Word document template (Normal.dot), adds a line of text to the document, then saves the document. Copy Private Sub btnCreateWordDocument_Click( _ ByVal sender As System.Object, _ ByVal e As System.EventArgs) _ Handles btnCreateWordDocument.Click

Dim objWord As Word.Application Dim strPath As String objWord = New Word.Application() With objWord .Visible = True .Documents.Add( _ Template:="Normal.dot", _ NewTemplate:=False) .Selection.TypeText( _ Text:="this is a test") .ActiveDocument.SaveAs( _ FileName:="Test.doc") .Documents.Close( _ SaveChanges:=Word.WdSaveOptions.wdDoNotSaveChanges) .Quit() End With objWord = Nothing End Sub Notice the value supplied as the SaveChanges argument to the Close method near the bottom of this code example. The value refers to an intrinsic constant (wdDoNotSaveChanges) that has been stored in the Word interop DLL. The Word interop DLL contains a large number of properties, methods, events, and constant values that are accessible to your .NET projects.

Managing COM Objects from .NET Applications

One major difference between a .NET in-process component and a COM-based ActiveX component is that the COM object's lifetime must be explicitly controlled by the Visual Basic .NET code. Notice the statement setting objWord to Nothing near the end of the listing above. When working with a .NET-created component, the component is disposed of by the .NET garbage collector. Because the .NET component consists of managed code, .NET takes

responsibility to discard the memory occupied by the object when the last reference to the object goes out of scope. This is not true of COM objects. Once a COM object has been instantiated, Windows normally leaves the object in memory until it is explicitly dismissed by setting its references (objWord, in the case of the listing above) to Nothing. When working with a large COM component such as Word, failure to explicitly dispose of the object at the conclusion of the application can result in enormous memory leaks. For the most part, the DLL wrapper handles other differences between COM objects and .NET components. For instance, one of these differences occurs when Windows moves a component (.NET or COM) in memory. This often happens as Windows tries to optimize the memory used by applications. A .NET application has no trouble keeping track of the location of its own components because the component and its data are being managed by the common language runtime. However, because a COM object contains unmanaged code, there is no way for the .NET application to keep track of the COM object's reference if the object is moved. The COM object's runtime wrapper prepared by .NET takes care of keeping memory references updated whenever the COM object is moved. From the consumer application's perspective, the address has not changed, even though the wrapper automatically translates the static memory reference to the updated location.

Distributing .NET Applications Containing COM Objects

For the most part, distributing a .NET application that contains COM objects is the same as distributing a pure .NET application. The only difference is that you must be sure to include the interop DLL created by .NET so that the common language runtime installed on the end-user's computer understands the interface to the COM component. Also, the COM object must be properly installed and registered on the user's computer. It is difficult to provide generalized rules for COM installation success. Most COM servers (for instance, Microsoft Word) have their own installation programs that create the appropriate folder

tree and registry keys. Generally speaking, if the COM server operates properly on the user's computer, it should work within the context of a .NET application.

What's Different From Visual Basic 6.0?

There are many differences between building components with Visual Basic 6.0 and Visual Basic .NET. In most cases, these changes enhance the development experience by making it easier to build complex applications, test and deploy components, and share components between applications.

.NET projects provide many features that make organizing the project's files easier. Instead of one class per module (a .CLS file),Visual Basic .NET code modules may contain multiple classes while in Visual Basic 6.0 each class occupied a separate .CLS file. The .NET approach allows you to logically group classes within a single code module to make it easier to recognize when classes are related (such as data access, financial, disk and file management, etc.)

.NET components are not registered on the user's computer; Visual Basic ActiveX components must be installed and registered on each user's computer. Each .NET component carries all of the interface information necessary for consumer applications to use the component. A component's interface (classes, properties, methods, and events) are documented in the .NET Object Browser, and through IntelliSense.

.NET error handling is far superior to Visual Basic 6.0's "On Error GoTo" model. It's easy to recognize a .NET error-handling construct, and .NET components can pass back the entire Exception object if necessary.

Class constructors accept parameters. This allows you to specify start-up information at the moment an object is instantiated, rather than waiting for instantiation to be complete, and then setting initial property values.

.NET classes can be logically organized within Namespaces. A Namespace can include classes with the same names as classes in another Namespace. A single DLL may include multiple Namespaces. Visual Basic 6.0 does not support Namespaces.