Walter Almeida's Blog

Fenomen's brand new Web Site is now available!

We are proud and happy to annouce the public availability of our brand new Web Site : http://www.fenomen.pro, available in french and english.

Feel free to visit our Web Site to find more about FENOMEN and our innovative approach for building connected business applications following a full modeling and generation approach.

via blog.fenomen.pro

Just got my new Thinkpad W510 notebook - Setup with 8Gb RAM, Windows Server 2008 R2 + Hyper-V

I just got my new laptop: A Lenovo Thinkpad W510. Great machine. I used to have a Dell laptop but I was so disapointed with the support service and with the reliability that I changed!

I did install Windows Server 2008 R2 and configured it with Hyper-V and everything works smoothly and fine so far. Just discovered that the W510 integrates a mobile broadband extension so i can use my 3G connection without having this extra annoying USB extension plugged-in , if not forgotten at home...

Here is a link that was usefull to me to setup my laptop with Windows Server 2008 R2:

Installing Windows Server 2008 R2 on a Lenovo ThinkPad W510

Note : i had to get the Ethernet driver from the Intel download page: the one provided by Lenovo for Windows 7 does not work on Windows Server 2008 R2:

http://www.intel.com/support/network/sb/cs-006120.htm

 

Model Driven Development: Code Generation or Model Interpretation?

During Code Generation 2010, I was part of a Birds of a Feather (BoF) session about Code Generation versus Model Interpretation. You can read the feedback from Johan den Haan here:

Model Driven Development: Code Generation or Model Interpretation

Followed by an interresting online discussion on the subject.

Model-View-ViewModel Design Pattern - An implementation of RelayCommand for SilverLight

A common pattern for developping applications with SilverLight and WPF is the Model-View-ViewModel (MVVM) Design Pattern. The MVVP pattern is an evolution of the MVC and MVP well-known pattern, specially adapted to the advanced data binding features of WPF and SilverLight. Please refer to the following excellent MSDN article from Josh Smith for a complete description and implementation of the MVVM Pattern for WPF:

WPF Apps With The Model-View-ViewModel Design Pattern

However, as stated in this article title, we're talking about an MVVM pattern for WPF. For those who have tried to develop portable applications working on both WPF and SilverLight, you know this frustration of discovering small differences between WPF and SilverLight and missing classes in  SilverLight as compared to WPF. 

And in our specific case, Josh defines a RelayCommand class, used to simplified the binding with user interface elements commands with underlying actions in the ViewModel class.

Here is the definition of the RelayCommand class:

public class RelayCommand : ICommand
{
 #region Fields

 readonly Action

This class makes use of the CommandManager object and the RequerySuggested event. When a user actions the UI in WPF, this triggers the CommandManager to requery all the commands. In Silverlight the CommandManager class does not exist: you have to do the work yourself!

So I created the following RelayCommand implementation, working for SilverLight:

 public class RelayCommand : ICommand
 {
 #region Fields

 readonly Action

And here is the definition of the ICommandManager interface:

