Griffith, Thanks for your explanations to my query. Sorry, I should have been more specific about what I am trying to acheive, in my earlier posting.
Anyways, what I am getting at is developing a Java like Dynamic Proxy equivalent in .NET for any class type. In Java, proxies may be created only for only those classes that implement atleast one interface to make them transparent by typecasting to the interface. In my quest for a more flexible solution in .NET compared to the Java approach, I attempted writing a Dynamic Proxy in .NET similar in lines to the TransparentProxy equivalent. Now, I know that similar functionality can be acheived by rolling my own extension to RealProxy at the cost of classes extending from ContextBoundObject and the overhead of method stack ->IMessage conversion made by TP that I prefer to avoid. One solution that will work is to have the Dynamic Proxy class that is built at runtime using Reflection.Emit to extend the type of the class to be proxied. But that limits only virtual methods to be intercepted by the Proxy. Now since CLR works out the magic of type-related operation(GetType, typecasting, isinstance check, etc...) and interception of virtual and non-virtual method invocation on TP, I thought my dynamic proxy implementation can leverage those features using TP and by overriding TP's behaviour (of method call -> IMessage conversion followed by subsequent RealProxy.Invoke(IMessage) method call) to invoke my DynamicProxy implementation with a different signature. My question is whether the "stub" parameter of type IntPtr in the constructor of RealProxy is provided for achieving this flexible override behaviour. If so, does the stub point to an array of IL code generated using Reflection.Emit() or is it a pointer to JIT'ed machine code? Thanks, Ramkishore ----- Original Message ----- From: "Griffiths, Ian" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Monday, August 11, 2003 11:01 AM Subject: Re: [ADVANCED-DOTNET] TP/RP stub... I'm assuming here that you're using "stub" in the Java sense, to mean the thing on the client side that looks like the object. (Microsoft have always used "stub" to mean the other end. They use the term "proxy" for the client-side part. But the only way I can make sense of your post is if you mean the client-side part when you say "stub".) If what you want to do is control the signature of the methods available, then you don't need to write your own TP. All you need to do is build a transparent proxy for a type which supplies the signatures you require. If you already have an appropriate interface definition or class definition defining the method signatures you require, then you're done. But if you would like to generate method signatures at runtime, you should be able to generate the interface definitions using Reflection.Emit, and then pass the resulting generated type in when you build the Transparent Proxy. So you really don't need to be able to generate the TP yourself to achieve what you're trying to achieve. (Which is a good thing - you wouldn't be able to do so reliably anyway, because there's no guarantee that the calling convention used by the CLR won't change from one version of .NET to the next. Using this approach insulates you from such changes, and also means it should work on the Itanium version of .NET, whenever that appears.) But if you really do mean stub in the Microsoft sense (i.e. the bit on the server side), you can replace absolutely anything downstream of the transparent proxy, and you don't need assembly language to do it. -- Ian Griffiths DevelopMentor > -----Original Message----- > From: Ramkishore [mailto:[EMAIL PROTECTED] > > Hi, > > Does anyone know how to write a custom stub for the TransparentProxy/ > RealProxy. RealProxy constructor does take in a stub of type IntPtr. I > would like to know if there is any way to control the method signature > invoked by TransparentProxy. My understanding after reading Chris Brumme's > blog http://blogs.gotdotnet.com/cbrumme/ on TransparentProxy is that the > stub is a machine code.(ie. x86 code for windows). If so, I guess there > is no portable way to provide our own stub implementation, right?
