Upgrading Microsoft DotNET

Technologies

Solutions

Industries

Projects

Upgrading to Microsoft .NET

Microsoft Visual Basic .NET offers remarkable power and flexibility, with richer object models for data, forms, transactions, and more. But must upgrade applications before they'll compile and run in the Microsoft .NET environment. Get the in-depth technical details you need to upgrade Visual Basic applications efficiently with this upgrade-specific reference.

Please fill up the form below and we will submit a proposal for your project. Alternatively, you can send email to contact@optionm.net with the project requirements.

Contents

	Designing a .NET Application
	Designing for Web or Desktop?
	Creating Components in .NET
	Calling a .NET Component from a COM Component

Designing a .NET Application

An overview of the differences between typical physical architectures that have proven useful in .NET applications. Each architecture description includes basic guidelines on appropriate scenarios for use, implementation options, advantages, and disadvantages. Describes two-tier, three-tier, and n-tier applications

Two-Tier Application Architecture

A typical two-tier application is a client application using ADO.NET communicating directly with a database server, like Microsoft SQL ServerT (see Figure 1). There are no intervening layers between the client application and the database other than ADO.NET. For more information on ADO.NET, see the .NET Framework documentation, other articles in this series or use the MSDN search engine.

Figure 1. A two-tier application has a client application and a data store, such as Microsoft SQL Server

When to Use a Two-Tier Architecture

A two-tier application is appropriate for a small application that does not have a lot of forms, or perhaps no forms at all. It may also be appropriate for prototypes where the final version of the application uses one of the other n-tier techniques described in this article. A two-tier application is not well suited, however, to an enterprise environment, because development and maintenance time and costs can become unmanageable.

Typical Implementation Options

There are several techniques you can use to develop a two-tier application. All use ADO.NET with a client interface, such as a desktop or Web-based application, and a database, such as SQL Server. Ideas for how to approach the architecture of a two-tier application include:

Use data binding techniques to connect an ADO.NET dataset directly to controls.

Write code that accesses ADO.NET objects to load data manually into controls on your user interface.

Use a combination of the above two techniques.

Code business rules directly on the forms with any of the above techniques.

Advantages

A two-tier application has the following advantages:

Development can be quick and easy because you can use data binding to connect an ADO.NET dataset directly to many of the controls used to build the user interface. This helps you get the basic functions of an application up and running quickly.

You can see an application's entire code by looking in just your forms. There is no need to look at both your forms and into another component to see the code.

Three-Tier Application Using an XML Web Service

Another design option is to use an XML Web service to separate the database's access to another component that returns the data to the front-end application. Figure 2 illustrates this design option.

Figure 2. Use an XML Web service to separate the database layer from the front-end code

When To Use This Technique

A three-tier application using an XML Web service is appropriate for either a Web-based or Microsoft Windows® application. This technique comes in handy when you need the richness of a desktop application, but users connect to it from many different locations and access the data across an HTTP interface.

Typical Implementation Options

You will most likely use the following development techniques to create a three-tiered/XML Web service application:

All SQL resides within the XML Web service. Datasets are built on the server and returned as an XML stream to the client where they can be rebuilt into datasets.

Datasets returned from the XML Web service can be bound directly to the controls on the forms.

Datasets returned from the XML Web service can be used to manually load data into the various controls on the forms.

All business rules are coded directly on the forms.

Advantages

A three-tier application using an XML Web service has the following advantages:

Users can run your application from anywhere they have connectivity to the Internet (or intranet).

Database access is separated to its own component so the front-end code does not have SQL embedded in it.

Connection information is maintained only on the XML Web service, again minimizing client machine maintenance.

The database access layer can be updated in a central location. There is no need to redistribute components to the client if you make a simple code change to this layer.

Three-Tier Application Using .NET Remoting

This type of application architecture is almost exactly the same as the three-tier application using an XML Web service. The only difference is that you use .NET Remoting instead of an XML Web service to wrap up the data access layer. Figure 3 illustrates this design option.

For more information on .NET Remoting, see the other articles in this series or use the MSDN search engine.

Figure 3. Working within a LAN environment, you can use .NET Remoting to wrap up the data access layer

When to Use the Three-Tier .NET Remoting Technique

