IDispatch definition in C#

[Phil Coveney]

Hello,

I am implementing a class in C# that wraps an automation server and am
stuck on something basic. Using the following code fragment:

using System;
using System.Runtime. InteropServices ;

namespace ANamespace
{
public class Wrapper
{
private IDispatch* m_Server;

public Wrapper()
{};
}
}

the compiler complains

Wrapper.cs(70): The type or namespace name 'IDispatch' could not be found
(are you missing a using directive or an assembly reference?)

I suspect I am missing something, but I don't know from where to pull the
IDispatch definition in.

Any help is appreciated.

Phil Coveney

[Mattias Sjögren]

> I suspect I am missing something, but I don't know from where to pull the

IDispatch definition in.

Why do you need it? Why not simply

private object m_Server;
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Phil Coveney]

Mattias,

Why do you need it? Why not simply
private object m_Server; Fair enough. In fact, that's what I have been doing to make progress on
this project while I am resolving this. And, if this is Microft's intention
for C# developers, I guess that's what I'll do.

But two things trouble me about this.
First, (I think) it implies that I store all standard COM interface
references in object variables. It seems to me unnecessarily hiding
information about the variable's type. One could extend this logic, I
suppose, and note that I could store integer values in object variables,
which I think we can agree would not be good practice.
Second, since I can store references to .NET interfaces, this (I think)
implies I would develop my class distinguishing between standard COM
interfaces, and typelib-imported + non-COM iterfaces. If I change the
provider of a COM interface service from a COM to a non-COM service, does it
mean I change how I store the reference?

OK, I'm not trying to start a deep philosophy discussion. It just seems
strange that Microsoft would thoughtfully prevent the definition of its core
interfaces from being visible to .NET class designers. I am just trying to
understand its rationale.

Thanks for your help,

Phil Coveney

[Mattias Sjögren]

Phil,

t seems to me unnecessarily hiding
information about the variable's type.
Unless you're going to use any type specific functionality (ie
IDispatch methods) I don't see that as a problem.

OK, I'm not trying to start a deep philosophy discussion. It just seems
strange that Microsoft would thoughtfully prevent the definition of its core
interfaces from being visible to .NET class designers.

They don't prevent it, you can declare and use IDispatch if you really
have a reason to. If you do, the field declaration becomes

private IDispatch m_Server;

(not IDispatch*).
Mattias

--
Mattias Sjögren [MVP] mattias @ mvps.org
http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com
Please reply only to the newsgroup.

[Phil Coveney]

OK, thanks Mattias.