Find more freelance jobs
|
Changing the names, data types, or order of the
parameters of a public procedure or Property procedure is the project name. The project name, which is set on the General tab of the Project Properties dialog box, is the first part of the programmatic ID of each class your component provides. For example, the SmallMechanicals component might provide a Widgets class. A client application would create a variable to contain a reference to a Widget object as follows: Private wdgDriver As SmallMechanicals.Widget The programmatic ID is the combination of project name and class name, and it must be unique. If you create a new version of this component, you might give it the project name SmallMechanicals200. Both versions of the Widget object could then be registered in the same Windows Registry without confusion. Changing the File Name You must change the file name of an incompatible component. If you use the old file name without incrementing the file version number, the incompatible component may not install on computers where the old file exists. If you increment the file version, the new file will over-write the old, and applications that used the old version will fail. Compiling with No Compatibility Before you compile the incompatible component for the first time, open the Project Properties dialog box (accessible from the Project menu), select the Component tab, then select No Compatibility in the Version Compatibility box. Do not omit this step. Compiling with No Compatibility ensures that the new executable will not contain any GUIDs (for example, class IDs or interface IDs) that belong to the previous version. This is necessary for applications that use the original version to continue working correctly. Tip After compiling once with No Compatibility, switch to Project Compatibility to simplify your development tasks. Alternatives to Version-Incompatible Changes If you prefer not to make the change to multiple interfaces, as described above, you can take a similar approach with classes. That is, you can avoid changes that cause version incompatibility by adding new objects, properties, and methods, instead of changing existing ones. Existing applications continue using the old methods and objects, while developers of new applications can use the new objects. For example, you might discover that to take advantage of enhancements to your General Ledger system, you need to add a SubAccount parameter to several business rules in your FinanceRules component. If each rule is implemented as a method of the GL object, you could avoid creating an incompatible version of the component by adding a new object named GL97. This object would have the same methods as the GL object, but with a SubAccount parameter where appropriate. If you need to add new versions of existing methods to an object, you can give the new methods the same name with a version or sequence number added -- for example, `Execute2.' This approach is not as flexible or efficient as implementing multiple interfaces. You may end up replicating entire classes, and class interfaces may become large and unwieldy -- for example, you might find yourself using a Query class with an Execute method, an Execute2 method, an Execute3 method, and so on. However, it's a step in the right direction. For More Information "Providing a Reference Point for Binary Version Compatibility" describes when and how to specify a version of your component as a reference point for version compatibility. See "Version Compatibility" for a list of topics related to this feature. Software evolution using multiple interfaces is discussed in "Providing Polymorphism by Implementing Interfaces," in Chapter 6, "General Principles of Component Design."Software evolution using multiple interfaces is discussed in "Providing Polymorphism by Implementing Interfaces," in "General Principles of Component Design." Send feedback to MSDN. Look here for MSDN Online resources. Version Compatibility in ActiveX Components A component can be part of another application because it provides Automation interfaces that the other application can manipulate. Each public class module has a default interface that includes all the properties and methods you added to the class module, plus any secondary interfaces implemented using the Implements feature. Once your component has been used in an application -- or, in the case of ActiveX controls, embedded in a document or on a Web page -- you can change its interfaces only at the risk of breaking the client application. Suppose, for example, that the Spin method of your Widget object has one argument, Speed. If you distribute a new version of your component, in which you redefine the Spin method so that it also requires a Direction argument, you could cause run-time errors in existing applications. At the same time, a successful component will inevitably spark requests for enhancements. You will want to provide new objects, or add new properties and methods to existing objects. Occasionally you will even want to change the arguments of existing methods of existing objects. The following topics describe the Version Compatibility feature of Visual Basic, which is designed to allow components to be enhanced without causing existing applications to fail. · When Should I Use Version Compatibility? Describes the Version Compatibility options and when to use them. Describes an alternative technique for enhancing software components. · Maintaining Binary Compatibility Describes the versioning system Visual Basic uses to prevent compatibility problems. · Levels of Binary Version Compatibility Describes the degrees of binary compatibility Visual Basic measures. · Providing a Reference Point for Binary Version Compatibility Describes when and how to specify a version of your component as a reference point for version compatibility. · Using Binary Version Compatibility Describes when and how to use the feature, problems you may encounter, and messages you may get from Visual Basic. For More Information See "Polymorphism, Interfaces, Type Libraries, and GUIDs," in Chapter 6, "General Principles of Component Design" for background information and concepts.See "Polymorphism, Interfaces, Type Libraries, and GUIDs" in "General Principles of Component Design" for background information and concepts. Next topic Previous topic |