Hi,

First, let me say thanks for building this library! I'd really go insane building XML CAML queries without it.

We've been working with the SharePoint Client Object Model for our application and whilst Camlex.NET does a great job of creating basic queries we also wanted to use the .ViewFields functionality. So we've made some small changes do the latest source code to adapt it to this purpose (source code attached to this work item).

The following (high level) changes were made:

• Microsoft.SharePoint references were changed to Microsoft.SharePoint.Client
• SPListItem type dependencies were updated to ListItem
• Modified .ToCaml() to only output XML with a surrounding <View> and <Query> elements (since CamlQuery.ViewXml needs this) (and updated the existing unit tests)
• Modified .ViewFields methods to return IQuery rather than string (and updated the existing unit tests)
• Modified .ToCaml to also output the <ViewFields> element (and updated the existing unit tests)
• Commented out unit tests that test for Guid functionality (ListItem.this[Guid] doesn't exist in the Client Object Model)
• Commented out unit tests that test for int support (ListItem.this[int] doesn't exist in the Client Object Model)
• Commented out unit tests that test for specific field Id (the SPBuiltInFieldId class does not exist in the Client Object Model)
  

These changes allow us to write code like...

Camlex.Query().ViewFields(l => l["Title"]).Where(l => (string)l["Title"] == "FooBar");

and get a query that will work with CamlQuery in the managed client object model:

<View>
<ViewFields>

<FieldRef Name="Title" />

</ViewFields>
<Query>

<Where>
  <Eq>
    <FieldRef Name="Title" />
    <Value Type="Text">FooBar</Value>
  </Eq>
</Where>

</Query>
</View>

So, the point of this work item is to really propose that Camlex supports the Client Object Model out-of-the-box. The changes required are actually quite minor although the differences around ViewFields are definitely incompatible. I'm not suggesting that you use the code that I've provided (I haven't put any effort into having the same assembly support both the COM and Server APIs) but it does demonstrate how little work is required.

Hopefully you guys have the time do to this.

Cheers,
Scriv