One of the goals of COM interopability is (to paraphrase slightly) 'that
either the client or the server portion of existing applications can be
upgraded to .NET independently without impacting the functionality of the

Bearing this in mind I created a simple VB6 client and server and after
learning a bit about COM interop attributes was able to replace the
VB6 server with a VB7 server. After running RegAsm.exe the VB6 client used
the VB7 server without any change whatever - certainly no need for a
recompilation. Top marks for .NET developers!

I had a lot more trouble with my second example where the VB6 server I was
replacing used a VB6 collection; surely a very likely case in practice.
Here is the code of my example server followed by the Form.Load method
of the trivial client which will show 'Greetings from V6' in the
labresult label of its only form. This in turn is followed by the IDL
of V6Server.dll' s type library as displayed by oleview.exe

-----------------------------------V6Server Create.cls
Option Explicit

Public Function Results() As Collection
Dim col As New Collection
col.Add "Greetings from V6"
Set Results = col
End Function

------------------------------------V6Client FClient.frm

Private Sub Form_Load()
Dim svr As New V6Server.Create
Dim col As Collection
Set col = svr.Results
labResults = col(1)
End Sub

-------------------------------------IDL from V6Server.dll

// Generated .IDL file (by the OLE/COM Object Viewer)
// typelib filename: V6Server.dll

library V6Server
// TLib : // TLib : OLE Automation :
// TLib : Visual Basic For Applications :

// Forward declare all types defined in this typelib
interface _Create;

interface _Create : IDispatch {
HRESULT Results([out, retval] _Collection** );

coclass Create {
[default] interface _Create;
When I had got this far I realised that the V7 server project would need
to make a COM reference to MSVBVM60.DLL ie VBA version 6. Here is the
code that eventually succesfully replaced VB6Server.dll and, after RegAsm
caused VB6Client to show the message 'Greetings from VB7' in its label.
(Note how MSVBVM60.DLL has been imported as assembly VBA)

<Assembly: System.Runtime.InteropServices.GUID _
Imports System.Runtime.InteropServices

Interface <GUID("5625567F-5568-4DC5-A010-6D22496B0E5F")> _Create
Function Results() As VBA._Collection
End Interface

Public Class <HasDefaultInterface(), _
GUID("DD5C041B-73E8-467D-9E4D-F378E37B65F1")> Create
Implements _Create
Public Function Results() As VBA._Collection Implements _Create.Results
Dim srv As New V7Helper.CMake() 'THIS IS LAME
Dim col As VBA._Collection = srv.NewCol 'AND SO IS THIS
col.Add("Greetings from V7")
Return col
End Function
End Class

Now, really the two lines commented 'THIS IS LAME AND SO IS THIS' are
subject of this note. There didn't seem to be anything strange about
VBA.Collection as far as the browser was concerned and the compiler
happily compiled
Dim coln As New VBA.Collection()
Dim col As VBA._Collection = CType(coln, VBA._Collection)
which I would have liked to use in their place. However, when run, the
first line suffers:

System.Runtime.InteropServices.COMException: Class not registered

but if you look for the CLSID in the registry it seems to be there OK:

"Assembly"="VBA, Ver=, Loc=\"\", SN=null"

I've tried hacking the registry a bit to no avail so I gave up and wrote
VSHelper.dll in VB6 then made it a COM reference.

---------------------------------------V7Helper.dll CMake.cls----------
Public Function NewCol() As Collection
Dim col As New Collection
Set NewCol = col
End Function

So the question I raise is 'Is there a better way of doing this?' or is
there one planned for when VB7 ships?