Is It Possible to Avoid Loading Implementation Assemblies If Only Interfaces Are Used? RRS feed

  • Question

  • I have the following scenario that involves a .NET-remoted singleton and a legacy native client that understands COM:

    1. I use local machine remoting, using the IpcChannel. Basically I need several applications to talk to the same singleton object that represents a piece of hardware connected to the machine.

    2. All the .NET assemblies are placed in a folder. The .NET remoting hosting process is also launched from this folder; a couple of .NET applications are in this folder as well, and everything works through .NET remoting. Am able to instantiate the singleton, invoke its methods, get internal objects, and so on.

    3. In addition, I have a legacy native client that also needs to talk to the remoted singleton. The legacy client does not belong to me, and I have little control over how it is distributed. It is placed in a separate folder, different from the folder where my .NET assemblies are.

    4. To make the legacy client talk to the .NET objects, I provide a COM-visible library that describes only the interfaces to the authors of the native client, who write the software using only these interfaces - there are no definitions of classes that they use, only the interfaces, that are represented as COM interfaces by the interop.

    The problems with the native client begin almost right away - after getting a reference to the singleton, the legacy client invokes an interface method that returns an interface that is implemented by some internal object defined in my .NET assebly (that resides in a different folder from where the legacy client is). This is where the the exception is thrown, signalling that the type is invalid. Placing the assembly that implements the internal object in the folder where the legacy client is fixes the problem.

    My question is - why does the CLR on the legacy client side care at all about the assembly where the internal object is implemented, if all that is used is interfaces and .NET remoting of the singleton? Since the singleton is remoted, all the implementation details must only be relevant to the appdomain of the .NET remoting hosting process - not the client's as well.

    If I may draw some parallels to COM - when I use a COM object that is hosted in an .EXE file as a "local server", and that object uses some internal COM objects that are implemented in other .DLL files, and if a client receives an interface to one of those internal objects , the .DLL file where that internal object is implemented is not mapped to the process of the client, because it does not care about it, provided that it knows the interface defintion and an available interface marshaler (usually the defaul marshaler is OK). In other words COM allows for 100% separation of interfaces from implementation - can the same be done in .NET?

    Sunday, August 15, 2010 12:09 AM


  • You can always use WCF, have the interfaces and Implementations in completely different assemblies, with the clients only having to know the interfaces to call them
    • Marked as answer by SamAgain Monday, August 23, 2010 5:43 AM
    Sunday, August 15, 2010 8:55 PM