 public interface ICommandManager
 {
 event EventHandler RequerySuggested;
 }

Now when creating a new command, you should pass a reference to an object implementing the ICommandManager interface. This object will usually be the ViewModel class itself. It is then the responsability of the ViewModel class to trigger the RequerySuggested event when anything in the state of the ViewModel changed that requires the command to be rebinded. That's it, this completes the SilverLight implementation of the MVVM pattern. 

Now going to the Code Generation 2010 Conference - Cambridge

I am now going to the Code generation conference 2010: http://www.codegeneration.net/cg2010/

I did attend the conference last year and I must say it was a real interesting time, meeting many people focused on the same ideas and concept than myself. Most of the people coming from the Java community I must say: not too much professionnals from the Microsoft side. Showing that the Java world still has the characteristic of a research & development environment with a step forward in this area, as compared to the Microsoft guys.

The conference is all about Model driven development, domain specific languages and code generation.

By the way the conference is located in Cambridge and I love the city! Makes the conference even more attractive!

Using Multiple Monitors in Remote Desktop Session

I have just found out a GREAT new feature included in Windows 7 / Windows Server 2008 R2 :

Multiple monitor support for Remote Desktop Services allows users to open a Remote Desktop connection expanded across all the monitors on the client computer regardless of the client monitor configuration. With this feature, the user can fully utilize all the monitors connected to the client computer for the Remote Desktop connection thereby providing extra desktop space and an almost seamless experience with the client desktop that is much improved over “Span mode”.  

I have been so frustated so far to not be able to fully take advantage of my two screens in remote scenarios. And it is more and more usual to work on virtual machines. For instance I develop  with Visual Studio 2010 on a virtual Windows Server 2008 machine, and I was not able so far to fully utilize the multiple screens support of VS2010. I now can:)

The only thing to do to initiate a remote session with multiple screen support is to check the "Use all my monitors for the remote session" box:

 

Find out more here: http://blogs.msdn.com/b/rds/archive/2009/07/01/using-multiple-monitors-in-remote-desktop-session.aspx

Split Button in WPF

WPF is great! I love it. Just so much more convenient and relevant to building user interfaces than Windows Forms!

However, unless you're using third parties components like Telerik, there is still a lack of controls. I recently had the need for a Split button: I button that shows a menu when clicked, to enable kind of a "multi-choices" button. 

Here I found a nice and neat implementation of such a control:

http://blogs.msdn.com/b/llobo/archive/2006/10/25/split-button-in-wpf.aspx

Enjoy!

WCF, DataContract serialization and self-tracking entities - Internals and tips

Custom Data exchanged with WCF services is defined through DataContracts using DataContract and DataMember attributes to the data definition classes. Please refer to the msdn help for more information: 

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

The recommended way of doing so is to apply the DataMember attributes to properties

namespace MyTypes
{
 [DataContract]
 public class PurchaseOrder
 {
 private int poId_value;

 // Apply the DataMemberAttribute to the property.
 [DataMember]
 public int PurchaseOrderId
 {
 get { return poId_value; }
 set { poId_value = value; }
 }
 }
}

However there are cases where you want to apply the DataMember attributes to the fields instead of the properties. I will describe here one of these cases.

The Case

The case is: you want to develop an N-tier application, exposing business data through a WCF service facade. To do so, you define a custom data structure, representing your business, you expose it as a DataContract and you share the DataContract assembly between the WCF service and the client application.

Let's take the following definition of a DataContract representing a contact:

[DataContract]
public class Contact : INotifyPropertyChanged
{
 #region fields

 private string _firstName;
 private string _lastName;
 private bool _isDirty = false;

 #endregion

 #region properties

 [DataMember]
 public string FirstName
 {
 get
 {
 return _firstName;
 }
 set
 {
 if (_firstName == value)
 return;

 _firstName = value;
 OnPropertyChanged("FirstName");
 }
 }

 [DataMember]
 public string LastName
 {
 get
 {
 return _lastName;
 }
 set
 {
 if (_lastName == value)
 return;

 _lastName = value;
 OnPropertyChanged("LastName");
 }
 }

 [DataMember]
 public bool IsDirty
 {
 get
 { 
 return _isDirty;
 }
 set
 {
 if (_isDirty == value)
 return;
 
 _isDirty = value;
 OnPropertyChanged("IsDirty");
 }
 }

 #endregion

 #region methods

 public Contact(string firstName, string lastName)
 {
 _firstName = firstName;
 _lastName = lastName;
 }

 public override string ToString()
 {
 return string.Format("FirstName: '{0}' LastName: '{1}' IsDirty: {2}", FirstName, LastName, IsDirty);
 }

 #endregion

 #region INotifyPropertyChanged implementation

 protected void OnPropertyChanged(string propertyName)
 {
 if (!ReferenceEquals(null, PropertyChanged))
 PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

 if (propertyName != "IsDirty")
 IsDirty = true;
 }

 public event PropertyChangedEventHandler PropertyChanged;

