locked
Pushing Extention methods into the Proxy.dll RRS feed

  • Question

  • As I have published my first generic contract and begun to use it within our project I have begun to rely on extension methods for common code patterns. (Extension methods rule!) The bummer is that I need to encapsulate them into a static class in a separate project because they don't get built into the Proxy.dll. Having them defined in the Proxy.dll would be optimum since one reference would bring all the needed namespaces with it.

    If defined in the implementation dll then they reference all the wrong objects (i.e. not the .Proxy namespace) and even if they didn't you would have to reference the implementation dll as well to get at them.

    I was thinking it would be cool if there would be a way to push some common coding patterns down to the Proxy.dll just like the automatic generation of the individual Message posting methods for each port on a contract's Service Port. Maybe a ExtensionContract attribute (akin to DataMember or DataContract) that could be stuck to a public static extension method class and would cause that class to be copied into the proxy.dll?

    Bryan
    Wednesday, October 22, 2008 4:22 PM

Answers

  • Well, I spent a few hours messing around with the dssproxy.exe options and reading posts in the forum and it seems that the only real functionality that you can obtain with the /ext and /partialclass arguments is to extend the service's ServiceState object. I can't push down any extension methods as they can only be a part of non generic, non nested static classes. So there isn't any way to add extension methods to the proxy dll using the dssproxy options.

    I have played around with alternate ways of dealing with this problem and the only way that avoids a bunch of project reference nightmares is to create a standalone project that carries just the extension methods.

    I personally think it would be nice to have this functionality and I don't really see this as adding implementation to the proxy as that isn't how I see extension methods being applied. YMMV

    ref:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3946603&SiteID=1

    Bryan
    Monday, October 27, 2008 12:34 PM

All replies

  • From my understanding of things the whole point of the proxy assembly is that it *doesn't* have user code in it, just the data types.  This ensures that other services consuming your service A) only need the proxy and not the main assembly, and B) can be guarentteed that the proxy isn't going to do anything unexpected.  Being able to inject your own code into the proxy defeats this because the proxy could then do just about anything.
    Wednesday, October 22, 2008 9:57 PM
  • Phillip

     

    The way I read your answer I only partly agree with you. Yes, the idea behind the proxy is to contain the contract and (here is where I interpret it differently) no implementation. But I am not talking about service implementation, but rather extension methods which extend a set of classes without regard to implementation.

     

    From:http://msdn.microsoft.com/en-us/library/bb383977.aspx

    Extension methods enable you to "add" methods to existing types without creating a new derived type, recompiling, or otherwise modifying the original type.

     

    So I am still presenting to the consumer of the Proxy.dll an implementation independent dll and at the same time shipping with it some common contract coding patterns. Afterall, the designers actually extended the ServicePort type by adding to it a series of methods that extend the contract. Use .Net Reflector and take a look at the assembly. I just thougth it would be cool to be able to add them myself too.

     

    Bryan

     

    Wednesday, October 22, 2008 10:57 PM
  • If this was allowed what would stopp you from exposing state the should otherwise be internal and using extension methods in the proxy from providing part of the implementation?  Don't get me wrong, I can certain see it being useful in some situation (take the vector/matrix classes from the PhysicalModel namespace for example, and obviously those extra helper methods already generated in the proxy) but IMHO allowing the easy injection of arbitrary code would be opening the door for abusing the system.

     

    EDIT: Taking a look at dssproxy.exe's options it looks like you can already do this, it has the '/ext' option that lets you specify a directory containing your own source files to include in the proxy.  It can also generate all the DataContract annotated classes as partial classes with the '/partialclass' option.

    Wednesday, October 22, 2008 11:18 PM
  • I can't see how one might be able to expose internals with extension methods in a Proxy dll.

     

    Fundamentally, one could do this if they had control of an implemention dll and put the extention method in the implemention dll and then made an internal member public. Though I would argue bad programming practice or say just make the internal element public.

     

    However, this isn't an issue with MRDS since the Proxy is generated from DataContract decorated classes and DataMember decorated methods/fields/properties and by definition they must be pubilc and get/set. So if an extension method did access an internal property that property wouldn't exist in the proxy.dll and the copy of the extension method would fail to compile.

     

    I will take a look at the dssproxy options that you mention and see what I can do with them. Thanks

     

    Bryan

    Thursday, October 23, 2008 1:07 AM
  • I was thinking more in terms of that someone could add state that *should* be internal as a public DataMember and then use that to do work in the proxy, instead of keeping the state internal and doing the work in the service implementation.  This of course assumes you have control over the implementation, which you will anyway if you're generating the proxy.  Doing this is obviously a bad idea, but i suppose it's just a tradeoff between prevent this sort of abuse and allowing the greater flexability.

    Thursday, October 23, 2008 1:20 AM
  • Well, I spent a few hours messing around with the dssproxy.exe options and reading posts in the forum and it seems that the only real functionality that you can obtain with the /ext and /partialclass arguments is to extend the service's ServiceState object. I can't push down any extension methods as they can only be a part of non generic, non nested static classes. So there isn't any way to add extension methods to the proxy dll using the dssproxy options.

    I have played around with alternate ways of dealing with this problem and the only way that avoids a bunch of project reference nightmares is to create a standalone project that carries just the extension methods.

    I personally think it would be nice to have this functionality and I don't really see this as adding implementation to the proxy as that isn't how I see extension methods being applied. YMMV

    ref:http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=3946603&SiteID=1

    Bryan
    Monday, October 27, 2008 12:34 PM