PROBLEM: Multiple instances of an AVR made DLL or OCX listed in Project References or Custom Controls.

The information in this article applies to:

• Windows
• ASNA Visual RPG, Release 3.1 and Higher
• ActiveX
• Deploy

SYMPTOMS:

Here are several symptoms:

• Multiple instances of an AVR made DLL or OCX listed in Project References or Custom Control Panel in AVR;
• Receiving error when opening a "Shared" DLL Project stating that a Reference can't be loaded (see Figure 1).

Figure 1

CAUSE:

Here are several causes:

• Project Compatibility is set incorrectly during compile;
• The DLL has been moved, renamed, or deleted.   Sharing or Moving a DLL Project on multiple Machines and the folder structure is not identical between the machines.

RESOLUTION:

NOTE:  Please coordinate with your Network Administrator or Microsoft while working with the Registry.  Modifying Registry values may have undesired results.  You will need to have Administrative Privileges while working with the Registry.

Resolution Summary:

1. You will need to delete all instances of the DLL in your Registry;
2. Reset the Project Compatibility setting;
3. Recompile the DLL.

Here are some instructions:

1. Close all instances of AVR;
2. Open MS Registry Editor (Start -> Run, "Regedit");
3. Search for your DLL, Project Name, or Class Name;
4. Delete the top most Key that refers to the DLL that was found.  Make sure the Key points to the DLL you found and you don't delete any other keys.  There might be multiple entries and you will need to delete them.;
5. Close the MS Registry Editor;
6. Open your AVR DLL/OCX Project and select the Project Settings in the Project Menu;
7. Select the Component Tab (refer to Figure 2);
8. Change the Project Compatibility selection to Project Compatibility.  This option is selected by default when creating a New DLL Project.
9. Delete or Clear the Path that is referenced in the Path IOField.  Select Ok;
10. Recompile the DLL.

Figure 2

STATUS:

Current.

MORE INFORMATION:

Note: Here is some information that are recommendations.  Our recommendation may not be well suited to your environment.  There might be other ways in which a resolution can be achieved.

Once an error occurs (see Figure 1) when trying to open an existing ActiveX project, the Project Compatibility setting gets set to No Compatibility.  This results in a "broken" link to the existing ClassID / InterfaceID.

TIP: It is important that you verify the Project Compatibility Setting prior to a recompile of an existing ActiveX project.

Here is an explanation of the types of Version Compatibility:

• No Compatibility:
  
  Compatibility is not enforced. Each time you compile the component, new type library information is generated, including new class IDs and new Interface IDs. There is no relation between versions of a component, and programs compiled to use one version cannot use subsequent versions.
  
• Project Compatibility:
  
  If checked, the Location box is active and allows you to search for the file with which this project is to be compatible. If cleared, the Location box is not available.  For all ActiveX project types, Project Compatibility is checked by default.
  
  Each time you compile the component, the type library identifier is kept, so that your projects can maintain their references to the component project. All Class IDs from the previous version are maintained.

NOTE: Binary Compatibility is no longer an option in AVR Release 4.0 or Higher. (See Figure 3)

Figure 3

More information from Microsoft's Article regarding "Application Lifecycle": http://msdn.microsoft.com/library/default.asp?URL=/library/techart/complus.htm

Keywords: IDE, references, compile, registry, listed, sharing, control, library, interface