The  (parenthesized references)  in this list are explained  here.  

ActiveX Controls

You import these two ways:

• With the command-line tool,  aximp.   You will never do this,  because it does not set up an entry in the toolbox,  and you would have to do all the fussing around to position the control that Kalani does on pages 645 and 646.
• Import the ActiveX control into the .NET IDE's Toolbox by using the Toolbox's  Customize Toolbox  option.
• Incidentally,  the class used to provide this communication between .NET and ActiveX controls is  AxHost.   It is a "wrapper" class.

• You can use legacy code without rewriting.

• It's slower.
• There are some name changes,  such as that for a member named "State",  which will be changed to "CtlState".
• ActiveX controls are not managed code,  and you do not have all the services that .NET's code management gives you:  garbage collection,  memory management,  versioning,  security.
• It is harder to deploy an app that uses such ActiveX controls,  because you must worry about their presence or absence on the target machine.

Using COM Components

You need to get a proxy,  specifically,  the Runtime Callable Wrapper  (RCW),  so that COM objects will appear to .NET as if they are running in managed code.   Fortunately,  COM has metadata that can be accessed.

There are two ways to create this RCW:

First,  with a command-line tool,  tlbimp.exe,  the Type Library Importer.

• Sample call:

      tlbimp MyCustomer.dll /out:NETMyCustomer.dll

• This creates a library,  each class is now available to .NET as a class.   You add a reference to this library in the Solution Explorer,  and add a "using" directive for it at the top of your program.   You can then instantiate the COM classes with,  say,  new.
• The  tlbimp.exe  tool has command-line options,  some of which will come up in a later chapter.   The one that is important now is
  •   /primary,  which produces a Primary Interop Assembly,  which is one of the main ways that you would deliver a compiled and linked system to a customer.   (Go ahead—just ask Mr. Holley if he's ever used one.)

• In the Solution Explorer,  add a reference to the COM DLL you want.
  • Such a DLL must be registered.
  • If it isn't registered,  you can register it with the command-line routine

            regsvr32 MyOwn.dll

  • Kalani doesn't mention a  using directive if you do this.   Is one needed?
  • Troelsen  (page 680 in the 1st edition)  says that the .NET  "Add Reference"  operation automatically runs   tlbimp.exe  and stores the result in your Debug or Release folder.

• Use direct reference if you're only going to use the COM component in a single .NET app.
• If the COM component will be shared,  it should be signed and placed in the GAC.   (This comes up again in a later chapter.)
• You must use  tlbimp.exe  if you need to control details of the operation,  such as name,  namespace,  or version number,  or if you want to create a Primary Interop Assembly.

Using COM+ Components

These are "serviced" components.   They are handled by .NET exactly the same as COM components.

Platform Invoke  ("PInvoke")

This is a way of calling routines in  unmanaged  libraries,  such as the Windows API.   There are a couple of aspects to this:   (Kalani, page 663)

• You add attributes and method declarations to your class,  such as

       [DllImport("kernel32.dll",  CharSet=CharSet.Auto)]
      public static extern int GetComputerName(
        StringBuilder buffer,  ref uint size);

• The  DllImport  attribute tells your routine where to find the  extern  routine you're calling.
• The  DllImport  class has various properties,  such as
  • CharSet,  whose choices are
    • CharSet.Ansi   (the default)
    • CharSet.Auto  
    • CharSet.Unicode   (the default)
    • CharSet.None   (obsolete)
  • ExactSpelling.   Should the name of the entry point you specify match the name of the unmanaged function exactly?   The default is,  unexpectedly enough,  false.
• Names for called routines:  some Windows API functions come in two versions,  such as  versionA  for ANSI characters,  or  versionW  for Unicode.   ("W" stands for "wide character",  in case you were wondering.)   If your routine just calls  version,  you may want to let the system decide which actual routine to invoke.   That's why the  ExactSpelling property's default is  false.
• You must get the calling sequences and passed-in structures exactly right,  sometimes going so far as to specify things like   (Kalani,  page 665)

       [StrucLayout(LayoutKind.Explicit)]
      public struct Rect
      {
        [FieldOffset(0)] public Int32 left;
        [FieldOffset(4)] public Int32 top;
        [FieldOffset(8)] public Int32 right;
        [FieldOffset(12)] public Int32 bottom;
      }

• You must pass in a  StringBuilder object if a string buffer is expected by the called routine.

    [DllImport("kernel32.dll",  CharSet=CharSet.Auto)]
    public static extern int GetComputerName(
      StringBuilder buffer,  ref uint size);

    Test 1:  questions  39  (page 374;  answer:  page 396),  46.

    Test 2:  questions  6  (page 406;  answer:  page 439),  32,  33.

• Test 2,  question 6 is very interesting.   In fact,  you really should answer this question before you look at the book's choices:  "Just what is so interesting about this question"?

(Some of these questions may duplicate those in long Kalani.   Both texts are listed here.)