Which PInvokes aren't supported in C# or managed code?

[Scottie_do]

I've heard from the CDO team that managed code is unsupported. With a site
like www.pinvoke.net it's possible that I'll easily end up with a faulty
application architecture that will require a rewrite after I write the darn
thing.

I would like to know what are the circumstances that make interop
unsupported (as in CDO), and what other API's aren't supported under PInvoke.

-Chris LaMont

Contact me here:
lamont
(_at__)
dcpromo
(~dot~)
com

[Peter Bromberg [C# MVP]]

Chris,
we might be confusing P/Invoke with COM interop here. CDO is a COM Server
for MAPI. You can set a COM -tab reference to the "Microsoft CDO 1.21
Library" (or whatever version you have) and Visual Studio will generate a
Runtime Callable Wrapper for it.
Peter

--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com


"Scottie_do" wrote:

I've heard from the CDO team that managed code is unsupported. With a site
like www.pinvoke.net it's possible that I'll easily end up with a faulty
application architecture that will require a rewrite after I write the darn
thing.

I would like to know what are the circumstances that make interop
unsupported (as in CDO), and what other API's aren't supported under PInvoke.

-Chris LaMont

Contact me here:
lamont
(_at__)
dcpromo
(~dot~)
com

[Nicholas Paldino [.NET/C# MVP]]

I don't think you heard that. The classes for mail in the
System.Web.Mail namespace use CDO through interop (through reflection) in
order to send mail.

There isn't that much that makes interop unsupported. I would recommend
reading on how interop works, and then you can make the determination for
yourself.

A good place to start is the interop section of the advanced development
issues section of the .NET framework documentation, found at (watch for line
wrap):

http://msdn2.microsoft.com/ms172270(en-US,VS.80).aspx

Hope this helps.
--
- Nicholas Paldino [.NET/C# MVP]
- mv*@spam.guard.caspershouse.com

"Scottie_do" <Sc*******@discussions.microsoft.com> wrote in message
news:95**********************************@microsof t.com...

I've heard from the CDO team that managed code is unsupported. With a
site
like www.pinvoke.net it's possible that I'll easily end up with a faulty
application architecture that will require a rewrite after I write the
darn
thing.

I would like to know what are the circumstances that make interop
unsupported (as in CDO), and what other API's aren't supported under
PInvoke.

-Chris LaMont

Contact me here:
lamont
(_at__)
dcpromo
(~dot~)
com

[Scottie_do]

Thank you, I did confuse Pinvoke with COM Interop. I'll need to study more
so I can see why CDO will not work with C#. Check out
win32.programmer.messaging if you want to read threads about this
incompatibility

-Chris

"Scottie_do" wrote:

I've heard from the CDO team that managed code is unsupported. With a site
like www.pinvoke.net it's possible that I'll easily end up with a faulty
application architecture that will require a rewrite after I write the darn
thing.

I would like to know what are the circumstances that make interop
unsupported (as in CDO), and what other API's aren't supported under PInvoke.

-Chris LaMont

Contact me here:
lamont
(_at__)
dcpromo
(~dot~)
com

[Ignacio Machin \( .NET/ C# MVP \)]

Hi,

"Scottie_do" <Sc*******@discussions.microsoft.com> wrote in message
news:95**********************************@microsof t.com...

I've heard from the CDO team that managed code is unsupported.
Probably he meant that they did not solve support question regarding using
the CDO in managed code, not that CDO cannot be used in managed code.
With a site
like www.pinvoke.net it's possible that I'll easily end up with a faulty
application architecture that will require a rewrite after I write the
darn
thing.
Why?
If the function in question is called correctly you should have no problem,
the function would not change, if so all applications that use it would
cease to work.
I would like to know what are the circumstances that make interop
unsupported (as in CDO), and what other API's aren't supported under
PInvoke.

CDO are not part of the Win32 API IIRC, they are COM objects so you can use
them directly in your project by adding a reference to it frmo VS

AFAIK almost all of the API are usable through P/Invoke, not easyly though.
IF you have a very complex structure it's difficult to create a managed
version and marshall it back and forth.
Also IIRC if the API requires a callback you cannot use it , not sure of
this though. anyone care to clarify it?

--
Ignacio Machin,
ignacio.machin AT dot.state.fl.us
Florida Department Of Transportation

[Willy Denoyette [MVP]]

Inline
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:ux**************@TK2MSFTNGP14.phx.gbl...
| Hi,
|
| "Scottie_do" <Sc*******@discussions.microsoft.com> wrote in message
| news:95**********************************@microsof t.com...
| > I've heard from the CDO team that managed code is unsupported.
|
| Probably he meant that they did not solve support question regarding using
| the CDO in managed code, not that CDO cannot be used in managed code.
|
| >With a site
| > like www.pinvoke.net it's possible that I'll easily end up with a faulty
| > application architecture that will require a rewrite after I write the
| > darn
| > thing.
|
| Why?
| If the function in question is called correctly you should have no
problem,
| the function would not change, if so all applications that use it would
| cease to work.

Beware the undocumented API's, they can be changed/removed at any time. In
my long carrier I've seen a lot of people calling API's they 'discovered' by
tools like depends etc.., I've seen a lot of code breaking also ;-)
|
| > I would like to know what are the circumstances that make interop
| > unsupported (as in CDO), and what other API's aren't supported under
| > PInvoke.
|
| CDO are not part of the Win32 API IIRC, they are COM objects so you can
use
| them directly in your project by adding a reference to it frmo VS
|

As from W2K on, CDO (cdosys.dll) is part of the OS API set, this is the
component used by System.Web.Mail.
The problem is that there are other CDO's as well, there is CDO 1.21 (and
older versions) and there is the CDO version that comes with exchange server
(the client stuff). All are COM servers, some are "clients type" of COM
server components (they should never be used in server environments like
service, asp.net etc...) others are server style (like cdosys.dll and the
exchange CDO DLL's).

| AFAIK almost all of the API are usable through P/Invoke, not easyly
though.
| IF you have a very complex structure it's difficult to create a managed
| version and marshall it back and forth.
| Also IIRC if the API requires a callback you cannot use it , not sure of
| this though. anyone care to clarify it?
|

Callbacks are no problem AFAIK, the only problem with v1.x is that the
calling convention is stdcall by default (like all callbacks should use in
windows), while some badly written C 'callbacks' are using cdecl. This
problem is solved in v2.0 where you have the possibilty to change the
default from stdcall to cdecl or whatever.

Willy.

[Scottie_do]

I'm trying to read more about callbacks, cdecl and stdcall, because I have no
idea what they are. Any pointers about where I can find more info? I'm
betting they are like a C# delegate.

"Willy Denoyette [MVP]" wrote:

Inline
"Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote
in message news:ux**************@TK2MSFTNGP14.phx.gbl...
| Hi,
|
| "Scottie_do" <Sc*******@discussions.microsoft.com> wrote in message
| news:95**********************************@microsof t.com...
| > I've heard from the CDO team that managed code is unsupported.
|
| Probably he meant that they did not solve support question regarding using
| the CDO in managed code, not that CDO cannot be used in managed code.
|
| >With a site
| > like www.pinvoke.net it's possible that I'll easily end up with a faulty
| > application architecture that will require a rewrite after I write the
| > darn
| > thing.
|
| Why?
| If the function in question is called correctly you should have no
problem,
| the function would not change, if so all applications that use it would
| cease to work.

Beware the undocumented API's, they can be changed/removed at any time. In
my long carrier I've seen a lot of people calling API's they 'discovered' by
tools like depends etc.., I've seen a lot of code breaking also ;-)
|
| > I would like to know what are the circumstances that make interop
| > unsupported (as in CDO), and what other API's aren't supported under
| > PInvoke.
|
| CDO are not part of the Win32 API IIRC, they are COM objects so you can
use
| them directly in your project by adding a reference to it frmo VS
|

As from W2K on, CDO (cdosys.dll) is part of the OS API set, this is the
component used by System.Web.Mail.
The problem is that there are other CDO's as well, there is CDO 1.21 (and
older versions) and there is the CDO version that comes with exchange server
(the client stuff). All are COM servers, some are "clients type" of COM
server components (they should never be used in server environments like
service, asp.net etc...) others are server style (like cdosys.dll and the
exchange CDO DLL's).

| AFAIK almost all of the API are usable through P/Invoke, not easyly
though.
| IF you have a very complex structure it's difficult to create a managed
| version and marshall it back and forth.
| Also IIRC if the API requires a callback you cannot use it , not sure of
| this though. anyone care to clarify it?
|

Callbacks are no problem AFAIK, the only problem with v1.x is that the
calling convention is stdcall by default (like all callbacks should use in
windows), while some badly written C 'callbacks' are using cdecl. This
problem is solved in v2.0 where you have the possibilty to change the
default from stdcall to cdecl or whatever.

Willy.