[Mono-list] General .NET Q

August Steinbacher august.steinbacher@gmx.net
Mon, 29 Mar 2004 09:05:30 +0200


Hello,

I am working on a similar problem, let me describe it shortly:

- there is an object-oriented DB containing objects (type description + 
the object's methods code)
- the objects are written in (unmanaged) C++.

Now I want to interact with these objects using managed code. I thought 
of creating something like a proxy object for each needed unmanaged 
object which provides the same methods and properties. If an unmanaged 
object would be called from my program, the proxy gets active and 
"redirects" the method call to the unmanaged object.
--------------------------------------------
unmanaged Type:
   class X {
     int n;
   public:
     X (int n) { this.n = n; }
     int getValue () { return n; }
   }
   X::X(int n) { this.n = n; }
   int X::getValue() {return this.n; }	

Managed program:
   static void Main () {
     X x = new X(4);  // here the proxy gets active
     System.Console.WriteLine(x.getValue());
   }
--------------------------------------------
How are the proxy objects created?
- from a given xsd schema. The xsd schema is created using a modified 
xsd.exe. Modified because i want to extract the method code from the c++ 
objects too. Don't know yet how to do that.
Respectively, the xsd-schema is createad from the info in the DB which 
holds the type description and the methods code for my objects.

I do not want to solve this problem using managed copies of the 
unmanaged types at runtime because then the DB would get inconsistent. 
So I have to work directly on the "living" C++ objects. That's why 
techniques like System.Reflection or System.CodeDom don't help me very 
much...

greetz
august


Chris List Recipient wrote:
> Check this out for a completed solution:
> 
> http://www.codeproject.com/dotnet/DotNetScript.asp?target=execute%7Cc%23%7Cc
> ode
> 
> -Chris 
> 
> -----Original Message-----
> From: mono-list-admin@lists.ximian.com
> [mailto:mono-list-admin@lists.ximian.com] On Behalf Of Jonathan Pryor
> Sent: Wednesday, March 24, 2004 7:15 PM
> To: svose@programmerforrent.com
> Cc: mono
> Subject: Re: [Mono-list] General .NET Q
> 
> Below...
> 
> On Wed, 2004-03-24 at 21:05, Shawn Vose wrote:
> 
>>Does anyone know if the following is possible:
>>
>>Taking a snippet of .NET c# code, maybe a function, and storing it in 
>>a mysql db
>>
>>to be later called by another piece of code and executed?
>>
>>I was asked this question by a client and I dont have the slightest 
>>clue on how to answer this. My initial answer is no because it would 
>>have to be compiled into the calling class; however, I am thinking 
>>that system.reflection would be able to help me.
> 
> 
> Is it possible?  Yes.  Will System.Reflection do it?  It depends.  It can't
> do it alone, though.
> 
> The easiest thing to do would be to:
> 1.  Define an interface
> 2.  Use System.CodeDom to (a) generate skeleton C# code, (b) include the
>     code from the database into the CodeDom code, and (c) compile the
>     code into an assembly.  The CodeDom code should implement the 
>     interface defined in (1).
> 3.  Load the assembly at runtime
> 4.  Instantiate the type from the assembly at runtime, through the 
>     numerous mechanisms .NET provides (Activator.CreateInstance, etc.) 5.
> Cast the type created in (4) to the interface defined in (1) 6.  Invoke the
> code via the interface method.
> 
> A Variation would be to use a delegate instead of the interface.
> 
> A pitfall with this framework is that all methods defined in the database
> must conform to a single interface, so you couldn't have methods with
> different argument lists and return types defined this way.
> 
> To work around that, you could use System.Reflection.MethodInfo, but this
> complicates your client code as you need not only need to know what function
> to call, but also what arguments to provide it, what it returns, etc.  This
> can be done, it's just not as simple or as fast as the above solution.
> 
> (Regarding performance, CodeDom generation will be slow, but it can't be
> avoided.  Method invocation also can't be avoided, but delegate/interface
> invocation is *much* faster than MethodInfo.Invoke, so if this code will be
> invoked frequently, a well-defined delegate/interface would be preferred.)
> 
>  - Jon
> 
> 
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> _______________________________________________
> Mono-list maillist  -  Mono-list@lists.ximian.com
> http://lists.ximian.com/mailman/listinfo/mono-list
> 
>