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. COM
  4. Anyone with experience in out-of-proc COM servers?

Anyone with experience in out-of-proc COM servers?

Scheduled Pinned Locked Moved COM
c++comsysadminhelpquestion
6 Posts 3 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.
  • J Offline
    J Offline
    jfugate
    wrote on last edited by
    #1

    I'm trying to write a COM .exe server that creates a small modeless dialog box when properly called. Unfortunately, when I call the COM object from my application, it always returns E_NOINTERFACE from CoCreateInstance when given the correct IID of my COM interface (ICObject in this case, for test purposes). According to MFC documentation, this error occurs when the QueryInterface call does not support the requested interface. However, if I create the same exact COM project using an in-proc .dll file, without changing a single line of code in the calling application (except the CLSCTX_ string in CoCreateInstance), it works fine. I am using MFC's ATL/COM wizard to create both the .exe and the .dll projects. Both settings are for apartment model threading, custom interface, no aggregation and connection points. Here's my application code: ////////////////////////////////////////////// #include "..\COMObject\COMObject.h" #include "..\COMObject\COMObject_i.c" ... HRESULT hr; //instantiate it hr = CoCreateInstance(CLSID_CObject, NULL, CLSCTX_LOCAL_SERVER /*CLSCTX_INPROC_SERVER for DLL*/, IID_ICObject, (void **) &m_pObject); //do something with it if(SUCCEEDED(hr)) { m_pObject->StartDialog(); } ////////////////////////////////////////////// Does anyone have any idea why it works with an in-proc .dll and not an out-of-proc .exe?

    S V 2 Replies Last reply
    0
    • J jfugate

      I'm trying to write a COM .exe server that creates a small modeless dialog box when properly called. Unfortunately, when I call the COM object from my application, it always returns E_NOINTERFACE from CoCreateInstance when given the correct IID of my COM interface (ICObject in this case, for test purposes). According to MFC documentation, this error occurs when the QueryInterface call does not support the requested interface. However, if I create the same exact COM project using an in-proc .dll file, without changing a single line of code in the calling application (except the CLSCTX_ string in CoCreateInstance), it works fine. I am using MFC's ATL/COM wizard to create both the .exe and the .dll projects. Both settings are for apartment model threading, custom interface, no aggregation and connection points. Here's my application code: ////////////////////////////////////////////// #include "..\COMObject\COMObject.h" #include "..\COMObject\COMObject_i.c" ... HRESULT hr; //instantiate it hr = CoCreateInstance(CLSID_CObject, NULL, CLSCTX_LOCAL_SERVER /*CLSCTX_INPROC_SERVER for DLL*/, IID_ICObject, (void **) &m_pObject); //do something with it if(SUCCEEDED(hr)) { m_pObject->StartDialog(); } ////////////////////////////////////////////// Does anyone have any idea why it works with an in-proc .dll and not an out-of-proc .exe?

      S Offline
      S Offline
      soptest
      wrote on last edited by
      #2

      Are you sure CLSID_CObject and IID_ICObject are the same in .DLL and .EXE COM implementation? Check .IDL files they have to be the same for both types of projects (.EXE and .DLL) or just use one .IDL file for both projects. soptest

      J 1 Reply Last reply
      0
      • S soptest

        Are you sure CLSID_CObject and IID_ICObject are the same in .DLL and .EXE COM implementation? Check .IDL files they have to be the same for both types of projects (.EXE and .DLL) or just use one .IDL file for both projects. soptest

        J Offline
        J Offline
        jfugate
        wrote on last edited by
        #3

        I just tried creating a wholly other .exe server in a new directory with a new interface CLSID and IID. Still has the same methods as the previous attempts and the application still gave the E_NOINTERFACE error. For some reason it will not find the interface requested for an .exe server. I searched through the messages and there's one other one back in the annals describing the same exact problem (search for NOINTERFACE).

        S 1 Reply Last reply
        0
        • J jfugate

          I just tried creating a wholly other .exe server in a new directory with a new interface CLSID and IID. Still has the same methods as the previous attempts and the application still gave the E_NOINTERFACE error. For some reason it will not find the interface requested for an .exe server. I searched through the messages and there's one other one back in the annals describing the same exact problem (search for NOINTERFACE).

          S Offline
          S Offline
          soptest
          wrote on last edited by
          #4

          Your CLSID_CObject and IID_ICObject are different (EXE_Project::CLSID_CObject == DLL_Project::CLSID_CObject AND EXE_Project::IID_ICObject == DLL_Project::IID_ICObject). Read my previous post. soptest

          1 Reply Last reply
          0
          • J jfugate

            I'm trying to write a COM .exe server that creates a small modeless dialog box when properly called. Unfortunately, when I call the COM object from my application, it always returns E_NOINTERFACE from CoCreateInstance when given the correct IID of my COM interface (ICObject in this case, for test purposes). According to MFC documentation, this error occurs when the QueryInterface call does not support the requested interface. However, if I create the same exact COM project using an in-proc .dll file, without changing a single line of code in the calling application (except the CLSCTX_ string in CoCreateInstance), it works fine. I am using MFC's ATL/COM wizard to create both the .exe and the .dll projects. Both settings are for apartment model threading, custom interface, no aggregation and connection points. Here's my application code: ////////////////////////////////////////////// #include "..\COMObject\COMObject.h" #include "..\COMObject\COMObject_i.c" ... HRESULT hr; //instantiate it hr = CoCreateInstance(CLSID_CObject, NULL, CLSCTX_LOCAL_SERVER /*CLSCTX_INPROC_SERVER for DLL*/, IID_ICObject, (void **) &m_pObject); //do something with it if(SUCCEEDED(hr)) { m_pObject->StartDialog(); } ////////////////////////////////////////////// Does anyone have any idea why it works with an in-proc .dll and not an out-of-proc .exe?

            V Offline
            V Offline
            Vi2
            wrote on last edited by
            #5

            You should use (and register) the proxy/stub for your EXE server. Or you should use the dual interfaces, derived from IDispatch, or/and oleautomation interfaces, derived from IUnknown, with standard OLE marshalling. For it, you should use the oleautomation compatible types of data, such as long, double, BSTR and so on. In this case, you don't need any additional proxy/stub. With best wishes, Vita

            J 1 Reply Last reply
            0
            • V Vi2

              You should use (and register) the proxy/stub for your EXE server. Or you should use the dual interfaces, derived from IDispatch, or/and oleautomation interfaces, derived from IUnknown, with standard OLE marshalling. For it, you should use the oleautomation compatible types of data, such as long, double, BSTR and so on. In this case, you don't need any additional proxy/stub. With best wishes, Vita

              J Offline
              J Offline
              jfugate
              wrote on last edited by
              #6

              Ahhh, thank you very much. I believe this is the answer I was looking for. I had started to suspect that it had something to do with the [oleautomation] tag, but I'm not knowledgeable yet enough to know what I'm doing. Thanks a lot!

              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