Game Development Reference
Another gotcha when using remoting is that it is ideal for the interface to exist in
its own assembly, away from the classes that provide implementation. The beauty
of remoting is that you can give each client machine an assembly containing only
the public interface of the tool, and each machine can build a proxy object to
access the actual implementation remotely. If you keep the interface and imple-
mentation together in the same file, however, it defeats the purpose of remoting
because clients have access to a local copy of the implementation.
There is one problem with keeping the interface in a separate assembly from the
implementation, and that is when also exposing a COM interface. In order for
COM to work, it must know what both the interface and the implementation are
defined as. When paired together in the same assembly, COM has no trouble find-
ing either the interface or the implementation, but when the interface exists by
itself in a separate assembly, COM will not register output for that interface, com-
plaining that it cannot find any suitable types to generate COM output for. This
error will cause registration to fail for the implementation output because the
interface will be unknown, even when the interface library is referenced correctly.
One method of fixing this error is to create a dummy class that implements the
interface and place it in the interface assembly. By setting the ClassInterface
attribute to ClassInterfaceType.None , no class interface will be generated and the
dummy class will only be visible through late-binding. The purpose of the dummy
class is to force COM output registration for the interface assembly so that it is
available to the implementation assembly when it registers for COM output.
If you do not wish to support remoting, you can pair the interface and imple-
mentation together, but keep in mind that you need to be committed to the archi-
tecture you choose. Going back to separate the interface into a separate assembly
would be much more difficult than doing it right from the get-go.
Here is the interface for the tool-specific code, along with attributes for COM
public interface IAlertObjectToolLogic