How do you translate IDL into C#?

Question

For example, the DOM specification has various IDL definitions , one of which is the Interface Node . How would you go about translating this—even a portion of this—into actual C#? I mean, where would you even start? As far as I understand, C#'s interfaces behave much differently than what IDL is calling an interface here. Am I wrong?

interface Node {

  // NodeType
  const unsigned short      ELEMENT_NODE                   = 1;
  const unsigned short      ATTRIBUTE_NODE                 = 2;
  const unsigned short      TEXT_NODE                      = 3;
  const unsigned short      CDATA_SECTION_NODE             = 4;
  const unsigned short      ENTITY_REFERENCE_NODE          = 5;
  const unsigned short      ENTITY_NODE                    = 6;
  const unsigned short      PROCESSING_INSTRUCTION_NODE    = 7;
  const unsigned short      COMMENT_NODE                   = 8;
  const unsigned short      DOCUMENT_NODE                  = 9;
  const unsigned short      DOCUMENT_TYPE_NODE             = 10;
  const unsigned short      DOCUMENT_FRAGMENT_NODE         = 11;
  const unsigned short      NOTATION_NODE                  = 12;

  readonly attribute DOMString       nodeName;
           attribute DOMString       nodeValue;
                                        // raises(DOMException) on setting
                                        // raises(DOMException) on retrieval

  readonly attribute unsigned short  nodeType;
  readonly attribute Node            parentNode;
  readonly attribute NodeList        childNodes;
  readonly attribute Node            firstChild;
  readonly attribute Node            lastChild;
  readonly attribute Node            previousSibling;
  readonly attribute Node            nextSibling;
  readonly attribute NamedNodeMap    attributes;
  // Modified in DOM Level 2:
  readonly attribute Document        ownerDocument;
  // Modified in DOM Level 3:
  Node               insertBefore(in Node newChild, 
                                  in Node refChild)
                                        raises(DOMException);
  // Modified in DOM Level 3:
  Node               replaceChild(in Node newChild, 
                                  in Node oldChild)
                                        raises(DOMException);
  // Modified in DOM Level 3:
  Node               removeChild(in Node oldChild)
                                        raises(DOMException);
  // Modified in DOM Level 3:
  Node               appendChild(in Node newChild)
                                        raises(DOMException);
  boolean            hasChildNodes();
  Node               cloneNode(in boolean deep);
  // Modified in DOM Level 3:
  void               normalize();
  // Introduced in DOM Level 2:
  boolean            isSupported(in DOMString feature, 
                                 in DOMString version);
  // Introduced in DOM Level 2:
  readonly attribute DOMString       namespaceURI;
  // Introduced in DOM Level 2:
           attribute DOMString       prefix;
                                        // raises(DOMException) on setting

  // Introduced in DOM Level 2:
  readonly attribute DOMString       localName;
  // Introduced in DOM Level 2:
  boolean            hasAttributes();
  // Introduced in DOM Level 3:
  readonly attribute DOMString       baseURI;

  // DocumentPosition
  const unsigned short      DOCUMENT_POSITION_DISCONNECTED = 0x01;
  const unsigned short      DOCUMENT_POSITION_PRECEDING    = 0x02;
  const unsigned short      DOCUMENT_POSITION_FOLLOWING    = 0x04;
  const unsigned short      DOCUMENT_POSITION_CONTAINS     = 0x08;
  const unsigned short      DOCUMENT_POSITION_CONTAINED_BY = 0x10;
  const unsigned short      DOCUMENT_POSITION_IMPLEMENTATION_SPECIFIC = 0x20;

  // Introduced in DOM Level 3:
  unsigned short     compareDocumentPosition(in Node other)
                                        raises(DOMException);
  // Introduced in DOM Level 3:
           attribute DOMString       textContent;
                                        // raises(DOMException) on setting
                                        // raises(DOMException) on retrieval

  // Introduced in DOM Level 3:
  boolean            isSameNode(in Node other);
  // Introduced in DOM Level 3:
  DOMString          lookupPrefix(in DOMString namespaceURI);
  // Introduced in DOM Level 3:
  boolean            isDefaultNamespace(in DOMString namespaceURI);
  // Introduced in DOM Level 3:
  DOMString          lookupNamespaceURI(in DOMString prefix);
  // Introduced in DOM Level 3:
  boolean            isEqualNode(in Node arg);
  // Introduced in DOM Level 3:
  DOMObject          getFeature(in DOMString feature, 
                                in DOMString version);
  // Introduced in DOM Level 3:
  DOMUserData        setUserData(in DOMString key, 
                                 in DOMUserData data, 
                                 in UserDataHandler handler);
  // Introduced in DOM Level 3:
  DOMUserData        getUserData(in DOMString key);
};

Answer 1

Background

In C#, an interface is by definition empty and has many possible implementations. In COM, in general, an interface will have one implementation and defines a calling contract, not an implementation contract (like with web services or CORBA). In C#, the implementation of an interface is .NET specific. In COM, the implementation of an interface is a language-neutral, but a binary implementation (as opposed to SOAP messages, which is textual/XML). This binary definition has always been food for criticasters of COM and the slow (if at all) adoption of COM on non-Windows systems (again, as opposed to web services).

For practically all IDL commands, there's an equivalent possibility in C#, albeit not always within just in interface. The base interface of COM is always IUknown , which is used for object reference counting, which must be included by all COM objects.

In speech, when talking about a COM interface, you usually talk about an implementation. In c#, you usually talk about the empty contracts that callers and implementers understand.

Translate IDL

The IDL above is for DOM, as you mention. The DOM is implemented in C# and is much more powerful than its COM cousins (and many versions). If you really want to create a C# class wrapper that can call the COM DOM interfaces:

• use MIDL (comes with Visual Studio) to create a TLB,
• then run tlbimp.exe (comes with .NET) to create a .NET COM wrapper, which you can include in your project.

You can also run tlbimp.exe directly on the COM dlls (in process) or executables (out of process) to create a .NET COM Wrapper.

More information

A basic, yet extremely brilliant and thorough introduction to COM is Don Box's famous book Essential COM , about IDL I suggest Essential IDL by Gudgin .

Absolutely everything there is to know about COM and .NET is written down in the comprehensive, yet slightly bloated, .NET and .COM The Complete Interoperability Guide by Nathan. Not a book you will read from cover to cover, but it makes excellent reference material.