Re: Registering a .NET assembly for COM interop access from an ASP page
- From: "Zoe Hart [MVP]" <zoehart@xxxxxxxxxxxxxxxx>
- Date: Wed, 22 Feb 2006 10:59:14 -0500
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@xxxxxxxxxxxxxxxxxxxx> wrote in message
news:m7glg8eLGHA.128@xxxxxxxxxxxxxxxxxxxxxxxx
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
Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no
rights.
.
- Follow-Ups:
- Re: Registering a .NET assembly for COM interop access from an ASP page
- From: "Peter Huang" [MSFT]
- Re: Registering a .NET assembly for COM interop access from an ASP page
- References:
- Registering a .NET assembly for COM interop access from an ASP page
- From: Zoe Hart
- RE: Registering a .NET assembly for COM interop access from an ASP page
- From: "Peter Huang" [MSFT]
- Re: Registering a .NET assembly for COM interop access from an ASP page
- From: Zoe Hart [MVP]
- Re: Registering a .NET assembly for COM interop access from an ASP page
- From: Zoe Hart
- Re: Registering a .NET assembly for COM interop access from an ASP page
- From: "Peter Huang" [MSFT]
- Registering a .NET assembly for COM interop access from an ASP page
- Prev by Date: Share COM object with 1.1 and 2.0 Application Pools
- Next by Date: privileged dll in c# application
- Previous by thread: Re: Registering a .NET assembly for COM interop access from an ASP page
- Next by thread: Re: Registering a .NET assembly for COM interop access from an ASP page
- Index(es):
Relevant Pages
|