I'm getting that old favourite: ActiveX component can't create object.

I have a WindowsXP SP2 (pre-patched) machine with IIS, VB6, VB.Net2003EE, DotNetSP1 and SQL2000Developer, MDAC2.8 SP1 (verified using the mdac tool).

Basically it is the same problem as described here: http://www.experts-exchange.com/Web/..._11605078.html , except I'm not using MTS - these are plain old vb6 com dll's. They recompile just fine, reference each other fine, but when called from asp get the "ActiveX component can't create object" error. Reregistering them doesn't work - but of course they are already registered otherwise VB6 wouldn't show them in its References.

Their suggestion is to reinstall MDAC, which I know from past experience will fix the problem. But I can't do this because I'm running XP SP2, and the MDAC tool tells me it's installed properly anyway.

This site has a description on MDAC and SP2: http://www.dbforums.com/archive/inde...t-1050457.html It tells me how to reinstall MDAC 2.8 SP1 and I've followed these instructions but it doesn't fix the aforementioned problem.

From reading these accounts I thoguht that MDAC might be the culprit. My DLL's all reference ado connections and so on heavily. So I've experimented a bit:

I've verified that a script (vbs or asp) can access my database by the following VBS script:
Set conn = CreateObject("ADODB.Connection")
conn.ConnectionString = "File Name=C:\Documents and Settings\me\Desktop\conn.UDL;"
conn.ConnectionTimeout = 120
conn.CommandTimeout = 120
conn.Open
Set foo = createobject("adodb.recordset")
sql = "select * from mytable"
foo.open sql, conn, 1, 3
do while not foo.eof
msgbox(foo("rowguid"))
foo.movenext
loop
foo.close
conn.close


And I get some alerts. Yay, data access works!

I've built an activex dll in VB6 using the template/wizard which has NO reference other than the standard ones, and added the following code:
Public Function SayHello() as String
SayHello = "Hello"
End Function


Then to test it from a VBS file:
set tbD = CreateObject("Project1.Stuff")
MsgBox(tbD.SayHello())
set tbD = nothing


Which alerts "Hello". So ActiveX is working. I'd be super-surpised if it wasn't.

Next, I've built an activex dll so that it can response out to the asp response stream. I did this by:

1. Used VB6 to make a new ActiveX DLL Project
2. Added References:
- Microsoft Active Server Pages Object Library
- Microsoft Scripting Runtime
3. Added a class called "Stuff" to my project (project1) with the following code

Private m_Application
Private m_Request
Private m_Response
Private m_Session
Private m_Server

Public Sub OnStartPage(objScriptingContext As ScriptingContext)
Debug.Print "OnStartPage"
Set m_Application = objScriptingContext.Application
Set m_Request = objScriptingContext.Request
Set m_Response = objScriptingContext.Response
Set m_Session = objScriptingContext.Session
Set m_Server = objScriptingContext.Server
StartPage
End Sub

Sub StartPage()
Debug.Print "StartPage"
End Sub

Public Sub OnEndPage()
Debug.Print "OnEndPage"
Set m_Application = Nothing
Set m_Request = Nothing
Set m_Response = Nothing
Set m_Session = Nothing
Set m_Server = Nothing
End Sub

Private Function Hello(ByVal s As String) As String
Debug.Print "Hello"
Hello = "Hello " & s
End Function

Public Sub SayHello()
Debug.Print "SayHello"
m_Response.Write App.Path & "\" & App.EXEName & " says " & Hello("world")
End Sub


Compile, register, create a small asp page which creates and calls the object, and boom: activex can't create the object. I thought it still might be my dll's so I tried out 3rd party ones which work on oher machines, but these result in exacly the same error.

I've also tried setting explicit permissions for my IUSR_<name> account to have read & execute on my C:\WINDOWS, C:\Program Files\Common Files\System and C:\INETPUB\WWWRoot folders, and manually registered the C:\Program Files\Common Files\System\ado\msado15.dll file just in case. But to no avail.

ActiveX just seems borked for me for IIS.

I'm sure i've missed something crucial here but the most obvious things are sometimes the least obvious...