 #endregion

}

The only addition to the first simple case is the support for the INotifyPropertyChanged interface. Indeed, if you want to develop a proper application, you probably want to handle self-tracking entities, to make sure the service at server level can easily figure out what happened to the data in order to efficiently process it. First step to handling self-tracking entities is to be able to determine whether data has been changed since last retrieval. This is handled through the IPropertyChanged interface.

Here starts our problems.

Let's take following service definition:

[ServiceContract]
public interface IContactService
{
 [OperationContract]
 Contact PassContactThrough(Contact theContactToPassThrough);
}

And service implementation:

public class ContactService : IContactService
{
 public Contact PassContactThrough(Contact theContactToPassThrough)
 {
 return theContactToPassThrough;
 }
}

All this operation is doing is passing the Contact through. We therefore expect to get back the same Contact information as the one we initially sent.

To test this, let's create a client, add a reference to the service and to the data contract assembly and do the following implementation:

static void Main(string[] args)
{
 ContactServiceClient service = new ContactServiceClient(); 

 var contactToPassThrough = new Contact("Walter", "Almeida");

 Console.WriteLine("Contact Before Service Call: " + contactToPassThrough.ToString());
 
 Contact returnedContact = service.PassContactThrough(contactToPassThrough);
 
 Console.WriteLine("Contact After Service Call: " + returnedContact.ToString());
}

We send through a Contact data for Walter Almeida. The Contact is clean, marked with IsDirty = false.

However, the returned Contact contains the proper "Walter Almeida" information but is marked ad IsDirty = true!

The explanation is the following: when sent to the service, the Contact data is serialized, accordingly to the DataMember attributes information. When received by the service, the received data is deserialized into a new Contact instance. When deserializing, the service will assign values to the Contact instance properties, because it is the properties that  are marked as DataMembers. When doing so: the OnPropertyChanged method is called and IsDirty is set to true.

We could have been lucky here if IsDirty (also marked as DataMember) would be the last one to be deserialized thus compensating the previous calls to IsDirty = true. However when no specified otherwise, the DataMembers are serialized in alphabetical order. Therefore IsDirty is deserialized before LastName...

Here are candidate solutions to this problem with benefits and drawbacks:

Solution 1: Do not share the exact same DataContract assembly 

Instead of sharing the exact same data contract assembly, the server should use a assembly that has the datacontract definition without the INotifyPropertyChanged interface implementation: just data, no behaviour:

[DataContract]
public class Contact : INotifyPropertyChanged
{
 #region fields

 private string _firstName;
 private string _lastName;
 private bool _isDirty = false;

 #endregion

 #region properties

 [DataMember]
 public string FirstName
 {
 get
 {
 return _firstName;
 }
 set
 {
 _firstName = value;
 }
 }

 [DataMember]
 public string LastName
 {
 get
 {
 return _lastName;
 }
 set
 {
 _lastName = value;
 }
 }

 [DataMember]
 public bool IsDirty
 {
 get
 {
 return _isDirty;
 }
 set
 {
 _isDirty = value;
 }
 }

 #endregion

}

However this requires two different versions of the data definition, leading to the associated maitainability issues.

Moreover we also loose all the tracking capabilities at server side, which is wrong: it is possible for the service to perform actions on the data and therefore these actions should be also tracked.

Solution 2: Change order of properties serialization

By default DataMembers are serialized in alphabetical order. You can redefine this order the following way:

[DataContract]
public class Contact : INotifyPropertyChanged
{
 #region fields

 private string _firstName;
 private string _lastName;
 private bool _isDirty = false;

 #endregion

 #region properties

 [DataMember(Order = 0)]
 public string FirstName
 {
 get
 {
 return _firstName;
 }
 set
 {
 if (_firstName == value)
 return;
 
 _firstName = value;
 OnPropertyChanged("FirstName");
 }
 }

 [DataMember(Order = 1)]
 public string LastName
 {
 get
 {
 return _lastName;
 }
 set
 {
 if (_lastName == value)
 return;

 _lastName = value;
 OnPropertyChanged("LastName");
 }
 }

 [DataMember(Order = 2)]
 public bool IsDirty
 {
 get
 {
 return _isDirty;
 }
 set
 {
 if (_isDirty == value)
 return;
 
 _isDirty = value;
 OnPropertyChanged("IsDirty");
 }
 }

 #endregion

 #region methods

 public Contact(string firstName, string lastName)
 {
 _firstName = firstName;
 _lastName = lastName;
 }

 public override string ToString()
 {
 return string.Format("FirstName: '{0}' LastName: '{1}' IsDirty: {2}", FirstName, LastName, IsDirty);
 } 

 #endregion

 #region INotifyPropertyChanged implementation

 protected void OnPropertyChanged(string propertyName)
 {
 if (!ReferenceEquals(null, PropertyChanged))
 PropertyChanged(this, new PropertyChangedEventArgs(propertyName));
 if (propertyName != "IsDirty")
 IsDirty = true;
 }

 public event PropertyChangedEventHandler PropertyChanged;

