Calling a .NET assembly through PURE UNMANAGED code

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

Hi,

I am tiring to load an assembly from memory ( e.g.
System.Reflection.Assembly.Load( byte[] ), this works fine through managed
and mixed code. NOW, I am tiring to achieve the same thing through PURE
UNMANAGED code, I can't use com or com interop, does some one have an idea
how to achieve what was just described? ( through unmanaged code )
Is it possible to call a managed assembly through PURE UNMANAGED code? how?
( if at-all )

Again, I can't use COM so COM Interop will not satisfy my needs
 
Nadav said:
Hi,

I am tiring to load an assembly from memory ( e.g.
System.Reflection.Assembly.Load( byte[] ), this works fine through managed
and mixed code. NOW, I am tiring to achieve the same thing through PURE
UNMANAGED code, I can't use com or com interop, does some one have an idea
how to achieve what was just described? ( through unmanaged code )
Is it possible to call a managed assembly through PURE UNMANAGED code?
how?
( if at-all )

Again, I can't use COM so COM Interop will not satisfy my needs
Click to expand...

Why can't you use COM? AFAIK the .net runtime exposes parts of its native
functionality through COM interfaces.
If COM really isn't an option, there are still a few solutions I can think
of, but I'm not sure you will like them:
- run the manages process using CreateProcess, and communicate with it on
standard IPC channels like pipes or sockets
- Create the managed assembly in MC++, which can create "ordinary" DLL
exports, that can be used with GetProcAddress
- Load the managed DLL with GetProcAddress, and use some windows messaging
code to get in contact with the managed code.

Niki
 
Hi Niki,

Thanks for your responce, Well, for me, exposing managed code through
DLLExport or through COM Interop is the same, as long as some code would be
able to be implemented using managed code it would be easy do decompile it or
get it's IL ( the dotfuscator will not solve my problem here ), SOooo a small
piece of my project should be written in unmanaged code ( which if far harder
to de-compile ), this part must include the ...Assembly.Load.....
functionality, If I could use a managed assembly directly from within my
unmanaged code it would solve my problem...

Niki Estner said:
Nadav said:
Hi,

I am tiring to load an assembly from memory ( e.g.
System.Reflection.Assembly.Load( byte[] ), this works fine through managed
and mixed code. NOW, I am tiring to achieve the same thing through PURE
UNMANAGED code, I can't use com or com interop, does some one have an idea
how to achieve what was just described? ( through unmanaged code )
Is it possible to call a managed assembly through PURE UNMANAGED code?
how?
( if at-all )

Again, I can't use COM so COM Interop will not satisfy my needs
Click to expand...

Why can't you use COM? AFAIK the .net runtime exposes parts of its native
functionality through COM interfaces.
If COM really isn't an option, there are still a few solutions I can think
of, but I'm not sure you will like them:
- run the manages process using CreateProcess, and communicate with it on
standard IPC channels like pipes or sockets
- Create the managed assembly in MC++, which can create "ordinary" DLL
exports, that can be used with GetProcAddress
- Load the managed DLL with GetProcAddress, and use some windows messaging
code to get in contact with the managed code.

Niki
Click to expand...
 
Nadav said:
Hi Niki,

Thanks for your responce, Well, for me, exposing managed code through
DLLExport or through COM Interop is the same, as long as some code would
be
able to be implemented using managed code it would be easy do decompile it
or
get it's IL ( the dotfuscator will not solve my problem here ), SOooo a
small
piece of my project should be written in unmanaged code ( which if far
harder
to de-compile ), this part must include the ...Assembly.Load.....
functionality, If I could use a managed assembly directly from within my
unmanaged code it would solve my problem...
Click to expand...

Is there any reason why you can't use COM in your unmanaged code? (I'm *not*
talking about COM interop!)
If not, have a look at:
http://msdn.microsoft.com/library/d...de/html/cpconhostingcommonlanguageruntime.asp.

Niki
 
Hi Thomas,

Thanks for your resounce, Indeed you are right, BUT creating a mixed mode
executable causes the IL code to be embedded in the raw EXE file, still, this
managed code is able to be de-compiled ( by ildasm for instance ) and this is
exacly what i am tring to avoid.

P.S.
Writing a managed assembly exposed by Com Interop impose the same problem as
the assembly exposed by COM Interop would be able to be decompiled...
 
Thanks for your resounce, Indeed you are right, BUT creating a mixed mode
executable causes the IL code to be embedded in the raw EXE file, still, this
managed code is able to be de-compiled ( by ildasm for instance ) and this is
exacly what i am tring to avoid.
Writing a managed assembly exposed by Com Interop impose the same problem as
the assembly exposed by COM Interop would be able to be decompiled...
Click to expand...


so 'your problem' is to prevent de-compiling?

Currently, 'managed code' always means IL-code and metadata, by design.
Thus there is no easy solution for you.

My recommendation:
use .NET the way it was designed for.


Maybe there are (IMHO strange) third-party tools
to compile IL code to native code....
But this will NOT be real .NET anymore.


Or maybe a 'hybrid' solution could work for you?
In theory, I don't have tried it:
create a classic Win32 EXE,
'embed' an assembly-file as raw data,
then use the .NET hosting APIs / Interfaces
CorBindToRuntimeEx, ICorRuntimeHost, _AppDomain....
to load & execute this raw data as assembly....
(but needs strong COM knowledge)
 
Back
Top