Skip to content

Home

  • 2 min read

Customize code generation in .NET RIA Services

Quote

Microsoft .NET RIA Services simplifies the traditional n-tier application pattern by bringing together the ASP.NET and Silverlight platforms. RIA Services provides a pattern to write application logic that runs on the mid-tier and controls access to data for queries, changes and custom operations. It also provides end-to-end support for common tasks such as data validation, authentication and roles by integrating with Silverlight components on the client and ASP.NET on the mid-tier.

To get started with .NET RIA Services you need Visual Studio 2008 SP1 and you need to install the following packages

  • Microsoft Silverlight 3 Tools Beta 1 for Visual Studio 2008 SP1
  • Microsoft .NET RIA Services March '09 Preview

On the download page of .NET RIA Services there is a great PDF document (riaservicesoverviewpreview.pdf) that gives you a step-by-step guide.

Every time you compile a solution with .NET RIA Services, an MSBuild task is executed that generates code in your Silverlight project from the domain services (DomainService class) that reside in your ASP.NET server. After some investigation through reflector, you can actually modify or extend the code generation using CodeDom! For this you need to add an attribute called DomainIdentifier where you specify a type that inherits from CodeProcessor. Both classes reside in the System.Web.Ria.Data namespace.

[EnableClientAccess()]
[DomainIdentifier("Comment", CodeProcessor = typeof(CommentCodeProcessor))]
public class CityService : DomainService
{
   //...
}

In this example, we simply add some documentation in the summary tag.

public class CommentCodeProcessor : CodeProcessor
{
    public CommentCodeProcessor(CodeDomProvider codeDomProvider)
        : base(codeDomProvider)
    {
    }

    public override void ProcessGeneratedCode(
        DomainServiceDescription domainServiceDescription,
        System.CodeDom.CodeCompileUnit codeCompileUnit,
        IDictionary<Type, System.CodeDom.CodeTypeDeclaration> typeMapping)
    {
        Type domainServiceType = domainServiceDescription.DomainServiceType;
        CodeTypeDeclaration declaration = typeMapping[domainServiceType];

        declaration.Comments.Add(new CodeCommentStatement("<summary>", true));

        foreach (var entityType in domainServiceDescription.EntityTypes)
        {
            declaration.Comments.Add(
                new CodeCommentStatement(
                    string.Format("Entity Type: {0}", entityType.FullName), true));
        }

        foreach (var operationEntry in domainServiceDescription.DomainOperationEntries)
        {
            declaration.Comments.Add(
                new CodeCommentStatement(
                    string.Format("Operation Entry: {0}", operationEntry.MethodInfo.Name), true));
        }

        declaration.Comments.Add(new CodeCommentStatement("</summary>", true));
    }
}

Below you find a sample of the generated file using the CommentCodeProcessor

/// <summary>
/// Entity Type: SilverlightApplication.Web.DataModels.City
/// Operation Entry: GetCities
/// Operation Entry: ReturnAllCities
/// </summary>
[DomainIdentifier("Comment")]
public sealed partial class CityContext : DomainContext
{
   //...
}
  • 1 min read

Intercepting your WCF messages in Silverlight 2.0

In many applications you want to intercept WCF messages for doing stuff like, logging, tracing, passing a user context, language identifier, etc. Typically this can be done through the IClientMessageInspector that resides in the System.ServiceModel.Dispatcher. Unfortunately this interface doesn’t exist in Silverlight 2.0.

Thankfully WCF is very extensible, and there is a sample Silverlight Web Services Samples on MSDN Code Gallery that shows how you can still use the IClientMessageInspector by implementing a custom binding. You simple use the BasicHttpMessageInspectorBinding that receives in the constructor an instance of type IClientMessageInspector. For example:

BasicHttpMessageInspectorBinding binding = new BasicHttpMessageInspectorBinding(new TraceInspector());

Note that the sample only allows you to pass one inspector, if you need to pass several inspectors you can use the decorator pattern to pass multiple.

