469,133 Members | 1,065 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 469,133 developers. It's quick & easy.

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
Nov 15 '05 #1
4 3763
Have you tried using - [ClassInterface(ClassInterfaceType.AutoDual)]
"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

Nov 15 '05 #2
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
Nov 15 '05 #3
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**************@tk2msftngp13.phx.gbl...
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

Nov 15 '05 #4
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 "Comprehensive VB .NET Debugging"
http://www.apress.com/book/bookDisplay.html?bID=128
"yoz" <netfever@hot_REMOVE_SPAM_mail.com> wrote in message
news:%U*******************@news-binary.blueyonder.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**************@tk2msftngp13.phx.gbl...
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


Nov 15 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

9 posts views Thread by Pierre Barbier de Reuille | last post: by
5 posts views Thread by TruongLapVi | last post: by
26 posts views Thread by Marius Horak | last post: by
reply views Thread by cs_hart | last post: by
reply views Thread by Michelangelo | last post: by
11 posts views Thread by Wayne Pedersen | last post: by
reply views Thread by zhoujie | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.