A three-tier application using .NET Remoting is appropriate for an application 'that must be distributed between computers on a LAN. This may be for business reasons or because the cost of the work involved justifies the cost of the network call.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application.

All SQL resides within the component called through the Remoting service. Datasets are built on the server and returned as an XML stream to the client where they can be re-built into datasets.

Datasets returned from the Remoting component are bound directly to the controls on your forms.

Datasets returned from the Remoting component are used to load data manually into the different controls on your forms.

All business rules are coded directly on the forms.

Advantages

A three-tier application using .NET Remoting has the same basic advantages as a three-tier application using an XML Web service.

Three-tiered applications are quick and easy to program because you can use data binding to connect an ADO.NET dataset directly to many of the controls that you use to build the user interface. This helps you get the basic functionality of an application up and running quickly.

Users can run this application from anywhere they have connectivity to the LAN or WAN.

Database access is separated to another component so the front-end code does not have any SQL embedded in it.

The database access layer can be updated in a central location. There is no need to redistribute components to the client if you make a simple code change in this component.

Note This advantage is true for all n-tier architectures.

Logical N-Tier Applications

The best approach to building an application using .NET is to separate all logical processes into discrete classes. In a typical business application, this generally involves a business rule component, a data layer component, and the front-end code that uses these components. Figure 4 illustrates this approach.

For more information on designing an n-tier application, see the other articles in this series or use the MSDN search engine.

Figure 4. Break up business processes into separate classes to make your application easier to create and maintain

When to Use an N-Tier Architecture

Using a logical n-tier development strategy is appropriate for all types of applications. It works equally well in small, medium, and large applications, and with both desktop and Web applications.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application:

Create the front-end user interface using either Windows Forms or Web Forms.

Create the business rule component as a separate Class Library project.

Create a data layer component as a separate Class Library project. This data layer uses classes to wrap up access to each table. Typed datasets should be used; they provide the flexibility of the dataset class and strong typing for each column in the tables.

Advantages

A logical n-tier application has the following advantages:

Centralizes business rules into a component that is easy to create, use, and re-use. This makes development and maintenance easier.

Provides a high-level language in which to develop business rules, as opposed to using stored procedures and limited SQL language for business rule checks.

Centralizes the data access into a component. This means less repeated code throughout your application; each form that needs to access a specific table always uses the same component.

If you use typed datasets, you get the benefit of looking up column names using IntelliSense instead of having to remember them.

Centralized data access routines help with maintenance, since changes to any data access routine need be made only once.

Provides the flexibility to separate components onto different physical machines at any time. This helps with scalability and better centralization of code.

N-Tier Application Using an XML Web Service

Figure 5 shows an example of how you might take a logical n-tier application design and split it across multiple machines. In this diagram, you can see that an XML Web service is used to access the data layer. The typed dataset is returned across the HTTP layer to the business rule layer. The client application can then consume the dataset for the user interface presentation of the data.

Figure 5. Separate your business processes onto separate machines to help with deployment and maintenance

When to Use This Technique

The n-tier XML Web service type of application design is appropriate when you need the richness of a desktop application, but users may be connecting from many remote locations and need to get the data across an HTTP interface. Keeping the business rules on the client side helps with network traffic, but can impose some maintenance update hassles if the rules change frequently. Because .NET is able to copy over new DLLs without registration, these issues are not as severe as they used to be in earlier technologies.

This scenario can also be useful for Web-based applications where the data might be provided by one Web server, but displayed by another Web application on another Web server.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application. 'These techniques are the same as those of the logical n-tier application.

Create the front-end user interface using either Windows Forms or Web Forms.

Create the business rule component as a separate Class Library project.

Advantages

An n-tier application using an XML Web service has several advantages, many of which are' the same as those of the logical n-tier application.

Centralizes business rules into a component that is easy to create, use, and re-use. This makes development and maintenance easier.

Provides a high-level language in which to develop business rules, as opposed to using stored procedures and limited SQL language for business rule checks.

Centralizes the data access into a component. This means less repeated code throughout your application; each form that needs to access a specific table always uses the same component.

If you use typed datasets, you get the benefit of looking up column names using IntelliSense instead of having to remember them.

Centralized data access routines help with maintenance, since changes to any data access routine need be made only once.

Provides the flexibility to separate components onto different physical machines at any time. This helps with scalability and better centralization of code.

Added benefit: Centralized data access layer.

