LINQ to SQL Expressions and WCF

I'm currently involved in an extensive migration of an existing .Net remoting architecture to WCF. The original architecture used Net Tiers in the data layer, which has been replaced by LINQ to SQL. We opted for LINQ to SQL over the Entity Framework, because EDM frankly offers little for a great deal of overhead additionally it just doesn't support functionality that it should.

One of the issues that we ran into during the migration was the migration of services methods that relied on client side criteria to filter the data, the original implementation used code that was heavily dependant on the Net Tiers metadata to write the queries on the client and pass them to the proxy. Initially  it looked as if Expression<Func<T,TResult>> would provide a perfect solution, it allowed us to create the expression and replace the current implementation with little impact. Unfortunately, it turns out that this solution won't work since Expressions can't be serialized. So we were left with the option of rolling a new dynamic query engine that could build the expression trees on the server, based on a string passed from the client. Initial discoveries lead us to believe it was feasible to create the expression in this way, but it would cost hours that we really didn't have.

  Then I ran across this article on ScottGu's blog regarding LINQ dynamic queries. After downloading the C# samples and looking at what it contained, it turned out that for the most part it contained most of the functionality we would need to create. So if you find yourself in need of the ability to pass queries across the wire to LINQ this is a great place to start.

Working around DataContract serialization with existing .Net classes

I'm working on moving some existing code to WCF. The code was originally passed via remoting so I thought it would be a pretty straight forward move. Turns out that's not the case. I ran into an issue with properties defined as System.Object and WCF. The error message that was returned was telling me that the connection was forcibly closed by the host, which I'm finding out can really be interpreted as "There was a problem with the object you want". After tracking the problem for the better part of the day it came down to an issue with the properties which looked like this:

[DataContract]
  public class ContractTest
  {
      [DataMember]
      public int PropOne { get; set; }

      [DataMember]
      public object PropTwo { get; set; }

      [DataMember]
      public string PropThree { get; set; }

      [DataMember]
      public object PropFour { get; set; }
  }

It turns out that the serialization of the data contract can be altered by using the XmlSerializer. This is really helpful when moving older code. So to fix the issue, I modified the class like this:

using System.ServiceModel;

   [DataContract]
   [XmlSerializerFormat]
   public class ContractTest
   {
       [DataMember]
       public int PropOne { get; set; }

      
       public object PropTwo { get; set; }

       [DataMember]
       public string PropThree { get; set; }

      
       public object PropFour { get; set; }
   }

The XmlSerializer will serialize the public properties and the end result is that you can now pass the class through the service noramlly.