views:

428

answers:

1

This way lies madness, I know.

I have an executable (the source code to which I do not have access) that I would like to extend via .NET. It's a native executable, so I would need to inject a CLR host in order to do this. My basic idea is to provide scripting-like functionality via a .NET language (C#, for example) and provide hooks in the target executable for the scripts to manipulate, and vice versa.

I know I'll need to use various techniques to achieve this - DLL injection, some runtime ASM injection, etc., but what I'd like to know is this: is what I'm talking about possible? Better still - has anyone done something like this before?

+1  A: 

You can do this using COM interop, if your native executable is capable of using COM objects. If you register your .NET assembly for interop then your native executable can use your .NET classes just like "ordinary" COM objects, and when the first one is created it will spin up the CLR inside the native process. Similary if you can expose COM objects from the native executable then you can use them from your .NET code if you create an interop assembly (or even without a type library, if you use only IDispatch).

The basics are straightforward but I'm just scratching the surface - for a serious project like this you need a serious reference. I highly recommend .NET and COM, The Complete Interoperability Guide by Adam Nathan. It's a big book that doesn't leave much unsaid, and it also has a lot of great information on designing .NET and COM classes to interop cleanly. It also explains how to host the CLR directly inside a native app, but that option may not be practical without access to the source code. I would definitely start with the COM interop route, and only host the CLR natively if you have no other option.

JayMcClellan
Thanks - although unfortunately the target executable I have in mind is *not* COM-capable. =\ Still I will look into the reference you provided - thanks again. =)
Erik Forbes