none
COM Interop compatibility RRS feed

  • Question

  • How does a COM Interop communicating with a COM library? The reason for asking is I would like to know how robust this relationship is in terms of handling changes.

    Say the COM library must be recompiled due to a software change. This will generate a new binary file that might have a different binary layout than the previous version. Will the unchanged COM Interop still be able to communicate with the new COM library or will it require a re-generation of the COM Interop? Does the type of change made to the COM library matter? For instance, would changing the inner workings of a method have a different affect than adding or deleting a method?

    Are there any tools available that could verify that a COM Interop file is compatible with a COM library file?


    • Edited by Lars1346 Thursday, December 22, 2011 2:00 PM
    Thursday, December 22, 2011 1:59 PM

Answers

  • The story is really the same here as any other COM client.  The COM interop will be based off the specific public API of the COM library when it's generated.  If you change the binary API of the COM library, you'll need to make a new interop layer.


    If, however, you use appropriate versioning (ie: make a new interface for the new change, such as IFoo2), you can reuse the existing library without problem.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Paul Zhou Tuesday, January 3, 2012 7:11 AM
    Thursday, December 22, 2011 6:51 PM
    Moderator
  • I largely agree with Reed here.  But to further explain, let's remember that COM is all about registry settings, GUID's and interfaces.  If you are correcting a bug, then do just that.  That is the equivalent of "changing the inner workings of a method", in your own words.  That doesn't affect the interface, the registry entries or the GUID's.  You're safe.

    If, on the other hand, you change the binary layout (again, in your words), then the change goes beyond fixing a bug.  If the layout changes, it means that the COM server now provides DIFFERENT functionality.  This breaks the Interop if you modify the layout of the interface.  If you only add, however, you could still be in good shape.  If you add new methods to the existing interface and don't change any of the existing functionality, most likely the interop DLL will work, but will be unaware of the new functionality.  But that is just a hack.  That is not the way to do it.  The correct way to do it is as Reed said:  Create a new interface.  Usually, the new interface inherits from the previous one (in C#, public interface IFoo2 : IFoo), which ensures binary compatibility with the original interface, while allowing new clients to use the new functionality via the new interface.

    If you are not extending the functionality of an inteface, and instead you are just adding more unrelated functionality, again the answer is a new interface, just don't make it inherit from the previous one.  And of course, a new interface requires new registry keys (for marshaling) and a new GUID (for QueryInterface()).


    Jose R. MCP
    • Marked as answer by Paul Zhou Tuesday, January 3, 2012 7:11 AM
    Thursday, December 22, 2011 7:12 PM

All replies

  • The story is really the same here as any other COM client.  The COM interop will be based off the specific public API of the COM library when it's generated.  If you change the binary API of the COM library, you'll need to make a new interop layer.


    If, however, you use appropriate versioning (ie: make a new interface for the new change, such as IFoo2), you can reuse the existing library without problem.

     


    Reed Copsey, Jr. - http://reedcopsey.com
    If a post answers your question, please click "Mark As Answer" on that post and "Mark as Helpful".
    • Marked as answer by Paul Zhou Tuesday, January 3, 2012 7:11 AM
    Thursday, December 22, 2011 6:51 PM
    Moderator
  • I largely agree with Reed here.  But to further explain, let's remember that COM is all about registry settings, GUID's and interfaces.  If you are correcting a bug, then do just that.  That is the equivalent of "changing the inner workings of a method", in your own words.  That doesn't affect the interface, the registry entries or the GUID's.  You're safe.

    If, on the other hand, you change the binary layout (again, in your words), then the change goes beyond fixing a bug.  If the layout changes, it means that the COM server now provides DIFFERENT functionality.  This breaks the Interop if you modify the layout of the interface.  If you only add, however, you could still be in good shape.  If you add new methods to the existing interface and don't change any of the existing functionality, most likely the interop DLL will work, but will be unaware of the new functionality.  But that is just a hack.  That is not the way to do it.  The correct way to do it is as Reed said:  Create a new interface.  Usually, the new interface inherits from the previous one (in C#, public interface IFoo2 : IFoo), which ensures binary compatibility with the original interface, while allowing new clients to use the new functionality via the new interface.

    If you are not extending the functionality of an inteface, and instead you are just adding more unrelated functionality, again the answer is a new interface, just don't make it inherit from the previous one.  And of course, a new interface requires new registry keys (for marshaling) and a new GUID (for QueryInterface()).


    Jose R. MCP
    • Marked as answer by Paul Zhou Tuesday, January 3, 2012 7:11 AM
    Thursday, December 22, 2011 7:12 PM
  • > How does a COM Interop communicating with a COM library? [...] Does the type of change made to the COM library matter? For instance, would changing the inner workings of a method have a different affect than adding or deleting a method?


    see "Runtime Callable Wrapper"; Defining COM Interfaces > Interface Design Rules (note: [interface/contract] must be immutable); COM Objects and Interfaces > "Interfaces and Interface Implementations".
     
     

    Thursday, December 22, 2011 7:15 PM