It's clear that in spite of the arrival of .NET, VB.Classic applications are still going to be around for a long time. Moving a company's business applications from VB.Classic to VB .NET is simply not a
This chapter first provides an overview of the very different ways in which COM and .NET view the world. It then looks at debugging Interop with a COM component written in VB 6.0 and called by a VB .NET application. Next is an investigation of debugging Interop with a VB .NET component called by a VB 6.0 application. Finally, you'll look at some of the finer details of debugging COM Interop applications.
You can use either VB 5.0 or VB 6.0 projects with VB .NET, but I recommend using VB 6.0 exclusively if possible. One problem is that the debug symbol files produced by VB 5.0 can cause difficulties when you try to view VB 5.0
I recommend using VB 6.0 with the latest service pack applied, SP5 at the time of writing. With this combination, I haven't
If you're using Windows NT 4.0 as your operating system, you'll need to install NT 4.0 SP4 or higher. You won't be able to debug VB 6.0 components from VB .NET without this.
Before you delve deeply into COM Interop, it's a good idea to understand the completely different views that managed and unmanaged code have of the world. When you have a good understanding of these two views and where they agree and
The following list
Coding model: The managed world uses an object-based view of code, whereas the COM world thinks of code in terms of interfaces. This means that Interop has to generate an interface to expose managed code to the unmanaged world, unless the managed code already provides such an interface.
Error handling: The usual COM practice is to return an HRESULT to signify whether a method has succeeded or failed. VB 6.0 developers get a break here because they're already used to the practice of raising errors using the Err object. COM Interop maps VB 6.0 errors to .NET exceptions, and it maps .NET exceptions to VB 6.0 errors.
Identities:
COM uses globally unique identifiers (GUIDs) to identify unmanaged types and interfaces, whereas .NET uses strong names, which uniquely identify assemblies and managed types. COM Interop can generate GUIDs for .NET assemblies and strong
Type compatibility: Although some managed and unmanaged types are compatible, others are not. Fortunately there are .NET attributes that can solve most type compatibility problems.
Type definitions: A COM type library is optional and only contains public types, whereas .NET metadata is mandatory and describes both public and private types. COM Interop is quite successful at converting between type libraries and metadata.
Versioning:
VB 6.0 allows you to extend interfaces without breaking binary compatibility, but COM interfaces are
In this chapter I point out some of the issues raised by these two very different views of the world and discuss how you avoid or work around them.