I would like to implement a service in C#, and I would like clients
without even COM support to make calls to it. Clients have
LoadLibrary support. What is my best strategy?

TIA

Hello,

Thanks for your post. As I understand, you want to load a managed C#
service from a legacy clients by calling LoadLibrary. Please correct me if
there is any misunderstanding. I'd like to share the following information
with you:

We are not able to export function from managed program, because it
requires a valid consistent function to call into which .NET Framework does
not support. Managed code has no concept of a consistent value for a
function pointer because these function pointers are proxies that are built
dynamically.

To work around the problem you should use COM Interop to call .NET
Component from unmanged application. Please refer to the following articles
and sample:

COM Interop Sample: COM Client and .NET Server
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconcominteropsamplecomclientnetserver.asp

COM Interoperability in Visual Basic and Visual C#
http://msdn.microsoft.com/library/de...us/vbcon/html/
vbconcominteropinvisualbasicvisualc.asp

I look forward to your feedback.

Have a nice day!

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

(E-Mail Removed) (Tian Min Huang) wrote in message news:<(E-Mail Removed)>...
> ...
>
> We are not able to export function from managed program, because it
> requires a valid consistent function to call into which .NET Framework does
> not support. Managed code has no concept of a consistent value for a
> function pointer because these function pointers are proxies that are built
> dynamically.
>
> To work around the problem you should use COM Interop to call .NET
> Component from unmanged application. Please refer to the following articles
> and sample:
>
> COM Interop Sample: COM Client and .NET Server
> http://msdn.microsoft.com/library/de...us/cpguide/htm
> l/cpconcominteropsamplecomclientnetserver.asp
>
> COM Interoperability in Visual Basic and Visual C#
> http://msdn.microsoft.com/library/de...us/vbcon/html/
> vbconcominteropinvisualbasicvisualc.asp
> ...

You understand my question.

My best strategy, then, is to present the .NET component as a COM
service, then implement a Win32 DLL to bridge the inteface gap between
the COM and the client that can't do COM.

(E-Mail Removed) (Tian Min Huang) wrote in message news:<(E-Mail Removed)>...
> ... As I understand, you want to load a managed C#
> service from a legacy clients by calling LoadLibrary. Please correct me if
> there is any misunderstanding. I'd like to share the following information
> with you:
>
> We are not able to export function from managed program, because it
> requires a valid consistent function to call into which .NET Framework does
> not support. Managed code has no concept of a consistent value for a
> function pointer because these function pointers are proxies that are built
> dynamically.
>
....
Another strategy I just thought of is to write my wrapper in C++ and
used mixed-mode. Managed to get to the C# component and unmanged to
present the API to legacy clients. That would work, wouldn't it?

Hello,

Thanks for your reply. I am not sure why your client that can't do COM. If
it's a Visual C++ client application, you can call the COM component
directly as described in the following MSDN sample:

COM Interop Sample: COM Client and .NET Server
http://msdn.microsoft.com/library/de...us/cpguide/htm
l/cpconcominteropsamplecomclientnetserver.asp

In the meantime, I believe that the best strategy is to use VC++
implementing a Win32 DLL.

Please feel free to let me know if you have any problems or concerns.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

(E-Mail Removed) (Tian Min Huang) wrote in message news:<(E-Mail Removed)>...
> Hello,
>
> ... I am not sure why your client that can't do COM...
My client is a third-party tool with its own scripting language that
allows for extensions implemented in C DLLs. I don't have the source
code, so I have limited control over how this tool interfaces with
extensions.

Here's a similar kind of problem. Could you present a C# extension
usable in Word 2.0?

Hello,

Thanks for your information.

>> Could you present a C# extension usable in Word 2.0?
I appologize that I am not sure what you mean exactly, could you please
tell me more detailed information?

I am standing by for your reply.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.

(E-Mail Removed) (Tian Min Huang) wrote in message news:<(E-Mail Removed)>...
> Hello,
>
> Thanks for your information.
>
> >> Could you present a C# extension usable in Word 2.0?
> I appologize that I am not sure what you mean exactly, could you please
> tell me more detailed information?
> ...
I mean, suppose you have a program that was written in the 1980s. It
has a scripting language and is designed to support the Win32 APIs for
LoadLibrary and GetProcAddress, but does not have support for
CreateObject. I likened this to an old version of Word that had
WordBasic. Maybe not a good analogy.

I have such a tool. I can LoadLibrary and GetProcAddress, but I
cannot CreateObject. I am trying to hack together a way for .NET
component extnesions to this tool.

Hi,

Thanks a lot for your clarification. Since the client does not support COM
client, I agree with you that it would be better to create Win32 DLL to
bridge the inteface gap between the .NET component and your client.

Please feel free to let me know if any further I can help.

Regards,

HuangTM
Microsoft Online Partner Support
MCSE/MCSD

Get Secure! -- www.microsoft.com/security
This posting is provided "as is" with no warranties and confers no rights.