public class ClientMessageInspectorDecorator : IClientMessageInspector
{
    IClientMessageInspector[] inspectors;

    public ClientMessageInspectorDecorator(params IClientMessageInspector[] inspectors)
    {
        this.inspectors = inspectors;
    }

    public object BeforeSendRequest(ref Message request, IClientChannel channel)
    {
        foreach (var item in inspectors)
        {
            item.BeforeSendRequest(ref request, channel);
        }

        return null;
    }

    public void AfterReceiveReply(ref Message reply, object correlationState)
    {
        foreach (var item in inspectors)
        {
            item.AfterReceiveReply(ref reply, correlationState);
        }
    }
}
  • 3 min read

AOP in Action - Dirty Tracking using Mixins with Castle’s DynamicProxy

In Part 1, we used the Unity block to intercept properties for dirty tracking. Our target class needed to implement the IDirty interface, and the setter properties (annotated with the Dirty attribute) assigned the Dirty flag (of IDirty) when the value has changed. Take for example the following classes:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public class DirtyAttribute : System.Attribute
{
}

public interface IDirty
{
    bool IsDirty { get; set; }
}

public class Customer
{
    public virtual string FirstName { get; [Dirty] set; }
    public virtual string LastName { get; [Dirty] set; }
}

Note that in contrast to Part 1, the Customer object doesn’t implement the IDirty interface. In this example we are going to use a mixin for dirty tracking, a mixin is a class that provides a certain functionality to be inherited by a subclass, but is not meant to stand alone. That’s exactly what we want to achieve, that is to provide extra functionality, namely dirty tracking, to our Customer object.

We simply have to implement the IDirty interface once and for all and call it for example DirtyMixin.

[Serializable]
public class DirtyMixin : IDirty
{
   public bool IsDirty { get; set; }
}

As interception and mixin mechanism we use Castle’s DynamicProxy, the latest build can be found here. To intercept our (dirty) properties we need to implement an interface called IInterceptor. In the implementation we write the code that need to be executed (advice) at particular points (pointcut) in the program. Note that with Unity we have the notion of IMatchingRule for defining Pointcuts, whereas in DynamicProxy we have to do it manually.

public class DirtyInterceptor : Castle.Core.Interceptor.IInterceptor
{
    public void Intercept(Castle.Core.Interceptor.IInvocation invocation)
    {
        if (PointCut(invocation.Proxy, invocation.Method))
        {
            Advise(invocation.Proxy, invocation.Method, invocation.GetArgumentValue(0));
        }

        invocation.Proceed();
    }

    bool PointCut(object target, MethodInfo methodInfo)
    {
        if (IsSetter(methodInfo) && target is IDirty)
        {
            object[] dirtyAttributes = methodInfo.GetCustomAttributes(typeof(DirtyAttribute), true);
            return (dirtyAttributes != null && dirtyAttributes.Length > 0);
        }
        else
        {
            return false;
        }
    }

    void Advise(object target, MemberInfo methodInfo, object value)
    {
        string propertyName = methodInfo.Name.Substring("set_".Length);
        PropertyInfo info = target.GetType().GetProperty(propertyName);

        if (info != null)
        {
            object oldValue = info.GetValue(target, null);

            if (!IsEqual(value, oldValue))
                ((IDirty)target).IsDirty = true;
        }
    }

    bool IsSetter(MethodInfo methodInfo)
    {
        return (methodInfo.Name.StartsWith("set_")) && (methodInfo.GetParameters().Length == 1);
    }

    bool IsEqual(object valueX, object valueY)
    {
        if (valueX == null && valueY != null)
            return false;

        if (valueX != null && valueY == null)
            return false;

        if (valueX == null && valueY == null)
            return true;

        return valueX.Equals(valueY);
    }
}

To generate our proxy we use the ProxyGenerator class that reside in the Castle.DynamicProxy2 assembly. Adding a mixin is done through the ProxyGenerationOptions which is passed to the CreateClassProxy method.

var generator = new ProxyGenerator();

