Hartmut's BoxHartmut Wilms’s Weblog

« März 2007 | Main | Mai 2007 »


WCF Dynamic Proxy

I’m a big fan of WCF XML Messaging, i.e. making use of the Message object and accessing the SOAP envelope directly. In my opinion this approach supports the loosely coupled nature of services best.

Although Untyped Services have no need for generated service proxies and they don’t rely on XML serialization, you have to provide the service contract (.NET interface). You might generate the interface from the published WSDL or write the code by hand. Either way the development of a service contract on the client side is annoying.

The WCF team at NetFx3 has published a WCF Dynamic Proxy, which relies on the WSDL URL in order to create a proxy for communication with a service:

1. Create the ProxyFactory specifying the WSDL URI of the service.

    DynamicProxyFactory factory = new DynamicProxyFactory(“http://localhost:8080/WcfSamples/DynamicProxy?wsdl”);

2. Browse the endpoints, metadata, contracts etc.

3. Create DynamicProxy to an endpoint by specifying either the endpoint or
   contract name.
    DynamicProxy proxy = factory.CreateProxy(“ISimpleCalculator”);


    DynamicProxy proxy = factory.CreateProxy(endpoint);
4. Invoke operations on the DynamicProxy
    dobule result = (dobule)proxy.CallMethod(“Add”, 1d ,2d);

5. Close the DynamicProxy


This is a great way of (really) decoupling your client (consumer) from the service (provider)!

Posted by Hartmut Wilms at 10:50 | Comments (1) | TrackBack


Partial Methods: the Missing Pieces of Code Generation

Partial Classes, a C# 2.0 language feature, are mainly used within code generation. What’s missing today is a means of customizing generated methods. Let’s say your code generator generates a method, which does “something”:

private void MyGeneratedMethod() {
    // Do Something

If someone wants to add any kind of pre- or post-processing surrounding this “something”, he’s out of luck. Traditionally this problem is solved by introducing protected areas into the generated code. These areas contain code, manually added by the developer, which is “protected” from being eliminated by subsequent code generations. The code generator has to identify these areas and act accordingly. The “protected areas” approach isn’t fool-proof, because protected areas can easily be removed without notification. Partial Methods to the rescue:


// In MyGeneratedClass.generated.cs 
public partial class MyGeneratedClass { 
    private void MyGeneratedMethod() {
        // Do Something
    partial void MyGeneratedMethodPreprocessing(); 
    partial void MyGeneratedMethodPostprocessing(); 
// In MyGeneratedClass.cs 
public partial class MyGeneratedClass { 
    partial void MyGeneratedMethodPreprocessing() {
        // Do some preprocessing
    partial void MyGeneratedMethodPostprocessing() {
        // Do some postprocessing

Partial Methods separate method definition and implementation. A defined method does not have to be implemented, i.e. if a partial method definition isn’t implemented, all calling code is removed by the compiler.

Galin Iliev summarizes the restrictions on partial methods in his blog entry:

Posted by Hartmut Wilms at 17:32