Permitting C access to managed .Net assemblies

[Ken Allen]

I am in the process of upgrading an existing product code base from C++
to C#, converting the use of a named pipe for the client/server
communication to using .Net remoting via C# classes. Things are going
fairly well, and most of the plans are falling into place.

One wrinkle that was introduced recently was the discovery that some of
our 'partners' are insisting on continuing their development labs using
C++ or even C code, and they have no plans to convert to managed code.
In some cases they are even refusing to move to using anything later
than Visual Studio 6!

How difficult is it to write a DLL that will permit C/C++ code to access
the contents of a .Net assembly? With some small changes I can create
a client-side DLL that will contain all of the pieces needed, and I can
even add some wrapper methods to make the C/C++ invocation easier if I
need to, but I can find no information on how to achieve this.

All of the existing documentation is focused on how to permit managed
..Net code access the contents of unmanaged DLLs, which I do not need.

And the clients do not want to use COM objects either -- they are
writing C or C++ code, and the most some of them are using is MFC.

Is this even possible?

-ken

[Fitim Skenderi]

Hi Ken,

As far as I know, I don't think you can create a DLL in .NET and access it
in your C++ application. DLLs written in .NET will need the .NET runtime to
execute, which will make it very difficult to bind to application's memory
space (win32 application).

Your best an easiest soultion would be COM interop. So you can create your
DLLs in .NET and register them as COM objects with the operating system,
then your VB6 or VC++ 6 can instantiate COM object without any problem.

Fitim Skenderi
"Ken Allen" <ke******@sympatico.ca> wrote in message
news:e9**************@TK2MSFTNGP10.phx.gbl...

I am in the process of upgrading an existing product code base from C++ to
C#, converting the use of a named pipe for the client/server communication
to using .Net remoting via C# classes. Things are going fairly well, and
most of the plans are falling into place.

One wrinkle that was introduced recently was the discovery that some of
our 'partners' are insisting on continuing their development labs using
C++ or even C code, and they have no plans to convert to managed code. In
some cases they are even refusing to move to using anything later than
Visual Studio 6!

How difficult is it to write a DLL that will permit C/C++ code to access
the contents of a .Net assembly? With some small changes I can create a
client-side DLL that will contain all of the pieces needed, and I can even
add some wrapper methods to make the C/C++ invocation easier if I need to,
but I can find no information on how to achieve this.

All of the existing documentation is focused on how to permit managed .Net
code access the contents of unmanaged DLLs, which I do not need.

And the clients do not want to use COM objects either -- they are writing
C or C++ code, and the most some of them are using is MFC.

Is this even possible?

-ken