Interface inheritence and COM

[yoz]

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

[Pramod Anchuparayil]

Have you tried using - [ClassInterface( ClassInterfaceT ype.AutoDual)]
"yoz" <ne******@hotma il.com> wrote in message
news:21******** *************** ***@posting.goo gle.com...

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

[Mark Pearce]

Hi Yoz,

When you look at the .NET class that's exposed to COM, what is its
ClassInterfaceT ype attribute set to? This is one way of controlling
versioning issues when a COM client consumes a .NET component.

ClassInterfaceT ype.AutoDispatc h 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.

ClassInterfaceT ype.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.

ClassInterfaceT ype.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 "Comprehens ive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <ne******@hotma il.com> wrote in message
news:21******** *************** ***@posting.goo gle.com...
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

[yoz]

OK I think I understand what C# wants.

I created an interface, and implemented it in the class to export. C#,
however, creates an "_" (underscore) interface for each object, and instead
of deriving interaces it put the whole ancestry public methods and
properties in every interface. The problem is that you cannot specify the
GUID of the "_" interface so it changes everytime you compile. Thus that is
why late binding always work, however application need to be recompile if my
..NET COM Module is compile with early binding.

Do I got it right?

I am sorry to sound ignorant but if it is, why can't you keep the same GUID?
Is that a design feature because I find it very stupid... I come from
Delphi, but I remember VB guys I work with told me that VB6 also change the
GUID at every compile but I was also told you can stop that.... Is there a
way to stop that under C#?

"Mark Pearce" <ev**@bay.com > wrote in message
news:Oa******** ******@tk2msftn gp13.phx.gbl...

Hi Yoz,

When you look at the .NET class that's exposed to COM, what is its
ClassInterfaceT ype attribute set to? This is one way of controlling
versioning issues when a COM client consumes a .NET component.

ClassInterfaceT ype.AutoDispatc h 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.

ClassInterfaceT ype.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.

ClassInterfaceT ype.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 "Comprehens ive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <ne******@hotma il.com> wrote in message
news:21******** *************** ***@posting.goo gle.com...
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

[Mark Pearce]

Hi Yoz,

Look at the GuidAttribute design-time attribute in the MSDN documentation.
This attribute allows you to specify a guid for a class, interface or
complete type library, and this guid can be kept even when you change your
interface.

HTH,

Mark
--
Author of "Comprehens ive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <netfever@hot_R EMOVE_SPAM_mail .com> wrote in message
news:%U******** ***********@new s-binary.blueyond er.co.uk...
OK I think I understand what C# wants.

I created an interface, and implemented it in the class to export. C#,
however, creates an "_" (underscore) interface for each object, and instead
of deriving interaces it put the whole ancestry public methods and
properties in every interface. The problem is that you cannot specify the
GUID of the "_" interface so it changes everytime you compile. Thus that is
why late binding always work, however application need to be recompile if my
..NET COM Module is compile with early binding.

Do I got it right?

I am sorry to sound ignorant but if it is, why can't you keep the same GUID?
Is that a design feature because I find it very stupid... I come from
Delphi, but I remember VB guys I work with told me that VB6 also change the
GUID at every compile but I was also told you can stop that.... Is there a
way to stop that under C#?

"Mark Pearce" <ev**@bay.com > wrote in message
news:Oa******** ******@tk2msftn gp13.phx.gbl...

Hi Yoz,

When you look at the .NET class that's exposed to COM, what is its
ClassInterfaceT ype attribute set to? This is one way of controlling
versioning issues when a COM client consumes a .NET component.

ClassInterfaceT ype.AutoDispatc h 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.

ClassInterfaceT ype.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.

ClassInterfaceT ype.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 "Comprehens ive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <ne******@hotma il.com> wrote in message
news:21******** *************** ***@posting.goo gle.com...
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