I had a problem similar to this but it had to do with COM servers being installed and registered in directories with long file names.

During installation, the short file name is used to register the COM server. For example, a COM server called MyServer installed in C:\Program Files\Microsoft Visual Studio\MyDir would have the following directory name in the registry:

C:\PROGRA~1\MICROS~1\MYDIR\MYSERVER.DLL

This works okay if there are no directories similar to this on the same level. For example, if you installed Office in Program Files, the short directory name would look like C:\PROGRA~1\MICROS~2. it can't find the directory because the names are so similar.

Two solutions I found were:
1. Uninstall (or unregister) the object, copy it to a new directory that only has short names, and re-install (re-register) the object.
2. Modify the registry entry for it so that it uses long file names.

HTH.

>Hi all,
>
>We developed some VFP 6 (SP4) COM components for an online application. The ASPs involved create instances of the VFP objects, which do direct lookups in native VFP 6 tables on the web server. Development was done on a local workstation. We used the VFP setup wizard to create an install package for the VFP runtimes, COM components, data files, etc.
>
>We run the install on our web server (NT 4, SP5, IIS 4.0) and everything works fine. The DLLs get registered properly, we load the app throught the browser, and all is sweet, and fast.
>
>We shipped the *same* installation package to the ISP of the client (who also claim to be running NT 4, SP 5 but only IIS 3.0), and when we hit the first ASP to use the COM objects, we get the following error:
>
>Microsoft Active Server Pages error '800a01aa'
>
>OLE error code 0x80040154: Class not registered.
>
>
>The ASP error code '800a01aa' cannot be found in the MSDN library, and a quick scan reveals the OLE error (0x80040154: Class not registered) as being caused by a corrupt resource file. It also says that VFP 6 SP3 does not create or load foxuser files when loading DLLs from the runtime libraries. Since we have SP 4, I assume that still applies. In any case, we gave the ISP a valid resource file, but the error persists.
>
>We have also had them manually unregistered and re-register the DLLs using REGSRV32. Still no luck.
>
>Interestingly, in the ASP file, the error is not reported on the line that creates the object, but on the line where one of the object's methods is first called.
>
>Anyone have any ideas here? Is it an IIS 3.0 thing? We have already suggested they go to IIS 4 with the option pack available for NT 4, but have not heard back from them on this.