 #endregion

}

The problem is now solved: IsDirty is not altered by the deserialization. Or better said: the IsDirty value is altered during deserialization but restored to the proper value at the end of deserialization when the IsDirty value is deserialized.

This solution is working but not perfect: there are still unecessary calls to the property changed event handler. And it can become cumbersome if we further complexify the Contact class. Moreover this solution does not work if we define a hierarchy of data classes and define the IsDirty property on the base class:

public class BaseContact : INotifyPropertyChanged
{
 #region fields
 
 private bool _isDirty = false;
 
 #endregion

 #region properties

 [DataMember]
 public bool IsDirty
 {
 get
 {
 return _isDirty;
 }
 set
 {
 if (_isDirty == value)
 return;
 
 _isDirty = value;
 OnPropertyChanged("IsDirty");
 }
 }

 #endregion

 #region INotifyPropertyChanged implementation

 protected void OnPropertyChanged(string propertyName)
 {
 if (!ReferenceEquals(null, PropertyChanged))
 PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

 if (propertyName != "IsDirty")
 IsDirty = true;
 }

 public event PropertyChangedEventHandler PropertyChanged;

 #endregion
}


[DataContract]
public class Contact : BaseContact
{
 #region fields

 private string _firstName;
 private string _lastName;

 #endregion

 #region properties

 [DataMember]
 public string FirstName
 {
 get
 {
 return _firstName;
 }
 set
 {
 if (_firstName == value)
 return;
 
 _firstName = value;
 OnPropertyChanged("FirstName");
 }
 }

 [DataMember]
 public string LastName
 {
 get
 {
 return _lastName;
 }
 set
 {
 if (_lastName == value)
 return;

 _lastName = value;
 OnPropertyChanged("LastName");
 }
 }

 #endregion

 #region methods

 public Contact(string firstName, string lastName)
 {
 _firstName = firstName;
 _lastName = lastName;
 }

 public override string ToString()
 {
 return string.Format("FirstName: '{0}' LastName: '{1}' IsDirty: {2}", FirstName, LastName, IsDirty);
 }

 #endregion

}

In this case setting orders on DataMembers will not solve the problem because DataMembers of base classes (and therefore IsDirty) are always serialized/deserialized first.

Solution 3: Mark fields as DataMember instead of properties

Third solution is to mark the fields with the DataMember attribute, rather than the properties. This way, the deserialization step will set fields rather than properties and therefore OnPropertyChanged will never be called.

The limitation is that serialization of private fields is not allowed in partial trust scenarios (and this is the case for instance when developping a SilverLight client). Everything works fine when running in a full trust environment. To overcome this issue, the fields must be set as internal rather than private and you need to mark the assembly defining the data contracts with the following attribute (in assemblyinfo.cs):

[assembly: InternalsVisibleTo("System.Runtime.Serialization")]

This gives access right to the serialization assmebly to access your internal members. Not doing so would result in the following exception at runtime, when running in partial trust environments: 

The data contract type 'Contact' cannot be deserialized because the property '_firstName' does not have a public setter. Adding a public setter will fix this error. Alternatively, you can make it internal, and use the InternalsVisibleToAttribute attribute on your assembly in order to enable serialization of internal members - see documentation for more details. Be aware that doing so has certain security implications

So here is the final version of the Contact data contract:

[DataContract]
public class Contact : INotifyPropertyChanged
{
 #region fields

 [DataMember( Name = "FirstName")]
 internal string _firstName;

 [DataMember( Name = "LastName")]
 internal string _lastName;
 
 [DataMember( Name = "IsDirty")]
 internal bool _isDirty = false;

 #endregion

 #region properties

 public string FirstName
 {
 get
 {
 return _firstName;
 }
 set
 {
 if (_firstName == value)
 return; 
 
 _firstName = value;
 OnPropertyChanged("FirstName");
 }
 }

 public string LastName
 {
 get
 {
 return _lastName;
 }
 set
 {
 if (_lastName == value)
 return;
 
 _lastName = value;
 OnPropertyChanged("LastName");
 }
 }

 public bool IsDirty
 {
 get
 {
 return _isDirty;
 }
 set
 {
 if (_isDirty == value)
 return;
 
 _isDirty = value;
 OnPropertyChanged("IsDirty");
 }
 }
 #endregion

 #region methods

 public Contact(string firstName, string lastName)
 {
 _firstName = firstName;
 _lastName = lastName;
 }

 public override string ToString()
 {
 return string.Format("FirstName: '{0}' LastName: '{1}' IsDirty: {2}", FirstName, LastName, IsDirty);
 }

