Re: Registering a .NET assembly for COM interop access from an ASP page - DOTNET

I have tried putting my DLL in C:\Windows\System32\InetSrv and the ASP page
fails with Server.CreateObject failed. If I put my DLL in
C:\Windows\System32 it works. I have tried your regasm /codebase suggestion,
but it requires a strongly named assembly and my customer says they've had
problems with ASP pages calling a strongly named assembly, so I have to
decide if I want to go down that path. I don't really understand how the
codebase option is supposed to work. According to the regasm documentation
the codebase option creats a codebase entry in the registry that specifies
the file path for an assembly. How does the regasm /codebase command know
what the filepath should be. Is the the filepath of the DLL that's being
registered?

Zoe

""Peter Huang" [MSFT]" <v-phuang@online.microsoft.com> wrote in message
news:m7glg8eLGHA.128@TK2MSFTNGXA01.phx.gbl...
> 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/de...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
>
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>