Hi Yoz,
When you look at the .NET class that's exposed to COM, what is its
ClassInterfaceType attribute set to? This is one way of controlling
versioning issues when a COM client consumes a .NET component.
ClassInterfaceType.AutoDispatch is the default. It is friendly about COM
versioning, but at the cost of allowing only late-bound COM clients and
potential bugs that won't be found until run-time. Your COM client will be
late-bound. This may be what you're seeing currently.
ClassInterfaceType.AutoDual allows early-bound COM clients and compile-time
checking, but completely ignores COM versioning, meaning that you should
(and may have to) recompile your COM clients every time the .NET component
is changed.
ClassInterfaceType.None together with a separation of the class interface
from its implementation gives you the best of both worlds: early binding and
compile-time checking together with the flexibility to change the .NET
component. I believe that there's an example in the docs that shows you how
to do this.
HTH,
Mark
--
Author of "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <ne******@hotmail.com> wrote in message
news:21**************************@posting.google.c om...
Hi everyone,
I wonder if you can shed some light on a problem I have. I am
exporting a C# .Net set of classes to COM. All of it is exported
properly but the interface inheritences are not in the type library.
for example:
public interface IA
{
void proc1();
}
public interface IB: IA
{
void proc2();
}
In the type library IA and IB BOTH descend from IDispatch. Is there an
attribute to say that when tlbexp.exe generate the type library, it
makes IB descend from IA?
Regards