ProxyGenerationOptions options = new ProxyGenerationOptions();
options.AddMixinInstance(new DirtyMixin());

Customer customer = generator.CreateClassProxy(typeof(Customer), options, new DirtyInterceptor()) as Customer;

var firstname = customer.FirstName;
Debug.Assert(!((IDirty)customer).IsDirty);
customer.FirstName = "Piet";
Debug.Assert(((IDirty)customer).IsDirty);

The customer object that we receive from the generator is a proxy through subclassing and you will see that it now implements the IDirty interface.

MixinReflector_2

You can use the PersistentProxyBuilder to save the generated assembly. It renders an assembly called CastleDynProxy2.dll. Below you find an example how you can use PersistentProxyBuilder.

var generator = new ProxyGenerator(new PersistentProxyBuilder());

ProxyGenerationOptions options = new ProxyGenerationOptions();
options.AddMixinInstance(new DirtyMixin());

Customer customer = generator.CreateClassProxy(typeof(Customer), options, new DirtyInterceptor()) as Customer;

string proxyAssemblyPath = ((PersistentProxyBuilder)generator.ProxyBuilder).SaveAssembly();

var firstname = customer.FirstName;
Debug.Assert(!((IDirty)customer).IsDirty);
customer.FirstName = "Piet";
Debug.Assert(((IDirty)customer).IsDirty);

You can go a bit further and use an extension method that enables you to ask for a certain service. Internally it will simply try to cast to the given interface.

public static class ObjectExtensions
{
    public static T GetService<T>(this object instance) where T : class
    {
        return instance as T;
    }
}

Given the GetService extension method, we use our customer as follow

IDirty dirty = customer.GetService<IDirty>();
if (dirty != null)
{
    var firstname = customer.FirstName;
    Debug.Assert(!dirty.IsDirty);
    customer.FirstName = "Piet";
    Debug.Assert(dirty.IsDirty);
}

The source code of this article can be downloaded here

  • 1 min read

WPF for data-driven applications?

The last couple of days, I was converting my add-in visual studio called Component Dropper to WPF. One thing I noticed, is that the text in my WPF application was blurry, certainly when the font is small. It is harder to read and very unpleasant to work with.

After some research, it appears to be a known problem. Check out the following threads, How to turn off anti aliasing for small text? and Blurry text in WPF – current status? and a very good explanation about the problem.

It’s an issue that is already known for 2 years and there is still no solution for this particular problem. In my experience, enterprise applications are data-driven, which means there is a lot of text (= data) that need to be displayed typically in a grid (master-detail). WPF is really a great technology, but this is not a minor issue. I don’t think that your customers will be happy if they receive a new application that is hard to read.

  • 1 min read

Please remove your hardware to start installation!

Today I tried out installing Windows Server 2008 on my cube server. When I reached the dialog to choose on which partition I want to install to, I always received the following warning "windows is unable to find a system volume that meets its criteria for installation". The partition had enough room space (40GB), formatted in NTFS, marked as primary and boot, etc.

After some research I ended up to the following article (KB927520). I tried a lot in the BIOS and partition settings but nothing helped. On the TechNet forum I saw the following thread with the same error and most of them solved the problem by physically unplugging all additional drives! On my cube I have an Areca RAID controller and a separated drive for booting the system. Unplugging my raid controller was the solution, duh!

  • 5 min read

AOP in Action - Dirty Tracking using Unity Interception

In most enterprise applications, you end up by having a lot of cross-cutting concerns throughout your application. Most of the time, you have, for example, infrastructure code for doing logging, dirty tracking, lazy loading, caching, etc. Often infrastructure code is scattered over a number of modules making it harder to maintain and understand. Aspect-oriented programming (AOP) solves this problem by allowing the programmer to express cross-cutting concerns in stand-alone modules called aspects.

When you apply domain-driven design, you often have the need for dirty tracking, check on a business entity whether the entity has changed (is dirty) or not. There are a lot of different implementations for dirty tracking, but in this article we are doing it by using an interface called IDirty that contains a property called IsDirty and the setter properties of your entity object calls the IsDirty if the value has changed.

