You must follow these rules with regard to name linkages inside a component directory:
For example, a typical component directory called mybots with two custom components might contain:
All the directories and file must be accessible by the FrontPage user account (the user account used to run CGI scripts).
If you add new components during a FrontPage editing session, you must perform a Recalculate Links operation to update the client-side cache. Normally this is done from the FrontPage Explorer’s Tools menu. However, the FrontPage Server Administrator also supports the Recalculate Links request from the command line interface. The extensions build a private registry of custom components containing an aggregation of the important facts from the bots and/or _vti_bot directories. This registry is stored in a string in a file named _vti_pvt/bots.cnf in the Root Web’s content directory.
Every time you update a FrontPage component’s implementation on the server, you must increment the version number in the corresponding .inf file and Recalculate Links in the web. Otherwise clients will keep using earlier versions of the component in their local cache (in the ‘botcache’ directory under the FrontPage installation directory).
If a page references an unrecognized component on a page in the web, a red triangle (“page contains errors”) will display in the Outline View of the FrontPage Explorer next to the page entry. Select the page, perform an Edit : Properties operation, and see the Error tab for more information.
Run-time errors on Windows 95 are written to C:\FrontPg.log. Run-time errors on Windows NT can be viewed in the Event Viewer. On UNIX, run-time errors are logged with the syslog facility. On Solaris, for instance, these messages are typically saved to the file /var/adm/messages. Common run-time errors include the name linkage problems discussed above.
FrontPage components with server-side DLL implementations on Windows-based Web servers may not be able to overwrite the DLL since the file can be in use and locked by the web server. For efficiency reasons, the Microsoft Internet Information Server (IIS) and the Microsoft Personal Web Server (MSPWS) do not free extension libraries that they load. This is very important for high-volume services that want to avoid reading libraries from disk every time a page is fetched or a form submitted. However, if you are in the process of developing FrontPage component libraries, it means you must keep stopping and restarting the web server every time you need to install a new version so you can test it.
On IIS, this is accomplished from the Internet Service Manager control application on the Microsoft Internet Server group located on your Start menu. Note that all services, included WWW, FTP, and Gopher, must be stopped in order for the libraries to be freed.
On MSPWS, this is accomplished from the Control Panel item Personal Web Server. On the Services tab, select the HTTP service and push the Stop button to halt the server. To restart it, select the HTTP service and push the Start button.
There is an alternative for development machines to avoid stopping and restarting these servers all the time. You can set a Windows Registry value that tells these servers to load and unload extension libraries with each request. Under the HKEY_LOCAL_MACHINE tree, the key is:
\SYSTEM\CurrentControlSet\Services\W3SVC\Parameters\CacheExtensionsIf you set the value of this key to 0, and then stop and restart the server, extension libraries will no longer be cached. To set the server back to normal behavior, set the key to 1 (or simply remove it), and then stop and restart the server.