Access .NET dlls from unmanaged programs

[=?Utf-8?B?Sm9hY2hpbQ==?=]

Is it possible to access .NET dlls from unmanaged programs, e.g. if I have a
..NET dll implemented in C# which listens on a socket for requests from a
program written in unmanaged C++ or VB? Would it require any specific details
in the implementation or would it be just like an ordinary C# dll?

[Alberto Poblacion]

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:F9**********************************@microsof t.com...

Is it possible to access .NET dlls from unmanaged programs, e.g. if I have
a
.NET dll implemented in C# which listens on a socket for requests from a
program written in unmanaged C++ or VB? Would it require any specific
details
in the implementation or would it be just like an ordinary C# dll?

A .Net program an certainly be called from an unmanaged program using
some interprocess communication mechanism such as sockets, like you suggest.
However, a dll is not enough for this purpose. The dll needs to be hosted in
an .exe which "starts" it listening at the socket.

If you don't want to communicate with the dll via such a mechanism, but
rather you want to call it directly from unmanaged code, then, as far as I
know, the only way to do it is to go through COM. You would expose the .Net
dll as a COM object, and then consume it from C++ or VB6 like any other COM
object, disregarding the fact that it was written in .Net.

[Willy Denoyette [MVP]]

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:F9**********************************@microsof t.com...

Is it possible to access .NET dlls from unmanaged programs, e.g. if I have
a
.NET dll implemented in C# which listens on a socket for requests from a
program written in unmanaged C++ or VB? Would it require any specific
details
in the implementation or would it be just like an ordinary C# dll?

You need to use COM Interop, that is, you have to expose your managed
class(es) as COM objects (ComVisible=true), you also need to make your
objects COM friendly, that means you need to respect the rules of COM not
the rules of .NET. For more detailed info, search the MSDN docs for COM
Interop.

Willy.

[=?Utf-8?B?Sm9hY2hpbQ==?=]

Thank you Alberto,

Well, I have the network communication and that is the way I decided to go.
I can also make a connection to the C# dll which hosts the tcp server (which
is blocking synchronous according to MSDN documentation). But when I try to
send data it doesn't seem to go through. My C++ implementation of the client
uses non-blocking sockets. Is that the problem?

"Alberto Poblacion" wrote:

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:F9**********************************@microsof t.com...

Is it possible to access .NET dlls from unmanaged programs, e.g. if I have
a
.NET dll implemented in C# which listens on a socket for requests from a
program written in unmanaged C++ or VB? Would it require any specific
details
in the implementation or would it be just like an ordinary C# dll?

A .Net program an certainly be called from an unmanaged program using
some interprocess communication mechanism such as sockets, like you suggest.
However, a dll is not enough for this purpose. The dll needs to be hosted in
an .exe which "starts" it listening at the socket.

If you don't want to communicate with the dll via such a mechanism, but
rather you want to call it directly from unmanaged code, then, as far as I
know, the only way to do it is to go through COM. You would expose the .Net
dll as a COM object, and then consume it from C++ or VB6 like any other COM
object, disregarding the fact that it was written in .Net.

[=?Utf-8?B?Sm9hY2hpbQ==?=]

Do I have to use COM or is there another way? I feel the use of COM forces
the user of the dll to write so much more extra code and it is not the way
that I want it.

"Willy Denoyette [MVP]" wrote:

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:F9**********************************@microsof t.com...

Is it possible to access .NET dlls from unmanaged programs, e.g. if I have
a
.NET dll implemented in C# which listens on a socket for requests from a
program written in unmanaged C++ or VB? Would it require any specific
details
in the implementation or would it be just like an ordinary C# dll?

You need to use COM Interop, that is, you have to expose your managed
class(es) as COM objects (ComVisible=true), you also need to make your
objects COM friendly, that means you need to respect the rules of COM not
the rules of .NET. For more detailed info, search the MSDN docs for COM
Interop.

Willy.

[Willy Denoyette [MVP]]

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...

Do I have to use COM or is there another way? I feel the use of COM forces
the user of the dll to write so much more extra code and it is not the way
that I want it.

No, there is not. Talking about COM interop from VB, there is no "extra"
code to write, all you need to do is create an instance of the object and
call it's methods and properties. From C++, you have to write some extra
code, but this is more like template code,basically what you need is
initialize COM, create an instance of the object and call it's methods,
basically not more complex than calling a C++ class methods complex, really.
Sure you need to take care about data marshaling, but this is something
you'll have to do anyway when exchanging data across disparate systems.

Herewith a simple sample illustrating the process...

// interface
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("...................................")]
public interface IFoo{
void Run();
}

// C#
// class implementing IFoo
[ClassInterface(ClassInterfaceType.None)]
[Guid("............................................ ....")]
[ProgId("someNamespace.Foo")]
[ComVisible(true)]
public sealed class Foo: IFoo {
public Foo() {}
public void Run()
{
....
}
}

// C++ client
// Import the typelib produced by running the regasm utility on your .NET
assembly.
#import "myDotNetLib.tlb" no_namespace
// Init COM for mutithreaded access ...
HRESULT hres = CoInitializeEx(0, COINIT_MULTITHREADED);
...
// Create an instance of Foo, using VC++ COM smart pointer support
IFooPtr m_ptrFoo(__uuidof(Foo));
// call it's meyhods
m_ptrFoo->Run();
....
// unitialize COM when done with it
CoUninitialize();
Willy.

[=?Utf-8?B?Sm9hY2hpbQ==?=]

Thank you Willy for clarifying things for me!

Regards,
Joachim

"Willy Denoyette [MVP]" wrote:

"Joachim" <Jo*****@discussions.microsoft.comwrote in message
news:C5**********************************@microsof t.com...

Do I have to use COM or is there another way? I feel the use of COM forces
the user of the dll to write so much more extra code and it is not the way
that I want it.

No, there is not. Talking about COM interop from VB, there is no "extra"
code to write, all you need to do is create an instance of the object and
call it's methods and properties. From C++, you have to write some extra
code, but this is more like template code,basically what you need is
initialize COM, create an instance of the object and call it's methods,
basically not more complex than calling a C++ class methods complex, really.
Sure you need to take care about data marshaling, but this is something
you'll have to do anyway when exchanging data across disparate systems.

Herewith a simple sample illustrating the process...

// interface
[InterfaceType(ComInterfaceType.InterfaceIsDual)]
[Guid("...................................")]
public interface IFoo{
void Run();
}

// C#
// class implementing IFoo
[ClassInterface(ClassInterfaceType.None)]
[Guid("............................................ ....")]
[ProgId("someNamespace.Foo")]
[ComVisible(true)]
public sealed class Foo: IFoo {
public Foo() {}
public void Run()
{
....
}
}

// C++ client
// Import the typelib produced by running the regasm utility on your .NET
assembly.
#import "myDotNetLib.tlb" no_namespace
// Init COM for mutithreaded access ...
HRESULT hres = CoInitializeEx(0, COINIT_MULTITHREADED);
...
// Create an instance of Foo, using VC++ COM smart pointer support
IFooPtr m_ptrFoo(__uuidof(Foo));
// call it's meyhods
m_ptrFoo->Run();
....
// unitialize COM when done with it
CoUninitialize();
Willy.