public interface IDirty
{
   bool IsDirty { get; set; }
}

public class Customer : IDirty
{
   private string _firstName;
   private string _lastName;

   public bool IsDirty { get; set; }

   public string FirstName
   {
      get { return _firstName; }
      set
      {
         if (value != _firstName)
            IsDirty = true;
         _firstName = value;
      }
   }

   public string LastName
   {
      get { return _lastName; }
      set
      {
         if (value != _lastName)
        IsDirty = true;

            _lastName = value;
      }
   }
}

As you can see from the example, if you have a lot of properties, you end up by having a lot of infrastructure code and repeated code in each setter. What we want to achieve, is to annotate the setter property through an attribute called DirtyAttribute and that the dirty logic is centralized in one module.

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false, Inherited = true)]
public class DirtyAttribute : System.Attribute
{
}

public interface IDirty
{
   bool IsDirty { get; set; }
}

public class Customer : IDirty
{
   public bool IsDirty { get; set; }

   public virtual string FirstName { get; [Dirty] set; }
   public virtual string LastName { get; [Dirty] set; }
}

Note that these are the only dependencies needed inside your domain model project. Now we need to make clear to Unity that we need to intercept the DirtyAttribute and execute some logic. With unity we denote a policy, a policy contains a set of matching rules and a set of call handlers. A matching rule will denote on which point the handler must be executed and the handler is the logic. In AOP this is called respectively a pointcut and an advice, the combination of the two is called an aspect. First, we are going to create our DirtyHandler by implementing the ICallHandler that resides in the Microsoft.Unity.Interception assembly.

public class DirtyHandler : ICallHandler
{
   public int Order { get; set; }

   public IMethodReturn Invoke(IMethodInvocation input, GetNextHandlerDelegate getNext)
   {
      Advise(input.Target, input.MethodBase, input.Arguments[0]);
      return getNext()(input, getNext);
   }

   private void Advise(object target, MemberInfo methodInfo, object value)
   {
      string propertyName = methodInfo.Name.Substring("set_".Length);
      PropertyInfo info = target.GetType().GetProperty(propertyName);

      if (info != null)
      {
         object oldValue = info.GetValue(target, null);

         if (!IsEqual(value, oldValue))
            ((IDirty)target).IsDirty = true;
      }
   }

   private bool IsEqual(object valueX, object valueY)
   {
      if (valueX == null && valueY != null)
         return false;

      if (valueX != null && valueY == null)
         return false;

      if (valueX == null && valueY == null)
         return true;

      return valueX.Equals(valueY);
   }
}

Note that in the DirtyHandler we did not specify when the dirty logic is executed, this is done by a set of matching rules that implement the IMatchingRule interface. In our case we have three criterias, first that it can only be applied to a setter property, secondly that the setter property must be annotated with the DirtyAttribute and finally that the class must implement the IDirty interface. In Unity we have predefined rules that we can use, in our case we can use the PropertyMatchingRule and the CustomAttributeMatchingRule. To detect that a particular instance implements a given type, I created the InstanceOfMatchingRule.

public class InstanceOfMatchingRule : IMatchingRule
{
   private readonly Type _type;

   public InstanceOfMatchingRule(Type type)
   {
      _type = type;
   }

   public bool Matches(System.Reflection.MethodBase member)
   {
      return _type.IsAssignableFrom(member.DeclaringType);
   }
}

Now we are ready to configure our container for interception. Note that the interception mechanism inside Unity is implemented as an extension to the Unity block. Below we configure a policy named "DirtyPolicy" that executes the handler named "DirtyHandler" if it matches all three matching rules (PropertyMatchingRule, CustomAttributeMatchingRule and InstanceOfMatchingRule). In this example, we denote that the type Customer is configured with the VirtualMethodInterceptor. Note that this type of interception only works if your methods/properties are marked as virtual, which is the case for our Customer type (see Customer.cs).

