[DotGNU]Signatures and invoking methods

[Chris Smith]

We've a new DGEE C# webservice bootstrapper exe which uses a brand new and 
pretty efficient XmlRpc implementation (from npg).

The new caching pnetVM uses ILExecThreadLookupMethod() to find the intended 
pnetvm entry point of this exe ( it doesn't use void Main as our entry point 
needs to return System.String).

And it's failing.  I'm pretty sure I've got the Signature correct and all 
that, but just in case could someone Check?

The DGEE_run workhorse is broken out into a class (and dll) of it's own as it 
will be inherited by all protocols (like xmlrpc) implemented by the DGEE.

    
namespace DotGNU.DGEE.Protocols
{   
  public class ProtocolService
  {
    public static String DGEE_run( String []args )
    { 
      // Locate, load and invoke webservice
       ....
    }
    ....
  }
}

namespace DotGNU.DGEE.Protocols 
{
  public class XmlRpcService : ProtocolService
  {
    static XmlRpcService ()
    {
        // Constructor stuff
    }

    public static void Main( string[] args )
    {
       // Command line debugging 
       // This is NOT the entry point for webservice Execution
       // Invoke DGEE_run (ProtocolService) instead
    }
  }
}


Of which, DGEE_run is looked up in the pnetvm via:

method = ILExecThreadLookupMethod(thread,
                                    "DotGNU.DGEE.Protocols.XmlRpcService",
                                    "DGEE_run",
                                    "([oSystem.String;)oSystem.String;" );


Resulting in method being NULL. :o(


I wonder if it is because DGEE_run is an inherited method... however, adding 

public static String DGEE_execute ( string[] args )
{
  return DGEE_run(args);
}

to Class XmlRpcService and Looking that up also fails.

This has got to be something to do with the way that the exe is being built as 
the old DGEEInvoke exe works fine with the new pnetVM (except the type and 
method names are different in the ThreadLookupMethod call.

Is there a way of generating the "([oSystem.String....." etc signature given a 
method prototype without having to do it by hand (and potentially getting it 
wrong)?

Anyone spot anything else???

Cheers,
Chris "clutching wildly"