Added benefit: Application scalability-you can add a Web farm to handle heavy loads of user requests to the database.

Added benefit: Users can connect over the Internet and still access the data from a desktop or Web-based application.

Other N-Tier Application Techniques

Of course, there are many different techniques you could use to create an n-tier application. For example, you could use .NET Remoting to communicate from the client tier to the business rule tier, as illustrated in Figure 6.

Figure 6. You can use a combination of .NET Remoting and XML Web services to give your application the best scalability and maintainability

There are a variety of ways you can configure an n-tier application once you have developed it using n-tier techniques. You can combine any of the methods available in .NET to separate the tiers of an application.

Migrating a Visual Basic 6.0 N-Tier Application

Programmers have used n-tier techniques for many years in previous versions of Microsoft Visual Basic®. If you have existing COM components now, you can easily place a .NET wrapper around them. When you do this, you may have an architecture that looks like Figure 7.

Figure 7. .NET makes it easy to interface with your old COM components

When to use the Visual Basic migration technique

This technique is ideal when you have a large code base of COM components that already contain your business rules and data access routines. This can lower your cost of entry into the .NET Framework because you leverage a lot of your existing code.

Typical Implementation Options

You will most likely use the following development techniques to create this type of application:

Create the front-end user interface using either Windows Forms or Web Forms.

Set a reference to your old COM DLL. Microsoft .NET automatically creates a .NET wrapper around this DLL so you can access the properties and methods just like you would any .NET component.

If you are returning any ADO recordsets from this DLL, you will most likely want to turn them into a dataset-the easiest way to bind to the .NET controls.

Advantages

Using the .NET wrapper around a COM interface can speed up your development cycle by taking advantage of the new .NET features, while using existing code.

Conclusion

There are almost an infinite number of architectural variations you can use when developing .NET applications. The best ones are both easy to create and maintain. Of course, you will also want to look at other design goals, including scalability, reliability and manageability. Many of these topics are covered in other white papers that you can find on MSDN.

Click here to submit your project requirements to Option Matrix, India.

Designing for Web or Desktop.

Summary: Learn about the advantages and disadvantages of using both Web and desktop user interfaces (UI), and gain an understanding of how to weigh other factors that need to be taken into account before deciding on the final user interface for your application.

Making the Choice

When you begin any new development project, you need to decide which technologies you will use to develop the application. There are a wide variety of languages to choose from, various database engines you can employ, and you need to choose a style of user interface to use. In all of these areas, you need to weigh a lot of disparate criteria when deciding on the best technologies for the task at hand.

To decide which language to use, you need to consider which languages you know and which language will let you perform the tasks that need to be accomplished in the application. For example, you would not use Microsoft Visual Basic® to develop a device driver. Instead, you would choose a language like Microsoft Visual C++®, as it allows you better access to the hardware than does Visual Basic. You would choose Visual Basic over Visual C++ to create a standard business application because the Rapid Application Development (RAD) environment lets you create this type of application much faster than Visual C++.

When choosing a database engine, you will also weigh certain factors. You need to consider what database engine your client might already have in-house. You might look at how much and what type of data needs to be stored. You also want to consider how easy it might be to integrate with other databases, or to be able to replicate data from one server to another. All of these factors are weighed before you choose a particular database engine.

Although this document will not help you decide which language or database engine you should choose, it will help you make some informed decisions about your user interface. You will go through the same type of decision making when choosing your user interface as you do when deciding the language or database engine to use.

Some choices about the user interface you choose will be very clear-cut. Some choices will not be so clear, and you will have to weigh many different factors before making the final decision. For example, if you are building any of the following types of applications, you will definitely be using a Web interface:

E-commerce store

Company Web site on the Internet

Remote users with no VPN capabilities, but access to the Internet

Likewise, if you are going to be building any of the following types of applications, you will definitely use a desktop type of interface:

Graphical applications, like games or CAD/CAM

Word Processors

Spreadsheets

You'll also be using a desktop interface if:

You need drag-and-drop support in the application.

You need to integrate one or more products, like Microsoft Word and Microsoft Excel, with your application.

You need to integrate with hardware like POS systems, scanners, cameras, or medical systems.

Of course, there are always those applications that don't fall neatly into the above categories. For example, if you are building any of the following types of applications, you could use either type of interface:

