The docs say that when exposing .NET classes to COM, the best attribute to
use is  <ClassInterface(ClassInterfaceType.None)>.  What this means is that
your class has to explicitly define a class interface.  Unfortunately, VB
doesn't support implicit interface implementation, which makes creating a
single exposed interface to COM a tad tedious to do. as well as eliminating
90% of the reason for using inheritance in the first place.  In C# this
isn't a problem due to it's ability to implicitly implement an interface.

I did come up with a way to do what I want, but I consider it hackish and
{*filter*}ugly and  I cannot see why the interop team or VB team cannot come up
with a better solution.

Below is an example of a base business object that implements some standard
properties and methods that all business objects share.  I then inherit from
it and create a Contact class that adds FirstName and LastName.  In  order
to expose this business object to COM so that there is only one interface
with all methods on it, I can either use
<ClassInterface(ClassInterfaceType.AutoDual)> which has problems, or use
<ClassInterface(ClassInterfaceType.None)> but then jump through a LOT of
hoops.

Imports System.Runtime.InteropServices
Public MustInherit Class BaseBusinessObject
    Protected m_isDirty As Boolean = False
    Protected m_isNew As Boolean = True
    Protected m_isDeleted As Boolean = False
    Public ReadOnly Property IsDirty()
        Get
            Return m_isDirty
        End Get
    End Property
    Public ReadOnly Property IsNew() As Boolean
        Get
            Return m_isNew
        End Get
    End Property
    Public ReadOnly Property IsDeleted() As Boolean
        Get
            Return m_isDeleted
        End Get
    End Property
    Public Sub Delete()
        m_isDeleted = True
    End Sub
End Class

<InterfaceType(ComInterfaceType.InterfaceIsDual)> _
Public Interface IContact
    ReadOnly Property IsDirty() As Boolean
    ReadOnly Property IsNew() As Boolean
    ReadOnly Property IsDeleted() As Boolean
    Sub Delete()
    Property FirstName() As String
    Property LastName() As String
End Interface

<ClassInterface(ClassInterfaceType.None)> _
Public Class Contact
    Inherits BaseBusinessObject
    Implements IContact

    Public Shadows ReadOnly Property IsNew() As Boolean Implements
IContact.IsNew
        Get
            Return MyBase.IsNew
        End Get
    End Property
    Public Shadows ReadOnly Property IsDirty() As Boolean Implements
IContact.IsDirty
        Get
            Return MyBase.IsDirty
        End Get
    End Property
    Public Shadows ReadOnly Property IsDeleted() As Boolean Implements
IContact.IsDeleted
        Get
            Return MyBase.IsDeleted
        End Get
    End Property
    Public Shadows Sub Delete() Implements IContact.Delete
        MyBase.Delete()
    End Sub
    Public Property FirstName() As String Implements IContact.FirstName
        Get

        End Get
        Set(ByVal Value As String)

        End Set
    End Property
    Public Property LastName() As String Implements IContact.LastName
        Get

        End Get
        Set(ByVal Value As String)

        End Set
    End Property
End Class

As you can see, I have to basically shadow and reimplement the base class's
methods and properties.  At this point, why bother using inheritance at all
as it buys the debeloper very little but causes a lot of grief.

Microsoft really needs to fix this or a serious constraint on VB's ability
to interoperate with COM exists.

Uhhh, No.

--

  inline

  > Well, it appears that VB.NET users are at an extreme disadvantage when
  > moving to .NET ***IF*** they expect to make use of both COM Interop AND
  > class inheritance.
  >
  > The docs say that when exposing .NET classes to COM, the best attribute to
  > use is  <ClassInterface(ClassInterfaceType.None)>.  What this means is
  that
  > your class has to explicitly define a class interface.  Unfortunately, VB
  > doesn't support implicit interface implementation, which makes creating a

  This is a VB.NET design decision to make the interface implementation
  explicit. It has some advantages (it's absolutely clear which interface
  contract a method/property satisfies) but it could seem strange to someone
  who is used to C++ inheritance.

  > single exposed interface to COM a tad tedious to do. as well as
  eliminating
  > 90% of the reason for using inheritance in the first place.  In C# this

  The main reason for interface implementation is to provide a contract. The
  implementer of the interface satisfies a set of functionality required by a
  consumer. Inheritance is used to provide polymorphism or to reuse an
  implementation. In this case since we are talking about interfaces, the
  former usage applies. The runtime provides full support for interface
  inheritance including multiple interface inheritance whereas IDL only
  provides support for single interface inheritance. It would be difficult for
  interop to accurately map multiple interface inheritance.

  > isn't a problem due to it's ability to implicitly implement an interface.
  >
  > I did come up with a way to do what I want, but I consider it hackish and
  > {*filter*}ugly and  I cannot see why the interop team or VB team cannot come up
  > with a better solution.

  To give COM consumers of your components the best COM experience you should
  define your interfaces in IDL, compile them with MIDL, import them using
  tlbimp, and implement these imported interfaces in your managed component.

  > As you can see, I have to basically shadow and reimplement the base
  class's
  > methods and properties.  At this point, why bother using inheritance at
  all
  > as it buys the debeloper very little but causes a lot of grief.

  I hope this gives you some understanding why these design decisions were
  maid. As you can see there are several ways to produce a functionality that
  you required.

Sam