|
The ASPSmith |
|
|
| D: | Domains | Authors.aspalliance.com | Stevesmith | Articles | Setting up a COM component project in Visual Basic 6.0 |
|
Setting up a COM component project in Visual Basic 6.0 First, you need to select the ActiveX DLL project type, as noted in Figure 1:  Figure 1: VB6 New Project Wizard This will create a project file with one class file already part of the project. You should modify this class file to reflect the kind of COM object you wish to build. Generally, you should group your functionality into components based on how the functions logically group together. Typically the functions can be thought of as verbs which act on nouns, and these nouns become the components. Further, you should build your components in tiers, with a Business Logic Layer (BLL) referencing a Data Access Layer(DAL). It is best to prefix your COM object project names with the layer to which they belong. Another layer that is sometimes used is the Application Flow Layer (AFL), which groups together multiple BLL calls and has methods which correspond to single ASP page calls or VB form events. Figure 2 displays a typical BLL component that has been created with one class.   Figure 2: Properties of the BLLUser project and User class Notice that we have set MTSTransactionMode to 3 – UsesTransactions for the User class. This is a good default behavior to give to your components, because by itself it will not result in a transaction being used, but it will enable to component to participate in a transaction if another component initiates one. Transactions are expensive, and should only be initiated by components whose methods are modifying very sensitive or mission-critical data. If you are certain that your application will not deal with transactions at all, you can safely set this to 1 – NoTransactions. This property can be modified later relatively easily, assuming that you construct your component properly (which we will cover). The next step in setting up our environment is one of the most frequently overlooked, but can result in difficult to track down bugs in your application if not followed. For more information on this topic, see the following Microsoft KB articles:
Figure 3 demonstrates the proper settings for the project properties to avoid these issues.  Figure 3: Setting Project Properties When working with COM objects, a common issue occurs when new versions of components conflict with the interfaces of previous versions. These problems can be very frustrating and difficult to diagnose and correct. Hence, the term “DLL Hell” has often been used to describe the interactions between COM components. One option feature that can help mitigate DLL Hell is the use of version numbers on component builds. These can be examined to quickly determine if a particular DLL is the same version as another DLL (say, in a different folder), and thus can help in tracking down “binary compatibility” issues. To set up your project so that it automatically increments the DLL’s version number with each compile, click on the “Make” tab under Project Properties and click the “Auto Increment” checkbox under Version Number, as shown in Figure 4. You can also set a variety of version fields under the Version Information section, which are visible to anyone examining the properties of your compiled DLL.  Figure 4: Setting Make Properties The last thing you need to do for your project is to configure your references. These will depend on the purpose of the component you are building, but a few common references are listed in Figure 5, below. The COM+ Services Library is needed if you will be using Constructor Strings, which are a very useful (and high performance) way to set certain properties for your components without hardcoding them. Using constructor strings performs better than reading from a file or the registry, but unfortunately they can be difficult to maintain, since they must be reset each time the component is reinstalled in COM+. If this component will use recordsets or interact with a database, then you will want to reference the latest version of Microsoft ActiveX Data Objects (in this case we are using version 2.5, but version 2.7 is about to be shipped as this is being written). Lastly, if the component will use XML or XSLT and the Microsoft DOM component, you will need to reference the msxml component, which is called simply Microsoft XML, and in this case is version 3. Of course, if you are calling any of your own custom components from this object, you will need to reference them here as well.  Figure 5: Set Project References An example of a Constructor String method is listed in Figure 6. This method examines the constructor string in order to determine whether or not to use a local file for an XML string, for example.  Figure 6: A Sample Constructor String Handler The last consideration for your component is the compatibility to use. This is found under Project Properties, and provides three choices: No Compatibility, Project Compatibility, and Binary Compatibility. Projects will begin with Project Compatibility, and should retain this type of compatibility until they must be referenced and used by other components in the application. At that time, you will want to change this setting to Binary Compatibility, and reference a copy of the DLL that is stored in a reference folder (i.e. not your live version of the component and not your development compilation target folder). This will prevent access conflicts for this DLL (most of the time, anyway).  Figure 7: Setting Version Compatibility Summary Setting up VB6 projects to build COM components is not terribly difficult, but there are certain steps that can be easily overlooked or set incorrectly if you are not careful. This article should serve as a good checklist for new users to use when creating COM components. For more advanced information, you will want to read my Ideal Component Architecture article/checklist, which covers many COM/COM+/MTS best practices and references several Microsoft sources for additional reading. |
|
|
|
|
|
|