Look-up systems, like product catalogs

Data entry systems

Order processing systems

Accounting systems

Work flow management systems

Charting/graphing applications

In these cases, you need to look at many other factors before deciding on which method will suit your application the best.

In this document, you will learn about the advantages and disadvantages of using both of the different types of user interfaces: Web and desktop. Then, you will learn how to weigh other factors that need to be taken into account before deciding on the final user interface (UI) for your application.

Web Advantages

When you wish to target a Web browser, it's probably because of the advantages the Web UI brings to an application. Developing with the Web allows you to use standard HTML interface elements. Most potential users are familiar with browsing the Internet and are used to how Web pages look and feel.

You get the benefit of centralized application deployment and upgrading without having to distribute the Microsoft .NET Framework. Instead of having to roll out a new software application (with the large .NET Framework) to hundreds or thousands of desktops, you only need to place the new software on a central server and all users can access the software in one place. Similarly, when it is time to make a change to the system, you only need to make that change in one place. Of course, if your users already have the .NET Framework available on their PCs, then you can deploy Windows Form applications in the same manner across your intranet.

If you have to create an application that remote users can use, it is much easier to export data through corporate firewalls over the HTTP protocol rather than other proprietary protocol.

Some applications take a lot of processing power. Instead of having to update each individual workstation, you can increase the power of your central server. This will be a more cost-effective solution than upgrading hundreds or thousands of workstations.

Desktop Advantages

When you program using a desktop UI, you get a much richer set of UI controls than you do with HTML. You can make your UI look like almost anything you want. You can make Tab controls; you can use input masking controls, editable grids, and many other controls that make creating a rich UI very easy. You also have total control over the exact positioning of screen elements.

When creating a desktop application, you can take advantage of the hardware that is already on the machine. You will need to do this if you are thinking of creating a game. Games typically need to interact directly with the video card, which is very difficult (if not impossible) to do with a browser. If you are developing a Computer-Aided Drawing (CAD) or Computer-Aided Manufacturing (CAM) application, you will also need to interact directly with the machine's hardware.

Performance is generally quicker on a desktop because the screen is drawn only once on the desktop and only the data changes. This prevents a lot of screen data coming from the server to the client, which increases the time taken to display the data.

If you need to integrate with any special hardware, such as Point of Sale (POS) systems, numerical control machines, printers, and scanners, it is much easier to produce a tidy interface using a desktop application than it is from within a browser. Browsers are such a closed environment that it is difficult to load the DLL needed to interact with this special hardware. If you are using Internet Explorer 5.x, it is not really that hard, but this does lock the user into using one browser and one operating system.

If you need to integrate with other products, you will find it much easier to do from a desktop application than you will from a browser. Many times you might need to exchange data with Word or Excel. Doing this using automation is very easy in a desktop application, but not so easy with a browser-based interface. The integration process between applications is hard to make generic enough to work across all browsers.

Click here to submit your project requirements to Option Matrix, India.

Creating Components in .NET

Discusses the components you build in Microsoft .NET, which are based on object-oriented programming principles and go beyond the simple classes used in other applications. (25 printed pages)

Understanding .NET Components

Microsoft .NET applications are built from components. All .NET objects expose important attributes, such as properties, methods, and events. These attributes form the foundation of object-oriented programming.

As the architect of Visual Basic .NET objects, you are also responsible for implementing the interface (that is, the properties, methods, and events) necessary for other programmers to use your application's services. Much of your development time will be spent designing objects and writing the code defining the objects and components exposed and used by your applications.

Typically, simple .NET object-oriented programming involves creating a class, adding the properties, methods, and events required by the class, and including the class in various applications. Component-based development takes this basic concept to a higher level. Although the components you build in .NET are based on object-oriented programming principles, they go beyond the simple classes you might use in multiple applications.

So What Is a .NET Component?

A component is a special type of executable built from a .NET project. After compilation the component is typically referenced by applications needing the services provided by the component. In many .NET Web environments, components run on the Web server and provide data and other services (such as security, communications, and graphics) to the Web Services operating on the server. In a Windows Form application a .NET component performs the same role as on a Web server, but on a reduced scale.

.NET components provide a programmable interface that is accessed by consumer applications (often called client applications). The component interface consists of a number of properties, methods, and events that are exposed by the classes contained within the component. In other words, a component is a compiled set of classes that support the services provided by the component. The classes expose their services through the properties, methods, and events that comprise the component's interface.

