Stymied by interop
-
Hi everyone. My customer has a COM object called validatecom.dll. I need to use this in my VS2005/C# web service. So I used tlbimp.exe to create a Runtime Callable Wrapper for validatecom.dll, defining the namespace as "wsl" because that makes sense in their environment. The COM interface is called IValidate, thus giving me a class called CValidateClass. In my unit test, which runs as an ordinary .NET application, I can instantiate a wsl.CValidateClass object and call methods on it. No problem. When I try to instantiate wsl.CValidateClass in my Web Service, however, I get an error, to wit:
System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID... yadda yadda yadda... failed due to the following error: 80070005.
And as we all know, 80070005 is another way of saying "Access Denied." Now I'm wondering why I can access the RCW assembly from an ordinary application, but not from a Web Service. I tried giving "full control" rights to "everyone" on that RCW assembly, but still no joy. Any ideas on this? I'd be happy with a pointer to an MSDN article, a Google term, anything! Thanks to all for your help. -
Hi everyone. My customer has a COM object called validatecom.dll. I need to use this in my VS2005/C# web service. So I used tlbimp.exe to create a Runtime Callable Wrapper for validatecom.dll, defining the namespace as "wsl" because that makes sense in their environment. The COM interface is called IValidate, thus giving me a class called CValidateClass. In my unit test, which runs as an ordinary .NET application, I can instantiate a wsl.CValidateClass object and call methods on it. No problem. When I try to instantiate wsl.CValidateClass in my Web Service, however, I get an error, to wit:
System.UnauthorizedAccessException: Retrieving the COM class factory for component with CLSID... yadda yadda yadda... failed due to the following error: 80070005.
And as we all know, 80070005 is another way of saying "Access Denied." Now I'm wondering why I can access the RCW assembly from an ordinary application, but not from a Web Service. I tried giving "full control" rights to "everyone" on that RCW assembly, but still no joy. Any ideas on this? I'd be happy with a pointer to an MSDN article, a Google term, anything! Thanks to all for your help. -
led mike
Well Mike, yes and no. I've got the Runtime Callable Wrapper, and I can use it (still) from an ordinary console application, but I'm still getting those errors when I try to instantiate the object from within a web service. I found out that when I just try to load the assembly directly using System.Reflection.Assembly.LoadFile(filename) it fails with the same error. But System.Reflection.Assembly.LoadFrom(filename) appears to work, as does System.Reflection.Assembly.ReflectionOnlyLoadFrom(filename). When I use System.Security.Permissions.FileIOPermission to determine my ASPNET user's rights on the assembly DLL, it tells me I have full rights, so it's not a matter of file access. And I pulled apart the reflection data to find that I'm depending only on mscorlib, which can't be the problem either. I finally tried signing my RCW assembly just in case it was ASPNET not wanting to run unsigned code. So... it looks my specific question is: what is it about the ASPNET environment that makes loading a RCW assembly (or any assembly?) so different from a console environment? Is there a document that addresses that? Thanks to all.