Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
  1. Home
  2. General Programming
  3. .NET (Core and Framework)
  4. Stymied by interop

Stymied by interop

Scheduled Pinned Locked Moved .NET (Core and Framework)
helpcsharpcomtestingsales
3 Posts 2 Posters 0 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • M Offline
    M Offline
    Mark Schumann
    wrote on last edited by
    #1

    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.

    L 1 Reply Last reply
    0
    • M Mark Schumann

      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.

      L Offline
      L Offline
      led mike
      wrote on last edited by
      #2

      See if this helps[^]

      led mike

      M 1 Reply Last reply
      0
      • L led mike

        See if this helps[^]

        led mike

        M Offline
        M Offline
        Mark Schumann
        wrote on last edited by
        #3

        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.

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups