Calling a .NET assembly through PURE UNMANAGED code

[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

 

[Niki Estner]

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

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

 

[Guest]

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...

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

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

 

[Niki Estner]

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...

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

 

[Thomas Scheidegger [MVP]]

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.....

Use the 'Managed Extensions for C++ .NET'.
There you can mix managed & unmanaged code.

Mixing Managed and Unmanaged Classes
http://msdn.microsoft.com/library/en-us/vcmxspec/html/vcManagedExtensionsSpec_16.asp

Wrapper:
http://msdn.microsoft.com/library/en-us/dncscol/html/csharp12192002.asp

 

[Guest]

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...

 

[Guest]

Thanks, I think that migth help...

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

 

[Thomas Scheidegger [MVP]]

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...

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)