To set component compatibilityWhen building a DLL, the version number of the DLL is automatically specified and incremented by Microsoft® Visual Basic®, unless you choose to maintain component compatibility; see Setting Component Compatibility.
If you're working with a compatibility DLL, it keeps the version numbers and CLSIDs synchronized, and displays a warning if the method parameters change or if methods or properties are deleted or changed.
If you don't have compatibility-level settings for a project-level compatibility set, Visual Basic will continue to increment the version number each time you rebuild the component.
When you delete a current version of an existing DLL and rebuild it in Visual Basic, the DLL is produced with a version number of 1.0. Now you can set the "component compatibility" in the DLL. Setting component compatibility after the first component is built keeps your project in sync as newer versions are built.
To set component compatibility
To set component compatibility in Visual Basic, first build your DLL, then follow these steps:
Note It is possible to specify the target DLL itself as the compatible version, but this can sometimes cause Visual Basic to report that the component is in use and cannot be recompiled. You'll need to restart the Visual Basic editor to release the file before you can recompile it.
During the component development phase, you may have to change the coding functionality a number of times. After the component is instantiated on the server, however, it is cached in memory, and in order to release the component, the Web service must be stopped and restarted (a time-consuming process). A less time-consuming alternative perhaps is to run the application in separate memory space of the server (also referred to as out-of-process, or OOP application). Clicking the Unload button on the properties page for the virtual directory causes IIS to release the component.
Note Although setting an application to run out-of-process protects the Web server against possible failures during development and testing of a new application, you cannot use Front Page Server Extensions to debug an OOP application. Because Visual InterDev™ uses these extensions, you'll need to run your application in-process with IIS in order to debug it.
Because debugging can be done in a separate step, it is easier to create Visual Basic components as ActiveX executable files, rather than ActiveX® DLLs. After debugging, simply recompile the component as an ActiveX DLL. There may be setup issues with this "out-of-process component" configuration; see the Internet Information Server Resource Kit for more information.
Use a Visual Basic form to test your component before compiling it to use with your application. See the documentation on the Fitch & Mather Expense Reporting Tool for more information.
Forms should be kept in a separate Visual Basic project. When using a separate project for hosting controls, you can only step through the code if the component is built as an ActiveX executable file (that is, a local server). At this point, both the Standard exe (the form) and the component can be launched in separate debuggers.
If you use the METADATA tag in global.asa to import constants from a type library you have built, you may see the following message at the start of the debug session:
Active Server Pages error 'ASP 0224'
Cannot load TypeLib
/FMLib/global.asa, line 10
Cannot load Type Library specified in the METADATA tag.
The message usually indicates that the component is waiting in the Visual Basic debugger and you have started the debugger in Visual InterDev 6.0. You can still continue, if you stop the Visual Basic debugger momentarily while the application is starting. After the Visual InterDev debugger is initialized, you can resume debugging the Visual Basic component.
If the "Start Page" of your Visual InterDev debugging session has been marked as session-less (EnableSessionState=False), and you reference the Session object in the Session_OnStart subroutine, you will get an error when you start debugging your application. Apparently, Visual InterDev ignores the EnableSessionState directive, and attempts to load Session_OnStart anyway. Since ASP does not define the Session object for Session-less pages, Visual InterDev will report an "Object not found" error during Session_OnStart if it encounters a reference to the Session object.
To work around this limitation, you can either comment out the lines in Session_OnStart that reference the Session object, or (better) don't use a session-less ASP page as your Start Page for debugging.