Hi Jas,
Your best bet likely will be to stick the COM component into a COM+
Application and then assign an Impersonation to the COM+ Application.
The problem most likely is that the ASP.NET account (ASPNET or NETWORK
SERVICE by default) - which is doesn't have rights to access the DLL or
access what ever the DLL needs to have access to. IF you don't use COM+ the
DLL just inherits the ASP.NET security token.
So the two choices are: Use COM+ as described or lower the security to give
the ASP.NET account the rights it needs to access the DLL and anything the
DLL accesses. If at all possible the former is probably the better approach.
<g>
+++ Rick ---
--
Rick Strahl
West Wind Technologies
www.west-wind.com www.west-wind.com/weblog
"Jas Manghera" <Ja*********@discussions.microsoft.com> wrote in message
news:58**********************************@microsof t.com...
Hello everyone, Im having a rather strange problem with my custom ASP.NET
application. After deploying the application on a .NET v1.1 computer, the
first time the application is launched it can call an external interop and
excute commands with no problems. However, when the same system is
restarted
and my application is relauched the COM commands do not function (asp &
managed code still works fine).
When I alter the permissions of any file in my application's web folder
the
COM interop functions begin working again. Sometimes I open up my web
config
add a blank space to the end of the file, save & exit, and voila the COM
interop works again (temporarily - until the next restart).
What is going on, is the CLR not loading the COM interop correctly? How do
I
resolve this issue?