// Start Configuration
IUnityContainer container = new UnityContainer()
   .AddNewExtension<Interception>()
   .RegisterInstance<ICallHandler>("DirtyHandler", new DirtyHandler());

container.Configure<Interception>()
   .SetInterceptorFor<Customer>(new VirtualMethodInterceptor())
   .AddPolicy("DirtyPolicy")
      .AddMatchingRule(new PropertyMatchingRule("*", PropertyMatchingOption.Set))
      .AddMatchingRule(new CustomAttributeMatchingRule(typeof(DirtyAttribute), true))
      .AddMatchingRule(new InstanceOfMatchingRule(typeof(IDirty)))
      .AddCallHandler("DirtyHandler");
// End Configuration

var customer = container.Resolve<Customer>();

var firstname = customer.FirstName;
Debug.Assert(!customer.IsDirty);
customer.FirstName = "Piet";
Debug.Assert(customer.IsDirty);

The configuration part can also be done through a configuration file. Unfortunately, there is no schema available, this means that there is no validation and intellisense inside your Visual Studio! Especially to describe the matching rules through xml, I had to introduce some extra converters that implement the TypeConverter class. This enables you to convert to any kind of object started from a string. I introduced the PropertyMatchingOptionConverter and GetTypeConverter.

public class PropertyMatchingOptionConverter : System.ComponentModel.TypeConverter
{
   public override object ConvertFrom(System.ComponentModel.ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
   {
      return (PropertyMatchingOption)Enum.Parse(typeof(PropertyMatchingOption), value.ToString());
   }
}

public class GetTypeConverter : System.ComponentModel.TypeConverter
{
   public override object ConvertFrom(System.ComponentModel.ITypeDescriptorContext context, System.Globalization.CultureInfo culture, object value)
   {
      return Type.GetType(value.ToString());
   }
}

Below you find how you use Unity with a configuration file and you find also the resulting xml file that does exactly the same as the above-mentioned version.

IUnityContainer container = new UnityContainer();
UnityConfigurationSection section = (UnityConfigurationSection)ConfigurationManager.GetSection("unity");
section.Containers["Default"].Configure(container);

var customer = container.Resolve<Customer>();

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
  <configSections>
<section name="unity" type="....UnityConfigurationSection, ..."/>
  </configSections>
  <unity>
    <typeAliases>

      <typeAlias alias="bool"     type="System.Boolean, mscorlib" />
      <typeAlias alias="string"   type="System.String, mscorlib" />
      <typeAlias alias="int"      type="System.Int32, mscorlib" />
      <typeAlias alias="Type"     type="System.Type, mscorlib" />

      <typeAlias alias="GetTypeConverter" type="..."/>
      <typeAlias alias="PropertyMatchingOptionConverter" type="..."/>
      <typeAlias alias="InstanceOfMatchingRule" type="..."/>
      <typeAlias alias="DirtyHandler" type="..."/>
      <typeAlias alias="VirtualMethodInterceptor" type="..."/>
      <typeAlias alias="CustomAttributeMatchingRule" type="..."/>
      <typeAlias alias="PropertyMatchingRule" type="..."/>
      <typeAlias alias="PropertyMatchingOption" type="..."/>
      <typeAlias alias="DirtyAttribute" type="..."/>
      <typeAlias alias="IDirty" type="..."/>
      <typeAlias alias="Customer" type="..."/>

