Hi
I'm trying to wrap up an existing legacy com component in a web service. Below is a simplified example of what I'm trying to do.
I have created a ActiveX COM DLL project PJoe with a class CJoe which has the following method
Public Sub test2()
Dim fn
fn = FreeFile
Open "C:\temp\joe.txt" For Output As fn
Print #fn, "Joe"
Close #fn
End Sub
(This works fine if I call it from a vb project.)
I then create a .NET web service & reference the PJoe
[WebMethod]
public string Test()
{
try
{
// looking at System.Security.Principal.WindowsIdentity.GetCurrent().Name and User.Identity.Name show that I am running the code under my normal NT login account i.e. not ASPNET or IUSR etc. I'm using <identity impersonate="true" />.
// the following lines work so I can create a file in c:\temp at this point
StreamWriter sr = new StreamWriter(@"C:\Temp\Joe.txt");
sr.WriteLine("Joes");
sr.Flush();
sr.Close();
// however this throws an System.UnauthorizedAccessException with "Path/File access error"
PJoe.CJoe c = new PJoe.CJoeClass();
c.test2();
}
catch (Exception ex)
{
Console.WriteLine(ex.Message);
}
return "Test";
}
Any ideas what I've missed
Thanks
Joe
COM Interop Permission Problem
kv_kp
It is not that weird.
What is happening is this. The thread that is running the ASP.NET page is not the
thread that is running the COM COmponent. You can check this by dumpin the thread ID
from ASP.NET and the COM coponent it self.
What is happening here is that the VB COM Component is the Aparatment Threaded component and the ASP.NEt is creating that component in an APARTMENT threaded
Context. This makes marsahling necessary and the COM COmponent runs in a different thread. This thread does not have the impersonation context. And hence runs in the
process user context. That explains the whole thing.
To make your component work, Use C++/ATL and create a component that is
marked "Both" threaded.
BillWert - MSFT
inpacem
Joe