Simple .NET object-oriented programming involves not much more than creating a class, adding the properties, methods, and events required by the class, and including the class in different applications. A .NET component, however, is a pre-compiled class module with a .DLL (dynamically-linked library) extension. At run time, a .NET component is invoked and loaded into memory to be used by some consumer application. These .NET components are most often built and tested as independent .NET projects and are not necessarily part of another project. After compilation into a .NET DLL, these components can be added to many .NET applications as plug-in service providers.

Each .NET DLL component may contain multiple classes. This means that each DLL may expose a single class or a variety of classes. For instance, if you build a .NET DLL that supports remote data access, the DLL might need to expose separate classes for the database and for the variety of DataSets also produced by the DLL. Or, you may have a single DLL that supports error handling in your applications. In this case, the DLL exposes a single ErrorHandler class that performs all of the error handling required by consumer applications.

What Does It Mean for a Component to Run in a Process?

All Microsoft Windows® applications run in the computer's memory, and use the computer's resources such as disk space, networking services, and graphics capabilities. Windows is a multi-tasking operating system, which simply means that multiple applications simultaneously share the computer's memory and other resources.

Windows manages each application, and the memory required to run that application, as a process. The memory occupied by a Windows application and its data is referred to as the application's process space. Among the important jobs performed by Windows are making sure that the process spaces occupied by applications do no overlap, and providing memory to each process as needed.

Under certain circumstances, Windows may allow process space to be shared among a number of applications. This is particularly true in the case of data or services (such as networking services) that must be shared between applications. Other times the memory occupied by an application is owned solely by the EXE running in that process space.

Many applications such as Microsoft Word and Microsoft Excel support dozens or hundreds of different features. Rather than distribute these application as very large single files, Microsoft has broken the basic functions supported by Word and Excel into multiple executables. The main program ends with an .EXE extension, while most of the other executable portions are files ending in .DLL.

When Word or Excel needs the functionality (perhaps a spell checker, or recalculation engine) contained within a DLL, Windows loads the DLL into the process space occupied by the main application. Windows then manages the main program and the executable code contained within the DLL as a single process. A DLL is called an in-process resource because it executes within the process space occupied by another application.

There are other situations where resources are not loaded in-process. For instance, when Word needs to print a document, Word issues a request to Windows to load a particular printer driver. That same printer driver may be needed by other applications, so Windows loads the driver as an out-of-process service so that more than one application can access the driver. This also means that Windows does not have to load multiple copies of the driver into memory.

In-Process Components

