Hi Zoe,

I am sorry I did not make it more clear.
The bin directory is meanful for the ASP.NET application.
But for ASP, it has a different mechanism. For an ASP page, it is running
at inetinfo.exe(The IIS process), or the dllhost.exe. This depends on how
you config your ASP application. If you config the Application protection
as Low, it will run in the IIS process(inetinfo.exe).
The inetinfo.exe is under the dir below.
c:\WINDOWS\system32\inetsrv
The dllhost.exe is under the dir below.
c:\WINDOWS\system32\inetsrv

When we call COM from ASP page, it is going the way of legacy win32
application.
In a Win32 Process, there will be a Working dir when we create a process.

lpCurrentDirectory
[in] Pointer to a null-terminated string that specifies the full path to
the current directory for the process. The string can also specify a UNC
path.
If this parameter is NULL, the new process will have the same current drive
and directory as the calling process. (This feature is provided primarily
for shells that need to start an application and specify its initial drive
and working directory.)
CreateProcess
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dllproc/bas
e/createprocess.asp

So the IIS process or dllhost will check the lpCurrentDirectory in their
environment block which is a internal structure for a Process.
Because the IIS process or dllhost's default lpCurrentDirectory is
%systemroot%\system32, so it will try to find the COM dll(the .NET assembly
has been registered as a legacy COM) in the dir above.
That is why when you put the dll under the %systemroot%\system32, it will
work.
But this is not recommend, because that dir is mainly used for stored
system dll, it is hard to maintain if you had put many your own dll in that
dir.

BTW: have you tried my suggestion, that use regasm /codebase to register
the .NET dll as COM?
If you still have any concern, please feel free to post here.

Best regards,

Peter Huang
Microsoft Online Partner Support