    </typeAliases>
    <containers>
      <container name="Default">
        <extensions>
          <add type="....Interception, ..."/>
        </extensions>
        <extensionConfig>
          <add name="interception" type="....InterceptionConfigurationElement, ...">
            <policies>
              <policy name="DirtyPolicy">
                <matchingRules>
                  <matchingRule name="SetPropertyRule" type="PropertyMatchingRule">
                    <injection>
                      <constructor>
                        <param name="propertyName" parameterType="string">
                          <value value="*"/>
                        </param>
                        <param name="option" parameterType="PropertyMatchingOption">
                          <value value="Set" type="PropertyMatchingOption" typeConverter="PropertyMatchingOptionConverter"/>
                        </param>
                      </constructor>
                    </injection>
                  </matchingRule>
                  <matchingRule name="DirtyAttributeRule" type="CustomAttributeMatchingRule">
                    <injection>
                      <constructor>
                        <param name="attributeType" parameterType="Type">
                          <value value="...DirtyAttribute, ..." type="Type" typeConverter="GetTypeConverter"/>
                        </param>
                        <param name="inherited" parameterType="bool">
                          <value value="true" type="bool"/>
                        </param>
                      </constructor>
                    </injection>
                  </matchingRule>
                  <matchingRule name="InstanceOfIDirtyRule" type="InstanceOfMatchingRule">
                    <injection>
                      <constructor>
                        <param name="type" parameterType="Type">
                          <value value="...IDirty, ..." type="Type" typeConverter="GetTypeConverter"/>
                        </param>
                      </constructor>
                    </injection>
                  </matchingRule>
                </matchingRules>
                <callHandlers>
                  <callHandler name="DirtyHandler" type="DirtyHandler"/>
                </callHandlers>
              </policy>
            </policies>
            <interceptors>
              <interceptor type="VirtualMethodInterceptor">
                <key type="Customer"/>
              </interceptor>
            </interceptors>
          </add>
        </extensionConfig>
      </container>
    </containers>
  </unity>
</configuration>

The source code of this article can be downloaded here

  • 2 min read

How to make your Windows Live Writer portable

I am using Windows Live Writer for posting items to my blog. One thing that I don’t like in general, is that applications store resources in the MyDocuments folder and that you cannot specify another location. I’m a huge fan of portable applications, which means that they don’t need any registry settings and/or dependencies, so that you can simply xcopy deploy to another location. Certainly if you are using an external HD, USB flash drive, etc.

Windows Live Writer (WLW) stores by default the drafts in the MyDocuments\My Weblog Posts\Drafts folder. I am using the latest beta (v14.0.5025.904) of WLW and didn’t find any settings through the application that enables you to customize folder paths.

I decided to dig into the assemblies of WLW via reflector to see how it is implemented. After some investigation I found that there is a class called ApplicationEnvironment that reside in the WindowsLive.Writer.CoreServices assembly. The Initialize method looks like this

ReflectorWLW

Apparently WLW has built-in functionality that enables you to run the application with the settings carried around with the software. WLW checks if there is a folder called ‘UserData’ in the installation folder and uses that folder to store all settings, drafts, etc. This is really great, you simply copy all contents of your WLW directory to for example your external drive and you simply create a folder called UserData. If you start WLW again it will create all the necessary subfolders and settings.

ExplorerWLW

I think it’s a feature of WLW beta that has not been documented yet ;-)

  • 2 min read

Organize your NHibernate mapping files inside Visual Studio

NHibernate uses an xml file to describe the mapping. Typically it is embedded as a resource file inside your project and it has a consistent filename convention, namely .hbm.xml. Typically an NHibernate project has the following structure

NHibernate01

Would it not be nice if we can organize it in the following way? I found it always handy that related classes, like designer classes and resource files are grouped together.

NHibernate02

To achieve this structure we can start from the first structure and nest the xml file trough a macro that I’ve written.

The second step, is to make clear to NHibernate where the mapping files reside. Note that resources that are nested to a class are compiled differently and thus NHibernate will not recognize the mapping files anymore. Therefore we need to traverse manually the assembly and try each embedded resource file. Below you find the resulting code

var domainAssembly = typeof(MyDomain.Order).Assembly;
NHibernate.Cfg.Configuration cfg = new NHibernate.Cfg.Configuration();

foreach (var resourceName in domainAssembly.GetManifestResourceNames())
{
   try
   {
      cfg.AddResource(resourceName, domainAssembly);
   }
   catch (NHibernate.MappingException)
   {
      //ignore
   }
}