 #endregion

 #region INotifyPropertyChanged implementation

 private void OnPropertyChanged(string propertyName)
 {
 if (!ReferenceEquals(null, PropertyChanged))
 PropertyChanged(this, new PropertyChangedEventArgs(propertyName));

 if (propertyName != "IsDirty")
 IsDirty = true;
 }
 
 public event PropertyChangedEventHandler PropertyChanged;

 #endregion
}

Please note the extra Name = xx setting of the DataMembers. This is to ensure we get a equivalent data schema as the one when marking the Properties as DataMembers. This implementation solves our issue and works in both full trust and partial trust environment. That's it for now!

Using the dynamic Keyword in C# to Improve Object-Orientation

C# 4.0 introduces the new 'dynamic' keyword to the language, adding dynamic support to the .NET Framework though the DLR (Dynamic Language Runtime). 

My first understanding of the use of such a dynamic support was the following:

• Great to use for inter-connections with dynamic langages, avoiding to have to write too complex code to bridge the gap between the 2 languages.
• Great to use for instance for Microsoft Office automation. MS Office automation is done though COM objects. Previous use of MS Office PIA was cumbersome. The new dynamic keyword makes much less verbose.
• Enhance support for reflection.

With the dynamic keyword, type checking is no more done at compile time but will be done at runtime. Thus making code writing more flexible (especially when using uncertain type, only known at runtime). However it makes writing code less safe (no compile checking) and less productive (no intellisense). Therefore one should not use the dynamic keyword in C#, except in previous cases. And use instead Object orientation design principles and patterns to achieve safe, strongly-typed coding. Moreover, the addition of generics to the .NET Framework 2.0 was a huge step forward to enable better object orientation and strong typing.

So IMHO the dynamic keyword and DLR is a great thing to have but will also be an added opportunity to write bad code and break core design principles. So one should be aware of it and use it sparingly, when making real sense!

Moreover be aware that the use of the dynamic keyword has a performance hit: because runtime discovery and type checking has to be done at runtime.

I came accross a post from Peter Ritchie highlighting another great use of the dynamic keyword. I said previously that when developing in C#, you should use as much as possible proper object orientation principle and patterns to write proper good code (because C# is a OO language). However there are cases where it is not easy to write full pure object oriented code. And Peter describes one of these cases and how the dynamic keyword can help:

http://msmvps.com/blogs/peterritchie/archive/2010/05/24/using-the-dynamic-keyword-in-c-to-improve-object-orientation.aspx

The case is the following (for more details please refer to Peter Ritchie's post):

When you use method overloading to define methods that take different flavors of a given type hierarchy (Circle and Square both derive from Shape):

public static void Draw(Circle circle)
{
 //... 
}

public static void Draw(Square square)
{
 //... 
}

When you want to call the Draw method, you have to call it with an object that is known at compile time to be either a Circle or a Square (or inheriting from Circle or Square). You cannot call it generically with a object of type Shape. This is because the compiler must know which method overload to link to.

Please note that this example is probably not the best as a solution could be to define the Draw method on the Shape class and override it on both Circle and Square. However there are cases where this scenario really makes sense, so just take this as a sole demonstration purpose, and get the idea of what the dynamic keyword could bring.

Back to our example, the following method will not compile:

public void ProcessShape(Shape shape)
{
 //...
 Draw(shape); 
 //...
}

You instead have to write something like 

public void ProcessShape(Shape shape)
{
 //...
 if (!ReferenceEquals(null, shape as Square))
 {
 Draw(shape as Square);
 }
 if (!ReferenceEquals(null, shape as Circle))
 {
 Draw(shape as Circle);
 }
 //... 
}

Thus wasting the interest of object orientation, adding a maintenance point for when new Shape types are added etc...

Solution with using the dynamic keyword is:

public void ProcessShape(Shape shape)
{
 //...
 dynamic dynShape = shape; 
 Draw(dynShape); 
 //...
}

The type checking done previously in code is now done by the DLR and the code is more robust: we have elimintated the maintenance point.

And here is the full code that demonstrate the use of the dynamic keyword (just create a Console app to include this code):

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;

namespace ConsoleApplication1
{
 public class Shape
 { 
 }

 public class Circle : Shape
 {
 }

 public class Square: Shape
 {
 }

 class Program
 {
  static void Main(string[] args)
  {
   Shape myShape = null;
 
   myShape = new Square(); 
   ProcessShape(myShape);

   myShape = new Circle();
   ProcessShape(myShape);

   Console.ReadLine();
  }

  static void ProcessShape(Shape shape)
  {
   //Draw(shape);
   dynamic dynShape = shape;
   Draw(dynShape);
  }

  static void Draw(Square square)
  {
   Console.WriteLine("I am a Square");
  }

  static void Draw(Circle circle)
  {
   Console.WriteLine("I am a Circle");
  }
 }

}

This is a great use of the dynamic keyword. However: this is also a good example to show that the dynamic keyword could be used improperly instead of a right object oriented design: We said before that in this specific case, it could probably better to add a Draw method on the Shape class and override it on derived class : this is a basic OO design principle: classes embed data and behavior. Thing is there is no definite rule: depending on your overall design and architecture (and especially the level of coupling you want to have), it could be good design to have the Draw method excluded from the Shape class. So nothing replaces experience, however the enhancement of the programming languages will add more and more confusion for beginners! And this makes the software design and development really challenging and exciting!

Advanced Linq - Dynamic Linq query library: Add support for 'Contains' extension

This post explains how to extend the Dynamic Linq library to support the "Contains" extension method. This post also can serve as a base for further extension of the Dynamic Linq Library and adding support to more extension methods.

Linq is an amazing programming model, brought to life by the Microsoft.NET Framework 3.5, that introduces data queries as a first-class concept into any Microsoft programming langage.

Linq allows you to build strongly type queries to access data in any source for which a Linq support library is available, including MS SQL, data objects (through IEnumerable and IQueryable), Entity Framework and more.

Even though the regular, strongly typed approach to building queries is definitively recommended, in some cases arises the need for dynamically building queries. For this purpose Microsoft freely provides an open source dynamic Linq query library. Cases for using dynamic queries could be for example: you might want to provide business intelligence UI within your application that allows an end-user business analyst to use drop-downs to build and express their own custom queries/views on top of data. Another example is the creation of RESTfull service interfaces that accept query string parameters that could be converted to dynamic linq queries.

Please refer the the Scott Guthrie post for more information on the Dynamic Linq Query library:

http://weblogs.asp.net/scottgu/archive/2008/01/07/dynamic-linq-part-1-using-the-linq-dynamic-query-library.aspx

I found this library very usefull and used it in several scenarios. However this library does not support all of the Linq extensions. I had the need for building dynamic queries with the "Contains" extension which was not supported by the Microsoft Dynamic Linq library. This post explains how to extend the Dynamic Linq library to support the "Contains" extension method. 

Sample Code

Here is the sample application we use to illustrate our tallks (You can download the source code here) : 

We define a class "Contact". For the purpose of demonstration, we do not connect to a data source, but have a static "GetContactList" method that return a collection of users. 

public class Contact
{
 public string FirstName { get; set; }
 public string LastName { get; set; }
 public DateTime BirthDate { get; set; }
 public string Country { get; set; }

 public Contact(string firstName, string lastName, DateTime birthDate, string country)
 {
 FirstName = firstName;
 LastName = lastName;
 BirthDate = birthDate;
 Country = country;
 }

 public override string ToString()
 {
  return string.Concat(FirstName, " ", LastName, " ", BirthDate, " ",Country);
 }
 
 public static List‹contact› GetContactsList()
 {
  var result = new List‹contact›();
 
  result.Add(new Contact("Zephr", "Austin", new DateTime(1967, 11, 07), "Afghan"));
  result.Add(new Contact("Odette", "Bean", new DateTime(1993, 05, 18), "Uzbekistan"));
  result.Add(new Contact("Maggie", "Mcson", new DateTime(2001, 06, 12),"Kiribati"));
  ...
  ...
 
  return result;
 }
}

 

The Case – Use of the Dynamic Linq Library and missing support for the “Contains”  extension method

 

Let's take a first example of simple Linq query to get the contacts located in Austria. Using regular Linq, you write the following query:

var query = from c in Contact.GetContactsList() where c.Country == "Austria" select c;

Or the equivalent query, using extension methods and lambda 

var query = Contact.GetContactsList().Where(c => c.Country == "Austria");

We will keep the second syntax as the dynamic linq library does not support the first syntax.

We can then iterate the query result and retrieve relevant contact information:

foreach (var contact in query)
{
 Console.WriteLine(contact.ToString());
} 

Doing the same query using dynamic Linq: 

query = Contact.GetContactsList().AsQueryable().Where("Country == @0", "Austria");

Please not the extra "AsQueryable()" call because the dynamic extension applies on collections implementing IQueryable. Then Iterating the results is just the same as with regular Linq.

The Dynamic Linq library also supports more complex queries. For instance here is the Dynamic Linq query to retrieve all contacts in Austria, born in 1957: 

query = Contact.GetContactsList().AsQueryable().Where("Country == @0 && BirthDate.Year == 1957", "Austria");

 

Everythings seems to magically work so far. Let’s try now a more complex scenario: when want to retrieve the list of contacts located in given list of countries. Let’s say : all contacts located in either Austria or Poland. For such a purpose, a common solution is to use the “Contains” extension method:

query = Contact.GetContactsList().Where(c => new List<string>>() { "Austria", "Poland" }.Contains(c.Country));

 

In Linq to SQL, the result pseudo SQL projection would be:

select * from contact c where c.Country in (‘Austria’, ‘Poland’);

 

Let’s try to write the same query in Dynamic Linq (using parameters to pass the input list of countries):

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(Country)", new List<string>() { "Austria", "Poland" });

 

This result at runtime to the following exception: “No applicable aggregate method 'Contains' exists”,

Emphasizing the fact the Dynamic Linq library does not have support for the “Contains” extension method. The following section will explains how to add support for “Contains”.

 

Add support for the “Contains” extension method

Analyzing the “Dynamic.cs” class that adds support for Dynamic Linq, you’ll find the definition of the  IEnumerableSignatures interface. This interface lists all IEnumerable extension methods that are supported by the Dynamic Linq library. You should add the “Contains” extension method signature:

interface IEnumerableSignatures
{
 void Contains(object selector);
 void Where(bool predicate);
 void Any();
 void Any(bool predicate);
 void All(bool predicate);
 void Count();
 void Count(bool predicate);
 void Min(object selector);
 void Max(object selector);
 void Sum(int selector);
 void Sum(int? selector);
 void Sum(long selector);
 void Sum(long? selector);
 void Sum(float selector);
 void Sum(float? selector);
 void Sum(double selector);
 void Sum(double? selector);
 void Sum(decimal selector);
 void Sum(decimal? selector);
 void Average(int selector);
 void Average(int? selector);
 void Average(long selector);
 void Average(long? selector);
 void Average(float selector);
 void Average(float? selector);
 void Average(double selector);
 void Average(double? selector);
 void Average(decimal selector);
 void Average(decimal? selector);
}

 

The IEnumerableSignatures interface is then used in the following method:

 

Expression ParseAggregate(Expression instance, Type elementType, string methodName, int errorPos) 
{
 ParameterExpression outerIt = it;
 ParameterExpression innerIt = Expression.Parameter(elementType, "");
 it = innerIt;
 Expression[] args = ParseArgumentList();
 it = outerIt;
 MethodBase signature;
 if (FindMethod(typeof(IEnumerableSignatures), methodName, false, args, out signature) != 1)
 throw ParseError(errorPos, Res.NoApplicableAggregate, methodName);
 Type[] typeArgs;
 if (signature.Name == "Min" || signature.Name == "Max") {
 typeArgs = new Type[] { elementType, args[0].Type };
 }
 else {
 typeArgs = new Type[] { elementType };
 }
 if (args.Length == 0) {
 args = new Expression[] { instance };
 }
 else {
 args = new Expression[] { instance, Expression.Lambda(args[0], innerIt) };
 }

 return Expression.Call(typeof(Enumerable), signature.Name, typeArgs, args);
}

 

There 2 changes to perform to that method.

Fist, the arguments are constructed using the following line:

args = new Expression[] { instance, Expression.Lambda(args[0], innerIt) };

 

this has to be changed specifically for the Contains methods to the following:

args = new Expression[] { instance, args[0] };

Reason is that the signature of the Contains extension methods differs from the others. Let’s take an example: here are the definitions for the “Any” and “Contains” extension methods of the IEnumerable<> interface (classe “System.Linq.Enumerable”):

 

Any<TSource>(this.System.Collections.Generic.IEnumerable<TSource>, System.Func<TSource,bool>);
Contains<TSource>(this.System.Collections.Generic.IEnumerable<TSource>, TSource);

 

You can see that the parameter of the “Any” extension method is a lambda expression taking “TSource” (type of innerIt in our Dynamic Linq library) as entry and returning ”bool” .This explains the transformation Expression.Lambda(args[0], innerIt). In the case of the “Contains” extension method, type of the argument is not a Lambda but just “TSource”.

Next change is the following: the Dynamic Linq library transforms the input string to a proper Linq query by parsing the input string. It internally keeps a context to the current collection being processed. This is the use of the field “innerIt”. When processing our list of “Contacts”, the innerIt represent a “Contact”. However, when processing the “Contains” method, the context changes from the list of “Contacts” to the list being the source for the “Contains” method; in our case: the list of string representing country name. Therefore the parsing of the following dynamic Linq expression:

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(Country)", new List<String>() { "Austria", "Poland" });

will not work: the parser will try to find a property “Country” on type String, where we meant a property “Country” on “Contact”.

In fact the previous query is equivalent to:

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(it.Country)", new List<String>() { "Austria", "Poland" });

Where “it” is the keyword defined in the Dynamic Linq library to represent the current element. It represents here the current item in the list {“Austria”, “Poland”}. What we would like here is the following syntax:

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(outerIt.Country)", new List<String>() { "Austria", "Poland" });

where “outerIt” represents the englobing context: the list of “Contacts”.  For this we should define an “outerIt” keyword, and use it in the “ParseAggregate” method. The new implementation of the “ParseAggregate” methods is now:

Expression ParseAggregate(Expression instance, Type elementType, string methodName, int errorPos) 
{
 outerIt = it;
 ParameterExpression innerIt = Expression.Parameter(elementType, "");
 it = innerIt;
 Expression[] args = ParseArgumentList();
 it = outerIt;
 MethodBase signature;
 if (FindMethod(typeof(IEnumerableSignatures), methodName, false, args, out signature) != 1)
  throw ParseError(errorPos, Res.NoApplicableAggregate, methodName);
 Type[] typeArgs;
 if (signature.Name == "Min" || signature.Name == "Max") {
  typeArgs = new Type[] { elementType, args[0].Type };
 }
 else
 {
  typeArgs = new Type[] { elementType };
 }
 if (args.Length == 0) {
  args = new Expression[] { instance };
 }
 else {
  if (signature.Name == "Contains")
  args = new Expression[] { instance, args[0] };
  else
  args = new Expression[] { instance, Expression.Lambda(args[0], innerIt) };
 }
 return Expression.Call(typeof(Enumerable), signature.Name, typeArgs, args);
}

 

By the way: it is important to mention that since “it” and “outerIt” are defined keywords, they become reserved keywords and should not be used as properties or method definitions in your data classes, if you intend to access them as part of dynamic queries. It would result in a runtime error. Since the common used code standards are to use only capitalized names for public properties and methods, it should be alright in most of the cases.

Remains the use of the “outerIt” keyword. Definition of the keyword and class level storage of its current value:

static readonly string keywordOuterIt = "outerIt";
ParameterExpression outerIt;

 

Taking into account the new keyword in « ParseIdentifier »

 

Expression ParseIdentifier() 
{
 ValidateToken(TokenId.Identifier);
 object value;
 if (keywords.TryGetValue(token.text, out value)) {
 if (value is Type) return ParseTypeAccess((Type)value);
 if (value == (object)keywordIt) return ParseIt();
 if (value == (object)keywordOuterIt) return ParseOuterIt();
 if (value == (object)keywordIif) return ParseIif();
 if (value == (object)keywordNew) return ParseNew();
 NextToken();
 return (Expression)value;
 }
 ...
 ...

 

And new method “ParseOuterIt”:

 

Expression ParseOuterIt()
{
 if (outerIt == null)
 throw ParseError(Res.NoItInScope);
 NextToken();
 return outerIt;
}

 

 

Conclusion

 

That’s it ! The Dynamic Linq library is now supporting the « Contains » extension method

You’ll find the modified “Dynamic.cs” class as part of the code sample. You can now write and successfully run queries likes the following:

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(outerIt.Country)", new List<String>() { "Austria", "Poland" });

or:

query = Contact.GetContactsList().AsQueryable().Where("@0.Contains(outerIt.Country) && it.BirthDate.Year > @1", new List<string>() { "Austria", "Poland" }, 1955);

This post can be used to further extend the Dynamic Linq library and add support for more extension methods.

Hope this can help other who faced the same limitation and help move forward the Dynamic Linq Library!

You can download the source code for the sample project here.