none
COM/.NET Interop and proxy stub confusion RRS feed

  • Question

  • We've written an ATL COM .exe which we talk to from .NET C# and it all works OK.  However when we created this via the project wizard we didn't check the "merge proxy stub" which means we have a proxy stub dll being created.

    When we run I notice the proxy stub DLL is loaded into the process space of both the COM .exe and the .NET .exe.  So  far so good.

    On a whim I cerated a new test ATL .exe, but this time checked the "merge proxy stub". One confusion here is that help for that option says that the merge only works for DLL projects however it's not greyed out for the .exe and appeared to work.

    I now create a matching test .NET C# client and connect to the new test COM .exe and it still works.  However now there is no proxy stub dll in either process.

    Given the COM server uses just standard IDL types I would have thought that C# can do all the marshalling, so it doesn't suprise me that a proxy stub isn't needed, however if that's the case when why does it get loaded in the first example.

    So my questions are:
    1. Does .NET need the COM proxy stub to work.
    2. If yes why does my 2nd example work and if no why does the first example load it.
    3. Is visual studio 2008 now meant to allow the merging of proxy stub code into ATL .exes or is that just an oversight?
    Thursday, October 29, 2009 10:28 AM

Answers

  • You will always need a proxy/stub dll for inter-process communication.  Don't quote me on this, but I think the test EXE did not create a dll because all your types are automation-compatible and you have the type library registered, and the interface(s) have the oleautomation attribute set.  This attribute forces the standard proxy/stub dll to be registered for the interface that has it, and therefore you don't need your own proxy/stub dll.  You still need one, though, only it is provided by Windows.  Your test EXE should fail if you unregister the type library or if you remove the oleautomation attribute from the interfaces.  Or maybe it doesn't fail, but instead you get a proxy/stub generated, like in the first case.  Try it out, I guess.
    MCP
    Thursday, October 29, 2009 2:24 PM
  • Hello

    webjose is right that oleautomation marks it as an interface that can be marshalled by using the standard marshaller and the typelib info, as opposed to the proxy/stub generated by the midl compiler.

    > Is visual studio 2008 now meant to allow the merging of proxy stub code into ATL .exes or is that just an oversight?
    According to product team's comments in this issue report, the problem will be fixed in VS2010. The option for EXE server projects will be disabled. Thanks for your report.
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=506323#details

    If you have any other questions, please feel free to post here.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, November 4, 2009 10:14 AM
    Moderator

All replies

  • You will always need a proxy/stub dll for inter-process communication.  Don't quote me on this, but I think the test EXE did not create a dll because all your types are automation-compatible and you have the type library registered, and the interface(s) have the oleautomation attribute set.  This attribute forces the standard proxy/stub dll to be registered for the interface that has it, and therefore you don't need your own proxy/stub dll.  You still need one, though, only it is provided by Windows.  Your test EXE should fail if you unregister the type library or if you remove the oleautomation attribute from the interfaces.  Or maybe it doesn't fail, but instead you get a proxy/stub generated, like in the first case.  Try it out, I guess.
    MCP
    Thursday, October 29, 2009 2:24 PM
  • Thanks - yes I believe everything is oleautomation compataible, and therefore we _don't_ need a proxy/stub in this case (as evidenced by the fact we don't have one!).  I can imagine that there may be the stub code linked into the .exe - but the proxy stuff must be being handled by the generated CLR Interop Dll.

    I think.

    Thursday, October 29, 2009 3:04 PM
  • Hello

    webjose is right that oleautomation marks it as an interface that can be marshalled by using the standard marshaller and the typelib info, as opposed to the proxy/stub generated by the midl compiler.

    > Is visual studio 2008 now meant to allow the merging of proxy stub code into ATL .exes or is that just an oversight?
    According to product team's comments in this issue report, the problem will be fixed in VS2010. The option for EXE server projects will be disabled. Thanks for your report.
    https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=506323#details

    If you have any other questions, please feel free to post here.
    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Wednesday, November 4, 2009 10:14 AM
    Moderator
  • Hello

    How are you? If you have any other questions, please feel free to post here.


    Regards,
    Jialiang Ge
    MSDN Subscriber Support in Forum
    If you have any feedback of our support, please contact msdnmg@microsoft.com.
    Please remember to mark the replies as answers if they help and unmark them if they provide no help.
    Welcome to the All-In-One Code Framework! If you have any feedback, please tell us.
    Friday, November 6, 2009 6:25 AM
    Moderator