In .NET, components built as DLLs run within the process space of the host application and share memory and processor time with their host applications. At run time, the component (which is part of the host application's assembly and is referenced by its manifest) is loaded from disk and added to the host application's process space. Because no remote procedure calls are generated to mediate communication between the component and its host, setting and reading property values, invoking methods, and responding to events raised by the component occurs very quickly.

Out-of-Process Components

An alternate architecture involves server applications that run as independent processes outside of the client application process space. These server applications usually (but not always) have an EXE file name extension. When Windows loads an out-of-process component, a separate process space is created for the component, and Windows manages the out-of-process component's resource requirements independently of the client application. Windows mediates the dialog between the server application (that is, the component) and the client (the consumer) by passing messages between them.

Differences Between Running Components In-Process vs. Out-of-Process in Visual Basic 6.0 Compared to Visual Basic .NET

There are several significant differences between in-process and out-of-process application architecture:

In-process applications tend to run faster because remote procedure calls are not necessary. The client application has direct access to the component without Windows mediating the dialog.

Out-of-process applications may, in some cases, prove to be more stable than applications built from in-process components. If an out-of-process component crashes, it does not take the consumer application with it. More often than not, if an in-process component stops running, its consumer also crashes.

Out-of-process components are more easily shared among a number of consumer applications. When compiled as sharable resources, Windows loads a single copy of an out-of-process component and makes it available to as many consumers as request it. Serious performance degradation can occur, however, if the component is simultaneously requested by a large number of consumers.

.NET Classes and Components

Although the example you're about to build is not particularly sophisticated, it effectively demonstrates most of the principles of class and component development in .NET. First, you will build a simple .NET class. Once you have built the class, you will use the same code to build a component and include the component in a small .NET application.

A typical requirement of distributed database systems is to synchronize and reconcile updates performed at remote locations. In a .NET-hosted database application, the same record may be updated at multiple sites and submitted to the server for storage. Or, similar records may be created at multiple sites and sent to the server for processing. In such cases, it may be important to know exactly when each record was updated or created so that newer records may be treated differently than older records.

In most such cases, the application assigns a timestamp to database records as the data is modified or added. The server can compare the timestamp on one record with the timestamp on another record and process the records accordingly. However, when the data has been updated in different time zones, it is important to use an appropriate base time for the timestamps. This is often done by using the server computer's time as the timestamp rather than the local time for the data entry.

This is an ideal use of a .NET component. The .NET server can expose its time as a Web Service component that can be read and used by any consumer application. Providing the server time component as a Web Service helps reconcile data changes occurring at geographically distant locations.

One major difference between Visual Basic 6.0 classes and .NET classes is that each Visual Basic 6.0 class module (file) contains one and only one class. This means that a project exposing a lot of different classes contains a lot of different class modules (files).

In .NET, a class can be created just about anywhere in your code. This means that a file in a .NET application can contain one or many classes. Each class in a .NET code module is defined by a Public Class. End Class code block within the module.

This architecture makes it easy to segment the classes developed within a .NET project into logical groups. As an example, in the data access component described earlier, you might choose to put all of the basic data access classes (such as identifying and logging into the database) into one module and all of the DataSet creation and manipulation into a second module. In this scenario, because each module supports multiple classes, project management is easier than having a large number of modules, each containing a single class.

The timestamp example, however, is a bit different. All that's needed in this case is for the .NET server to expose its internal date and time as properties of a component. It's unlikely you'd split the code for such a simple component across multiple class modules.

Click here to submit your project requirements to Option Matrix, India.

Calling a .NET Component from a COM Component

Walks through the details of how to call Microsoft .NET servers from COM clients.

The Joy of Interoperability

Sometimes a revolution in programming forces you to abandon all that's come before. To take an extreme example, suppose you have been writing Visual Basic applications for years now. If you're like many developers, you will have built up a substantial inventory of code in that time. And if you've been following the recommendations from various language gurus, that code is componentized. That is, by using COM (Component Object Model)-formerly Microsoft® ActiveX®-servers, you've broken your application into chunks of callable functionality. Of course, you're also likely to have a substantial investment in components, such as ActiveX controls, from other developers and other companies.

But what if you decide on the radical move of switching development to another operating system entirely? At that point, your entire investment in COM becomes worthless. You can't use any of your existing code, and you have to learn how to do everything on the new platform. This would undoubtedly be a severe blow to your productivity.

Fortunately, switching from COM to .NET involves no such radical loss of productivity. There are two key concepts that make it much easier to move from COM development to .NET development, without any loss of code base or productivity:

.NET components can call COM components.

COM components can call .NET components.

This two-way interoperability is the key to moving from COM to .NET. As you learn the intricacies of .NET, you can continue to use COM components. There are a number of situations where this interoperability is useful:

The switch to .NET won't be instant. It takes time to learn the .NET programming concepts and implementation, so you will probably find that you need to continue working with COM code while you, your coworkers, and your suppliers come up to speed.

The code that you can migrate to .NET can't be migrated all at once. You'll want to migrate, and then test, each migrated component individually.

You may be using third-party COM components that you cannot convert to .NET, and where the supplier has not yet released a .NET version.

Although Visual Basic 6.0 code will migrate to .NET, the migration isn't perfect. You may have components that can't be moved to .NET because of implementation or language quirks.

Creating .NET Classes for Use in COM Applications

Although COM clients can call code that is exposed in a public class by .NET servers, .NET code is not directly accessible to COM clients. In order to use .NET code from a COM client, you need to create a proxy known as a COM callable wrapper (CCW). In this section, you'll learn about the CCW architecture, as well as the steps necessary to create and deploy a .NET class to be used by COM clients.

COM Callable Wrappers

Code that operates within the .NET Common Language Runtime (CLR) is called managed code. This code has access to all the services that the CLR brings to the table, such as cross-language integration, security and versioning support, and garbage collection. Code that does not operate within the CLR is called unmanaged code. Because COM was designed before the CLR existed, and COM code does not operate within the infrastructure provided by the CLR, it can't use any of the CLR services. All of your COM components are, by definition, unmanaged code.

Managed code components not only depend on the CLR, they require the components with which they interact to depend on the CLR. Because COM components don't operate within the CLR, they are unable to call managed code components directly. The unmanaged code simply cannot reach into the CLR to directly call managed components.

The way out of this dilemma is to use a proxy. In general terms, a proxy is a piece of software that accepts commands from a component, modifies them, and forwards them to another component. The particular type of proxy used in calling managed code from unmanaged code is known as a COM callable wrapper, or CCW. Figure 1 shows schematically how CCWs straddle the boundary between managed and unmanaged code. This figure includes a COM program named ComUI.exe, two .NET components named NETService.dll and Utility.dll, and the necessary technology that connects them.

Figure 1. Calling managed code with CCWs

Prerequisites for COM Callable Classes

There are two prerequisites to keep in mind when creating a .NET class that will be used by COM clients.

First, explicitly define an interface in your Visual Basic .NET code, and have the class implement the interface. For example, this code snippet defines an interface named iFile, and a class that implements the interface:

Copy Code

Public Interface iFile
    Property Length() As Integer
End Interface

Public Class TextFile
    Implements iFile
    ' details omitted
End Class

Implementing functionality through interfaces has a major benefit for COM clients. .NET keeps interfaces consistent with previous versions when generating CCWs. This helps keep changes to your .NET server from breaking COM clients.

Secondly, any class that is to be visible to COM clients must be declared public. The tools that create the CCW only define types based on public classes. The same rule applies to methods, properties, and events that will be used by COM clients.

You should also consider signing .NET assemblies containing classes that will be used by COM with a cryptographic key pair. Microsoft refers to this as signing the assembly with a strong name. Signing an assembly with a strong name helps .NET ensure that the code in the assembly has not been changed since the assembly was published. This is a requirement for all global assemblies, which are assemblies that are to be shared by multiple clients, although unsigned assemblies can also be called by COM clients.

Note It is possible to use an unsigned assembly from a COM client by deploying the assembly directly to the COM client's directory as a private assembly. This document does not cover the private assembly approach, because global assemblies are more compatible than private assemblies with the architecture of most COM applications.

It's good practice to sign all assemblies, even private assemblies. This will help in generating better CLSIDs for managed classes, and help avoid collisions between classes in different assemblies.

To create a strong name, you can use the sn tool. There are many options for this command-line tool, and you can type sn /? at a command prompt to see them all. The option you need for signing an assembly is -k, which creates a key file. By default, key files use the extension .snk. For example, to create a key file named NETServer.snk, you could use this command line:

Copy Code

sn -k NETServer.snk

Deploying an Application for COM Access

After you've created a .NET assembly containing a class that will be called by a COM client, there are three steps to make the class available to COM.

First, you must create a type library for the assembly. A type library is the COM equivalent of the metadata contained within a .NET assembly. Type libraries are generally contained in files with the extension .tlb. A type library contains the necessary information to allow a COM client to determine which classes are located in a particular server, as well as the methods, properties, and events supported by those classes. The .NET Framework SDK includes a tool named tlbexp (type library exporter) that can create a type library from an assembly. Tlbexp includes a number of options, and you can type tlbexp /? at a command prompt to see all of them. One of these options is the /out option, which lets you specify the name of the generated type library. (One is created for you if you don't choose to create your own name.) For example, to extract the metadata from an assembly named NETServer.dll to a type library named NETServer.tlb, you could use this command line:

Copy Code

tlbexp NETServer.dll /out:NETServer.tlb

Secondly, you should use the Assembly Registration Tool (regasm) from the .NET Framework SDK to both create the type library and register it in a single operation. This is the easiest tool to use when you're doing both .NET and COM development on a single computer. Like tlbexp, there are a number of options for regasm; type regasm /? at a command prompt to see them all. To create and register a type library using regasm, use a command line such as this:

Copy Code

regasm /tlb:NETServer.tlb NETServer.dll

Thirdly, you must install the .NET assembly into the Global Assembly Cache (GAC) so that it will be available as a shared assembly. To install an assembly into the GAC, use the gacutil tool:

Copy Code

gacutil /i NETServer.dll

Again, you can get a list of all the opti