We have just released an updated version of the SSDS sample application called 'PhluffyFotos'.  Clouds are fluffy and this is a cloud services application - get it?  This sample application is a ASP.NET MVC and Windows Mobile application showing how to build a photo tagging and sharing site using our cloud data service, SSDS.  For this update:

• Updated to MVC Preview 4.  We have removed hardcoded links and used the new filtering capability for authorization.  Of course, Preview 5 was just (and just) released as we were putting this out the door.  I might update this to Preview 5 later, but it will not be a big deal to do so. 
• Updated to add thumbnail support.  Originally, we just downloaded the entire image and resized to thumbnail size.  This drags down performance in larger data sizes, so we fixed it for this release.
• Updated to use the SSDS blob support.  Blob support was recently added with the latest sprint.  Previously, we were using the 'base64Binary' attributes to store the picture data.  With the new blob support, you supply a content type and content disposition, which will be streamed back to you on request. 
• Updated to use the latest SSDS REST library.  This library gives us the ability to use and persist CLR objects to the service and use a LINQ-like query syntax.  This library saved us a ton of time and effort in building the actual application.  All the blob work, querying, and data access was done using this library.

The sample is available for download at CodePlex, and a live version is available to play with at PhluffyFotos.com.  I am opening this one up to the public to upload photos.  Maybe I am playing with fire here, so we will see how well it goes.  Keep in mind that this is a sample site and I will periodically blow away the data.  The live version has an added feature of integrating a source code viewer directly into the application.

I have just updated the Code Gallery page to reflect the new version of the REST-based library for SSDS.  This is a fairly major update to library and adds a ton of new features to make working with SSDS even easier than it already is for the .NET developer.  Added in this release:

• Concurrency support via Etags and If-Match, If-None-Match headers.  To get a basic understanding of how this works, refer here.
• Blob support.  The library introduces a new type called SsdsBlobEntity that encapsulates working with blobs in SSDS.  Overloads are available for both synchronous as well as async support.
• Parallelization support via extension methods.  The jury is still out on this one and I would like to hear some feedback on it (both the technique as well as the methods).  Instead of using an interface, factory methods, etc., we are using extension methods supplied in a separate assembly to support parallel operations.  Since there are many different techniques to parallelize your code, this allows us to offer more than one option.  Each additional assembly can also take dependencies that the entire library might not want to take as well.  Imagine that we get providers for Parallel Extensions, CCR, or perhaps other home-baked remedies.  A very simple provider using Parallel Extensions is included.
• Bug fixes.  Hard to believe, but yes, I did have a few bugs in my code.  This release cleans up a few of the ones found in the LINQ expression syntax parser as well as a few oversights in handling date/times.
• Better test coverage.  Lots more tests included to not only prove out that stuff works, but also to show how to use it.

If you just want to see this library in action, refer to the photo sharing and tagging application called 'PhluffyFotos' that pulls it all together (sans parallelization, I suppose).  You can use the integrated source viewer to see how the library works on a 'real' application (or a real sample application at least).

Eugenio already covered concurrency via the SOAP interface with with latest post.  The idea is exactly the same in REST, but the mechanics are slightly different.  For REST, you specify a "Etag" value and either the If-Match or If-None-Match headers.

Here is a simplified client that does a PUT/POST operation on SSDS:

            internal
            void Send(Uri
scope, string etag, string method, string data,
Action<string, WebHeaderCollection> action,
Action<WebException> exception) { using (var
client = new WebClient { Credentials = _credentials
}) { client.Headers.Add(HttpRequestHeader.ContentType, "application/x-ssds+xml"); if (etag
!= null) client.Headers.Add(HttpRequestHeader.IfMatch,
etag); client.UploadStringCompleted += (sender, e) => { if (e.Error
!= null && exception != null)
{ exception((WebException)e.Error); } else { if (action
!= null) { action(e.Result, client.ResponseHeaders);
} } }; client.UploadStringAsync(scope, method, data); } }

All this does is add the If-Match header and the Etag (which corresponds to the Flexible Entity Version system attribute).  This instructs the system to only update if the version held in SSDS matches the version specified in the Etag with the If-Match header.

Failure of this condition will result in a 412 error "A precondition, such as Version, could not be met".  You simply need to handle this exception and move on.

Next, there are times when you have a large blob or a largish flexible entity.  You only want to perform the GET if you don't have the latest version.  In this case, you specify the Etag again with the If-None-Match header.

Here is a simplified client that shows how the GET would work:

            public
            void Get(Uri
scope, string etag, Action<string,
WebHeaderCollection> action, Action<WebException> exception) { using (var
client = new WebClient { Credentials = _credentials
}) { client.Headers.Add(HttpRequestHeader.ContentType, "application/x-ssds+xml"); if (etag
!= null) client.Headers.Add(HttpRequestHeader.IfNoneMatch,
etag); client.DownloadStringCompleted += (sender, e) => { if (e.Error
!= null && exception != null)
{ exception((WebException)e.Error); } else { if (action
!= null) action(e.Result, client.ResponseHeaders);
} }; client.DownloadStringAsync(scope); } 

When you add the Etag and this header, you will receive a 304 error "Not Modified" if the content has NOT changed since the Etag value you sent.

I am attaching a small Visual Studio sample that includes this code and demonstrates these techniques.

Here is my last installment in this series of working with objects in SQL Server Data Services.  For background, readers should read the following:

Serialization in SSDS

Working with Objects in SSDS Part 1

Working with Objects in SSDS Part 2

Last time, we concluded with a class called SsdsEntity<T> that became an all-purpose wrapper or veneer around our CLR objects.  This made it simple to take our existing classes and serialize them as entities in SSDS.

In this post, I want to discuss how the querying in the REST library works.  First a simple example:

var ctx = new SsdsContext( "authority=http://dunnry.data.beta.mssds.com/v1/;username=dunnry;password=secret" );
var container = ctx.OpenContainer("foo"); var
foo = new Foo { IsPublic = false,
Name = "MyFoo", Size = 12 }; //insert
it with unique id guid string container.Insert(foo, Guid.NewGuid().ToString()); //now
query for it var results = container.Query<Foo>(e => e.Entity.IsPublic
== false && e.Entity.Size > 2); //Query<T>
returns IEnumerable<SsdsEntity<T>>, so foreach over itforeach (var
item in results) { Console.WriteLine(item.Entity.Name);
}

I glossed over it in my previous posts with this library, but I have a class called SsdsContext that acts as my credential store and factory to create SsdsContainer objects where I perform my operations.  Here, I have opened a container called 'foo', which would relate to the URI (http://dunnry.data.beta.mssds.com/v1/foo) according to the authority name I passed on the SsdsContext constructor arguments.

I created an instance of my Foo class (see this post if you want to see what a Foo looks like) and inserted it.  We know that under the covers we have an XmlSerializer doing the work to serialize that to the proper POX wire format.  So far, so good.  Now, I want to retrieve that same entity back from SSDS. The key line here is the table.Query<T>() call.  It accepts a Expression<Func<SsdsEntity<T>, bool>> argument that represents a strongly typed query.

For the uninitiated, the Expression<TDelegate> is a way to represent lambda expressions in an abstract syntax tree.  We can think of them as a way to model what the expression does without generating the bits of code necessary to actually do it.  We can inspect the Expression and create new ones based on it until finally we can call Compile and actually convert the representation of the lambda into something that can execute.

The Func<SsdsEntity<T>, bool> represents a delegate that accepts a SsdsEntity<T> as an argument and returns a boolean.  This effectively represents the WHERE clause in the SSDS LINQ query syntax.  Since SsdsEntity<T> contains an actual type T in the Entity property, you can query directly against it in a strongly typed fashion!

What about those flexible properties that I added to support flexible attributes outside of our T?  I mentioned that I wanted to keep the PropertyBucket (a Dictionary<string, object>) property public for querying.  In order to use the flexible properties that you add, you simply use it in a weakly typed manner:

var results = container.Query<Foo>(e => e.PropertyBucket["MyFlexProp"]
> 10);

As you can see, any boolean expression that you can think of in the string-based SSDS LINQ query syntax can now be expressed in a strongly-typed manner using the Func<SsdsEntity<T>, bool> lambda syntax.

How it works

Since I have the expression tree of what your query looks like in strongly-typed terms, it is a simple matter to take that and convert it to the SSDS LINQ query syntax that looks like "from e in entities where [....] select e" that is appended to the query string in the REST interface.  I should say it is a simple matter because Matt Warren did a lot of the heavy lifting for us and provided the abstract expression visitor (ExpressionVisitor) as well as the expression visitor that partially evaluates the tree to evaluate constants (SubTreeEvaluator).  This last part is important because it allows us to write this:

            int i
= 10; string name = "MyFoo";
var results = container.Query<Foo>(e => e.Entity.Name == name &&
e.Entity.Size > i);

Without the partial tree evaluation, you would not be able to express the right hand side of the equation.  All I had to do was implement an expression visitor that correctly evaluated the lambda expression and converted it to the LINQ syntax that SSDS expects (SsdsExpressionVisitor).  It would be a trivial matter to actually implement the IQueryProvider and IQueryable interfaces to make the whole thing work inside LINQ to Objects.

Originally, I did supply the IQueryProvider for this implementation but after consideration I have decided that using methods from the SsdsContainer class instead of the standard LINQ syntax is the best way to proceed.  Mainly, this has to do with the fact that I want to make it more explicit to the developer what will happen under the covers rather than using the standard Where() extension method.

Querying data

The main interaction to return data is via the Query<T> method.  This method is smart enough to add the Kind into the query for you based on the T supplied.  So, if you write something like:

var results = container.Query<Foo>(e => e.Entity.Size > 2);

This is actually translated to "from e in entities where e["Size"] > 2 && e.Kind == "Foo" select e".  The addition of the kind is important because we want to limit the results as much as possible.  If there happened to be many kinds in the container that had the flexible property "Size", it would actually return those as well in the wire response.

Of course, what about if you want that to happen?  What if you want to return other kinds that have the "Size" property?  To do this, I have introduced a class called SsdsEntityBucket.  It is exactly what it sounds like.  To use it, you simply specify a query that uses additional types with either the Query<T,U,V> or Query<T,U> methods.  Here is an example:

var foo = new Foo
{ IsPublic = true, MyCheese = new Cheese
{ LastModified = DateTime.Now, Name = "MyCheese" },
Name = "FooMaster", Size = 10 }; container.Insert(foo,
foo.Name); container.Insert(foo.MyCheese, foo.MyCheese.Name); //query
for bucket... var bucket = container.Query<Foo, Cheese>( (f, c) =>
f.Entity.Name == "FooMaster" || c.Entity.Name
== "MyCheese" ); var f1 = bucket.GetEntities<Foo>().Single();
var c1 = bucket.GetEntities<Cheese>().Single();

The calls to GetEntities<T> returns IEnumerable<SsdsEntity<T>> again.  However, this was done in a single call to SSDS instead of multiple calls per T.

Paging

As I mentioned earlier, I wanted the developer to understand what they were doing when they called each method, so I decided to make paging explicit.  If I had potentially millions of entities in SSDS, it would be a bad mistake to allow a developer to issue a simple query that seamlessly paged the items back - especially if the query was something like e => e.Id != "".  Here is how I handled paging:

var container = ctx.OpenContainer("paging");
List<Foo> items = new List<Foo>(); int i
= 1; container.PagedQuery<Foo>( e => e.Entity.Size != 0, c => { Console.WriteLine("Got
Page {0}", i++); items.AddRange(c.Select(s => s.Entity)); } ); Console.WriteLine(items.Count);

The PagedQuery<T> method takes two arguments.  One is the standard Expression<Func<SsdsEntity<T>, bool>> that you use to specify the WHERE clause for SSDS, and the other is Action<IEnumerable<SsdsEntity<T>>> which represents a delegate that takes an IEnumerable<SsdsEntity<T>> and has a void return.  This is a delegate you provide that does something with the 500 entities returned per page (it gets called once per page).  Here, I am just adding them into a List<T>, but I could easily be doing anything else here.  Under the covers, this is adding the paging term dynamically into the expression tree that is evaluated.

What's next

This is a good head start on using the REST API with SSDS today.  However, there are a number of optimizations that could be made to the model: additional overloads, perhaps some extension methods for common operations, etc.

As new features are added, I will endeavor to update this as well (blob support comes to mind here).  Additionally, I have a few optimizations planned around concurrency for CRUD operations. 

I have published this out to Code Gallery and I welcome feedback and bug fixes.  Linked here.

This is the second post in my series on working with SQL Server Data Service (SSDS) and objects.  For background, you should read my post on Serializing Objects in SSDS and the first post in this series.

Last time I showed how to create a general purpose serializer for SSDS using the standard XmlSerializer class in .NET.  I created a shell entity or a 'thin veneer' for objects called SsdsEntity<T>, where T was any POCO (plain old C#/CLR object).  This allowed me to abstract away the metadata properties required for SSDS without changing my actual POCO object (which, I noted was lame to do).

If we decide that we will use SSDS to interact with POCO T, an interesting situation arises.  Namely, once we have defined T, we have in fact defined a schema - albeit one only enforced in code you write and not by the SSDS service itself.  One of the advantages of using something like SSDS is that you have a lot of flexibility in storing entities  (hence the term 'flexible entity') without conforming to schema.  Since, I want to support this flexibility, it means I need to think of a way to support not only the schema implied by T, but also additional and arbitrary properties that a user might consider.

Some may wonder why we need this flexibility:  after all, why not just change T to support whatever we like?  The issue comes up most often with code you do not control.  If you already have an existing codebase with objects that you would like to store in SSDS, it might not be practical or even possible to change the T to add additional schema.

Even if you completely control the codebase, expressing relationships between CLR objects and expressing relationships between things in your data are two different ideas - sometimes this problem has been termed 'impedance mismatch'.

In the CLR, if two objects are related, they are often part of a collection, or they refer to an instance on another object.  This is easy to express in the CLR (e.g. Instance.ChildrenCollection["key"]).  In your typical datasource, this same relationship is done using foreign keys to refer to other entities.

Consider the following classes:

            public
            class Employee
{ publicstring EmployeeId
{ get; set; } publicstring Name
{ get; set; } public DateTime HireDate { get;
set; } public Employee Manager { get; set; } public Project[]
Projects { get; set; } } publicclass Project
{ publicstring ProjectId
{ get; set; } publicstring Name
{ get; set; } publicstring BillCode
{ get; set; } }

Here we see that the Employee class refers to itself as well as contains a collection of related projects (Project class) that the employee works on.  SSDS only supports simple scalar types and no arrays or nested objects today, so we cannot directly express this in SSDS.  However, we can decompose this class and store the bits separately and then reassemble later.  First, let's see what that looks like and then we can see how it was done:

var projects = new Project[]
{ new Project { BillCode = "123",
Name = "TPS Slave", ProjectId = "PID01"}, new Project
{ BillCode = "124", Name = "Programmer",
ProjectId = "PID02" } }; var bill = new Employee
{ EmployeeId = "EMP01", HireDate = DateTime.Now.AddMonths(-1),
Manager = null, Name = "Bill
Lumbergh", Projects = new Project[] {}
}; var peter = new Employee { EmployeeId = "EMP02",
HireDate = DateTime.Now, Manager = bill, Name = "Peter
Gibbons", Projects = projects }; var cloudpeter = new SsdsEntity<Employee>
{ Entity = peter, Id = peter.EmployeeId }; var cloudbill = new SsdsEntity<Employee>
{ Entity = bill, Id = bill.EmployeeId }; //here is how
we add flexible props cloudpeter.Add<string>("ManagerId",
peter.Manager.EmployeeId); var table = _context.OpenContainer("initech");
table.Insert(cloudpeter); table.Insert(cloudbill); var cloudprojects = peter.Projects
.Select(s => new SsdsEntity<Project>
{ Entity = s, Id = Guid.NewGuid().ToString() }); //add
some metadata to track the project to employeeforeach (var
proj in cloudprojects) { proj.Add<string>("RelatedEmployee",
peter.EmployeeId); table.Insert(proj); }

All this code does is create two employees and two projects and set the relationships between them.  Using the Add<K> method, I can insert any primitive type to go along for the ride with the POCO.  If we query the container now, this is what we see:

            <
            s:EntitySet
            xmlns:s
            ="http://schemas.microsoft.com/sitka/2008/03/"
            xmlns:xsi
            ="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:x
            ="http://www.w3.org/2001/XMLSchema"
            >
            <
            Project
            >
            <
            s:Id
            >2ffd7a92-2a3b-4cd8-a5f7-55f40c3ba2b0</s:Id><s:Version>1</s:Version><ProjectIdxsi:type="x:string">PID01</ProjectId><Namexsi:type="x:string">TPS
Slave</Name><BillCodexsi:type="x:string">123</BillCode><RelatedEmployeexsi:type="x:string">EMP02</RelatedEmployee></Project><Project><s:Id>892dbb1e-ba47-4c87-80e6-64fbb46da935</s:Id><s:Version>1</s:Version><ProjectIdxsi:type="x:string">PID02</ProjectId><Namexsi:type="x:string">Programmer</Name><BillCodexsi:type="x:string">124</BillCode><RelatedEmployeexsi:type="x:string">EMP02</RelatedEmployee></Project><Employee><s:Id>EMP01</s:Id><s:Version>1</s:Version><EmployeeIdxsi:type="x:string">EMP01</EmployeeId><Namexsi:type="x:string">Bill
Lumbergh</Name><HireDatexsi:type="x:dateTime">2008-05-25T23:59:49</HireDate></Employee><Employee><s:Id>EMP02</s:Id><s:Version>1</s:Version><EmployeeIdxsi:type="x:string">EMP02</EmployeeId><Namexsi:type="x:string">Peter
Gibbons</Name><HireDatexsi:type="x:dateTime">2008-06-25T23:59:49</HireDate><ManagerIdxsi:type="x:string">EMP01</ManagerId></Employee></s:EntitySet>

As you can see, I have stored extra data in my 'flexible' entity with the ManagerId property (on one entity) and RelatedEmployee property on the Project kinds.  This allows me to figure out later what objects are related to each other since we can't model the CLR objects relationships directly.  Let's see how this was done.

            public
            class SsdsEntity<T> where T: class {
Dictionary<string, object>
_propertyBucket = new Dictionary<string, object>(); public SsdsEntity()
{ } [XmlIgnore] public Dictionary<string, object>
PropertyBucket { get { return _propertyBucket;
} } [XmlAnyElement] public XElement[] Attributes
{ get { //using XElement is much easier than XmlElement
to build//take all properties on object instance
and build XElement var props = from prop intypeof(T).GetProperties()
let val = prop.GetValue(this.Entity, null) where prop.GetSetMethod()
!= null && allowableTypes.Contains(prop.PropertyType)
&& val != null select new XElement(prop.Name, new XAttribute(Constants.xsi
+ "type", XsdTypeResolver.Solve(prop.PropertyType)),
EncodeValue(val) ); //Then stuff in any extra stuff you
want var extra = _propertyBucket.Select( e => new XElement(e.Key, new XAttribute(Constants.xsi
+ "type", XsdTypeResolver.Solve(e.Value.GetType())),
EncodeValue(e.Value) ) ); return props.Union(extra).ToArray();
} set { //wrap the XElement[] with the name of the type var
xml = new XElement(typeof(T).Name, value);
var xs = new XmlSerializer(typeof(T)); //xml.CreateReader()
cannot be used as it won't support base64 content XmlTextReader reader = new XmlTextReader(
xml.ToString(), XmlNodeType.Document, null ); this.Entity
= (T)xs.Deserialize(reader); //now deserialize the other
stuff left over into the property bucket... var stuff = from v invalue.AsEnumerable()
let props = typeof(T).GetProperties().Select(s
=> s.Name) where !props.Contains(v.Name.ToString())
select v; foreach (var item in stuff)
{ _propertyBucket.Add( item.Name.ToString(), DecodeValue( item.Attribute(Constants.xsi
+ "type").Value, item.Value) ); } } } publicvoid Add<K>(string key,
K value) { if (!allowableTypes.Contains(typeof(K))) thrownew ArgumentException(
String.Format( "Type {0} not supported in SsdsEntity", typeof(K).Name)
); if (!_propertyBucket.ContainsKey(key)) { _propertyBucket.Add(key, value);
} else { //replace
the value _propertyBucket.Remove(key); _propertyBucket.Add(key, value);
} } }

I have omitted the parts of SsdsEntity<T> from the first post that didn't change.  The only other addition you don't see here is a helper method called DecodeValue, which as you might guess, interprets the string value in XML and attempts to cast it to a CLR type based on the xsi:type that comes back.

All we did here was add a Dictionary<string, object> property called PropertyBucket that holds our extra stuff we want to associate with our T instance.  Then in the getter and setter for the XElement[] property called Attributes, we are adding them into our array of XElement as well as pulling them back out on deserialization and stuffing them back into the Dictionary.  With this simple addition, we have fixed our in flexibility (or lack thereof) problem.  We are still limited to the simple scalar types, but as you can see you can work around this in a lot of cases by decomposing the objects down enough to be able to recreate them later.

The Add<K> method is a convenience only as we could operate directly against the Dictionary.  I also could have chosen to keep the Dictionary property bucket private and not expose it.  That would have worked just fine for serialization, but I wanted to also be able to query it later.

In my last post, I said I would introduce a library where all this code is coming from, but I didn't realize at the time how long this post would be and that I still need to cover querying.  So... next time, I will finish up this series by explaining how the strongly typed query model works and how all these pieces fit together to recompose the data back into objects (and release the library).

Last time we talked about SQL Server Data Services and serializing objects, we discussed how easy it was to use the XmlSerializer to deserialize objects using the REST interface.  The problem was that when we serialized objects using the XmlSerializer, it left out the xsi type declarations that we needed.  I gave two possible solutions to this problem - one that used the XmlSerializer and 'fixed' the output after the fact, and the other built the XML that we needed using XLINQ and Reflection.

Today, I am going to talk about a third technique that I have been using lately that I like better.  It uses some of the previous techniques and leverages a few tricks with XmlSerializer to get what I want.  First, let's start with a POCO (plain ol' C# object) class that we would like to use with SSDS.

            public
            class Foo
{ publicstring Name
{ get; set; } publicint Size
{ get; set; } publicbool IsPublic
{ get; set; } }

In it's correctly serialized form, it looks like this on the wire:

            <
            Foo
            xmlns:s
            ="http://schemas.microsoft.com/sitka/2008/03/"
            xmlns:xsi
            ="http://www.w3.org/2001/XMLSchema-instance"
            xmlns:x
            ="http://www.w3.org/2001/XMLSchema"
            >
            <
            s:Id
            >someid</s:Id><s:Version>1</s:Version><Namexsi:type="x:string">My
Foo</Name><Sizexsi:type="x:decimal">10</Size><IsPublicxsi:type="x:boolean">false</IsPublic></Foo>

You'll notice that we have the additional system metadata attributes "Id" and "Version" in the markup.  We can account for the metadata attributes by doing something cheesy like deriving from a base class:

            public
            abstract
            class Cheese
{ publicstring Id
{ get; set; } publicint Version
{ get; set; } }

However this is very unnatural as our classes would all have to derive from our "Cheese" abstract base class (ABC).

            public
            class Foo
: Cheese { publicstring Name
{ get; set; } publicint Size
{ get; set; } publicbool IsPublic
{ get; set; } }

Developers familiar with remoting in .NET should be cringing right now as they remember the hassles associated with deriving from MarshalByRefObject.  In a world without multiple inheritance, this can be painful.  I want a model where I can use arbitrary POCO objects (redundant, yes I know) and not be forced to derive from anything or do what I would otherwise term unnatural acts.

What if instead, we derived a generic entity that could contain any other entity?

            public
            class SsdsEntity<T> where T: class { string _kind; public SsdsEntity()
{ } [XmlElement(Namespace = @"http://schemas.microsoft.com/sitka/2008/03/")] publicstring Id
{ get; set; } [XmlIgnore] publicstring Kind
{ get { if (String.IsNullOrEmpty(_kind)) { _kind
= typeof(T).Name; } return _kind;
} set { _kind = value; } } [XmlElement(Namespace
= @"http://schemas.microsoft.com/sitka/2008/03/")] publicint Version
{ get; set; } [XmlIgnore] public T Entity { get;
set; } }

In this case, we have simply wrapped the POCO that we care about in a class that knows about the specifics of the SSDS wire format (or more accurately could serialize down to the wire format).

This SsdsEntity<T> is easy to use and provides access to the strongly typed object via the Entity property.

Now, we just have to figure out how to serialize the SsdsEntity<Foo> object and we know that the metadata attributes are taken care of and our original POCO object that we care about is included.  I call it wrapping POCOs in a thin SSDS veneer.

The trick to this is to add a bucket of XElement objects on the SsdsEntity<T> class that will hold our public properties on our class T (i.e. 'Foo' class).  It looks something like this:

[XmlAnyElement]
public XElement[]
Attributes { get { //using XElement is much easier than
XmlElement to build//take all properties on object
instance and build XElement var props = from prop intypeof(T).GetProperties()
let val = prop.GetValue(this.Entity, null) where prop.GetSetMethod()
!= null && allowableTypes.Contains(prop.PropertyType)
&& val != null select new XElement(prop.Name, new XAttribute(Constants.xsi
+ "type", XsdTypeResolver.Solve(prop.PropertyType)),
EncodeValue(val) ); return props.ToArray(); }
set { //wrap the XElement[] with the name of the type var
xml = new XElement(typeof(T).Name, value);
var xs = new XmlSerializer(typeof(T)); //xml.CreateReader()
cannot be used as it won't support base64 content XmlTextReader reader = new XmlTextReader(
xml.ToString(), XmlNodeType.Document, null); this.Entity
= (T)xs.Deserialize(reader); } }

In the getter, we use Reflection and pull back a list of all the public properties on the T object and build an array of XElement.  This is the same technique I used in my first post on serialization.  The 'allowableTypes' object is a HashSet<Type> that we use to figure out which property types we can support in the service (DateTime, numeric, string, boolean, and byte[]).  When this property serializes, the XElements are simply added to the markup.

The EncodeValue method shown is a simple helper method that correctly encodes string values, boolean, dates, integers, and byte[] values for the attribute.  Finally, we are using a helper method that returns from a Dictionary<Type,string> the correct xsi type for the required attribute (as determined from the property type).

For deserialization, what happens is that the [XmlAnyElement] attribute causes all unmapped attributes (in this case, all non-system metadata attributes) to be collected in a collection of XElement.  When we deserialize, if we simply wrap an enclosing element around this XElement collection, it is exactly what we need for deserialization of T.  This is shown in the setter implementation.

It might look a little complicated, but now simple serialization will just work via the XmlSerializer.  Here is one such implementation:

            public
            string Serialize(SsdsEntity<T>
entity) { //add a bunch of namespaces and override the
default ones too XmlSerializerNamespaces namespaces = new XmlSerializerNamespaces();
namespaces.Add("s", Constants.ns.NamespaceName);
namespaces.Add("x", Constants.x.NamespaceName);
namespaces.Add("xsi", Constants.xsi.NamespaceName);
var xs = new XmlSerializer( entity.GetType(), new XmlRootAttribute(typeof(T).Name)
); XmlWriterSettings xws = new XmlWriterSettings();
xws.Indent = true; xws.OmitXmlDeclaration = true; using (var
ms = new MemoryStream()) { using (XmlWriter
writer = XmlWriter.Create(ms, xws)) { xs.Serialize(writer, entity, namespaces); ms.Position
= 0; //reset to beginningusing (var
sr = new StreamReader(ms)) { return sr.ReadToEnd();
} } } }

Deserialization is even easier since we are starting with the XML representation and don't have to build a Stream in memory.

            public SsdsEntity<T>
Deserialize(XElement node) { var xs = new XmlSerializer( typeof(SsdsEntity<T>), new XmlRootAttribute(typeof(T).Name)
); //xml.CreateReader() cannot be used as it won't support
base64 content XmlTextReader reader = new XmlTextReader(
node.ToString(), XmlNodeType.Document, null); return (SsdsEntity<T>)xs.Deserialize(reader);
}

If you notice, I am using an XmlTextReader to pass to the XmlSerializer.  Unfortunately, the XmlReader from XLINQ does not support handling of base64 content, so this workaround is necessary.

At this point, we have a working serializer/deserializer that can handle arbitrary POCOs.  There are some limitations of course:

• We are limited to the same datatypes that SSDS supports.  This also means nested objects and arrays are not directly supported.
• We have lost a little of the 'flexible' in the Flexible Entity (the E in the ACE model).  We now have a rigid schema defined by SSDS metadata and T public properties and enforced on our objects.

In my next post, I will attempt to address some of those limitations and I will introduce a library that handles most of this for you.

I officially love LINQPad.  Joe Albahari has done a great job of introducing a light weight tool that is great for learning and prototyping LINQ queries.  From what I gather, Joe and Ben Albahari built this tool as part of their book offering.  It was so useful, it has taken on a life of its own.

It may not be entirely obvious, but it turns out don't have to use LINQPad solely for LINQ queries.  You can actually prototype any type of snippet of code.  I have been using it now instead of SnippetCompiler (another great quick snippet tool).

As an example, here is how to use System.DirectoryServices snippets inside of LINQPad:

Hit F4 to bring up the Advanced Query Properties Window

Add the System.DirectoryServices.dll reference in the Additional References window, and then add "System.DirectoryServices" in the Additional Namespace Imports window.

Now, just type your code normally and hit F5 when you are done:

This is a great little tool to have as you can query databases, build LINQ expressions, and visually inspect the results that come back pretty easily.  Now, as you can see you can also execute arbitrary code snippets as well.  Highly recommended.

A member in the book's forum mentioned some code I had originally posted here in the blog for asynchronous, paged searches in System.DirectoryServices.Protocols (SDS.P).  He questioned whether or not it was thread safe.  I honestly don't know - it might not be as I didn't test it extensively.

Regardless, I had actually moved on from that code and started using anonymous delegates for callbacks instead of events.  I liked this pattern a bit better because it also got rid of the shared resources.

After reading Stephen Toub's article on asynchronous stream processing, I learned about the AsyncOperationManager which was something I was missing in my implementation.  I have been doing a lot lately with .NET 3.5, LINQ, and lambda expressions, so I also decided to rewrite the anonymous delegates to lambda expressions.  That is not as big a change, but it is more concise.

I actively investigated using async iterators, but ultimately I decided closures seemed to be more intuitive for me.  I might revisit this at some time and change my mind.  Here is my outcome:

            public
            class AsyncSearcher
{ LdapConnection _connect; public AsyncSearcher(LdapConnection
connection) { this._connect = connection; this._connect.AutoBind
= true; //will bind
on first search } publicvoid BeginPagedSearch( string baseDN, string filter, string[]
attribs, int pageSize, Action<SearchResponse>
page, Action<Exception> completed ) { if (page
== null) thrownew ArgumentNullException("page");
AsyncOperation asyncOp = AsyncOperationManager.CreateOperation(null);
Action<Exception> done = e => { if (completed
!= null) asyncOp.Post(delegate {
completed(e); }, null); }; SearchRequest request
= new SearchRequest( baseDN, filter, System.DirectoryServices.Protocols.SearchScope.Subtree,
attribs ); PageResultRequestControl prc = new PageResultRequestControl(pageSize); //add
the paging control request.Controls.Add(prc); AsyncCallback rc = null;
rc = readResult => { try { var response = (SearchResponse)_connect.EndSendRequest(readResult); //let
current thread handle results asyncOp.Post(delegate {
page(response); }, null); var cookie = response.Controls
.Where(c => c is PageResultResponseControl)
.Select(s => ((PageResultResponseControl)s).Cookie) .Single(); if (cookie
!= null && cookie.Length != 0) { prc.Cookie
= cookie; _connect.BeginSendRequest( request, PartialResultProcessing.NoPartialResultSupport,
rc, null ); } else done(null); //signal
complete } catch (Exception ex) { done(ex);
} }; //kick off asynctry {
_connect.BeginSendRequest( request, PartialResultProcessing.NoPartialResultSupport,
rc, null ); } catch (Exception
ex) { done(ex); } } }

It can be consumed very easily using something like this:

            class Program
{ static ManualResetEvent _resetEvent = new ManualResetEvent(false); staticvoid Main(string[]
args) { //set these to your environmentstring servername
= "server.yourdomain.com"; string baseDN
= "dc=yourdomain,dc=com"; using (LdapConnection
connection = CreateConnection(servername)) { AsyncSearcher searcher = new AsyncSearcher(connection);
searcher.BeginPagedSearch( baseDN, "(sn=Dunn)", null,
100, f => //runs per page { foreach (var
item in f.Entries) { var entry = item as SearchResultEntry; if (entry
!= null) { Console.WriteLine(entry.DistinguishedName);
} } }, c => //runs on error or when done { if (c
!= null) Console.WriteLine(c.ToString()); Console.WriteLine("Done");
_resetEvent.Set(); } ); _resetEvent.WaitOne(); } Console.WriteLine(); Console.WriteLine("Finished....
Press Enter to Continue."); Console.ReadLine(); } static LdapConnection
CreateConnection(string server) { LdapConnection
connect = new LdapConnection( new LdapDirectoryIdentifier(server), null,
AuthType.Negotiate ); connect.SessionOptions.ProtocolVersion = 3; connect.SessionOptions.ReferralChasing
= ReferralChasingOptions.None; connect.SessionOptions.Sealing = true;
connect.SessionOptions.Signing = true; return connect;
} } 

The important thing to note is that because everything is running asynchronously, it is totally possible for the end delegate to be invoked before the paging delegate has a chance to finish processing results (depending on how complicated your code is).  You would need to compensate for this yourself.

This client is a console application, so I am using a ManualResetEvent just to prevent it from closing before finishing.  You wouldn't need to do this in a WinForms or WPF app.

I am sure there are other optimizations you could make to pass in parameters or even other directory controls.  However, the general pattern should apply.

I just posted the first version of PhluffyFotos, our SQL Server Data Services (SSDS) sample app to CodePlex.  PhluffyFotos is a photo sharing site that allows users to upload photos and metadata (tags, description) to SSDS for storage.  As the service gets more features and is updated, the sample will be rev'd as well.

Points of interest that will likely also be blog posts in themselves:

• This sample has a LINQ-to-SSDS provider in it.  You will notice we don't use any strings for queries, but rather lambda expressions.  I had a lot of fun writing the first version of this and I would expect that there are a few more revisions here to go.  Of course, Matt Warren should get a ton of credit here for providing the base implementation.
• This sample also uses a very simplistic ASP.NET Role provider for SSDS.  Likely updates here will include encryption and hashing support.
• We have a number of Powershell cmdlets included for managing authorities and containers.

I have many other ideas for this app as time progresses, so you should check back from time to time to see the updates.

In case anyone was wondering about the name: clouds are fluffy... get it?

You need to have SSDS credentials to run this sample.  If you don't have credentials yet, you can see an online version until then at http://www.phluffyfotos.com

Even if you don' t have access to SSDS credentials yet, the code is worth taking a look.

If you are interested in learning more about Visual Studio 2008, make sure you check out the Visual Studio 2008 Training Kit.  Weighing in at roughly 120MB compressed, it contains, "a full 5-days of technical content including 20 hands-on labs, 28 presentations, and 20 scripted demos.   The technologies covered in the kit include:  LINQ, C# 3.0, VB 9, WCF, WF, WPF, Windows CardSpace, Silverlight, ASP.NET Ajax, .NET Compact Framework 3.5, VSTO 3.0, Visual Studio Team System, and Team Foundation Server".

Naturally, you will want to have a machine setup to run all these labs and samples... so, thanks to the hard work of David and James, you can now download a VPC with Vista, Visual Studio 2008 (trial), and the .NET 3.5 framework pre-loaded and ready to run.  Get it here.

You want more?  Ok, how about 17 training videos describing the technologies and running through a number of demos?  Get those here.

These are truly some great resources to get you jumpstarted!

There are three ways of figuring out things that have changed in Active Directory (or ADAM).  These have been documented for some time over at MSDN in the aptly titled "Overview of Change Tracking Techniques".  In summary:

1. Polling for Changes using uSNChanged. This technique checks the 'highestCommittedUSN' value to start and then performs searches for 'uSNChanged' values that are higher subsequently.  The 'uSNChanged' attribute is not replicated between domain controllers, so you must go back to the same domain controller each time for consistency.  Essentially, you perform a search looking for the highest 'uSNChanged' value + 1 and then read in the results tracking them in any way you wish.
   • Benefits
     • This is the most compatible way.  All languages and all versions of .NET support this way since it is a simple search.
   • Disadvantages
     • There is a lot here for the developer to take care of.  You get the entire object back, and you must determine what has changed on the object (and if you care about that change).
     • Dealing with deleted objects is a pain.
     • This is a polling technique, so it is only as real-time as how often you query.  This can be a good thing depending on the application. Note, intermediate values are not tracked here either.
2. Polling for Changes Using the DirSync Control.  This technique uses the ADS_SEARCHPREF_DIRSYNC option in ADSI and the LDAP_SERVER_DIRSYNC_OID control under the covers.  Simply make an initial search, store the cookie, and then later search again and send the cookie.  It will return only the objects that have changed.
   • Benefits
     • This is an easy model to follow.  Both System.DirectoryServices and System.DirectoryServices.Protocols support this option.
     • Filtering can reduce what you need to bother with.  As an example, if my initial search is for all users "(objectClass=user)", I can subsequently filter on polling with "(sn=dunn)" and only get back the combination of both filters, instead of having to deal with everything from the intial filter.
     • Windows 2003+ option removes the administrative limitation for using this option (object security).
     • Windows 2003+ option will also give you the ability to return only the incremental values that have changed in large multi-valued attributes.  This is a really nice feature.
     • Deals well with deleted objects.
   • Disadvantages
     • This is .NET 2.0+ or later only option.  Users of .NET 1.1 will need to use uSNChanged Tracking.  Scripting languages cannot use this method.
     • You can only scope the search to a partition.  If you want to track only a particular OU or object, you must sort out those results yourself later.
     • Using this with non-Windows 2003 mode domains comes with the restriction that you must have replication get changes permissions (default only admin) to use.
     • This is a polling technique.  It does not track intermediate values either.  So, if an object you want to track changes between the searches multiple times, you will only get the last change.  This can be an advantage depending on the application.
3. Change Notifications in Active Directory.  This technique registers a search on a separate thread that will receive notifications when any object changes that matches the filter.  You can register up to 5 notifications per async connection.
   • Benefits
     • Instant notification.  The other techniques require polling.
     • Because this is a notification, you will get all changes, even the intermediate ones that would have been lost in the other two techniques.
   • Disadvantages
     • Relatively resource intensive.  You don't want to do a whole ton of these as it could cause scalability issues with your controller.
     • This only tells you if the object has changed, but it does not tell you what the change was.  You need to figure out if the attribute you care about has changed or not.  That being said, it is pretty easy to tell if the object has been deleted (easier than uSNChanged polling at least).
     • You can only do this in unmanaged code or with System.DirectoryServices.Protocols.

For the most part, I have found that DirSync has fit the bill for me in virtually every situation.  I never bothered to try any of the other techniques.  However, a reader asked if there was a way to do the change notifications in .NET.  I figured it was possible using SDS.P, but had never tried it.  Turns out, it is possible and actually not too hard to do.

My first thought on writing this was to use the sample code found on MSDN (and referenced from option #3) and simply convert this to System.DirectoryServices.Protocols.  This turned out to be a dead end.  The way you do it in SDS.P and the way the sample code works are different enough that it is of no help.  Here is the solution I came up with:

              public
              class ChangeNotifier
: IDisposable

{

    LdapConnection _connection;

    HashSet<IAsyncResult> _results = new HashSet<IAsyncResult>();

              public ChangeNotifier(LdapConnection
connection)

    {

        _connection = connection;

        _connection.AutoBind = true;

    }

              public
              void Register(string dn,
SearchScope scope)

    {

        SearchRequest request = new SearchRequest(

            dn, //root
the search here

              "(objectClass=*)", //very
inclusive

            scope, //any
scope works

              null
              //we
are interested in all attributes
            

            );

              //register
our search
            

        request.Controls.Add(new DirectoryNotificationControl());

              //we
will send this async and register our callback
            

              //note
how we would like to have partial results
            

        IAsyncResult result = _connection.BeginSendRequest(

            request,

            TimeSpan.FromDays(1), //set
timeout to a day...

            PartialResultProcessing.ReturnPartialResultsAndNotifyCallback,

            Notify,

            request

            );

              //store
the hash for disposal later
            

        _results.Add(result);

    }

              private
              void Notify(IAsyncResult
result)

    {

              //since
our search is long running, we don't want to use EndSendRequest
            

        PartialResultsCollection prc = _connection.GetPartialResults(result);

              foreach (SearchResultEntry
entry in prc)

        {

            OnObjectChanged(new ObjectChangedEventArgs(entry));

        }

    }

              private
              void OnObjectChanged(ObjectChangedEventArgs
args)

    {

              if (ObjectChanged
!= null)

        {

            ObjectChanged(this,
args);

        }

    }

              public
              event EventHandler<ObjectChangedEventArgs>
ObjectChanged;

              #region IDisposable
Members

              public
              void Dispose()

    {

              foreach (var
result in _results)

        {

              //end
each async search
            

            _connection.Abort(result);

        }

    }

              #endregion
            

}

              public
              class ObjectChangedEventArgs
: EventArgs

{

              public ObjectChangedEventArgs(SearchResultEntry
entry)

    {

        Result = entry;

    }

              public SearchResultEntry
Result { get; set;}

}

It is a relatively simple class that you can use to register searches.  The trick is using the GetPartialResults method in the callback method to get only the change that has just occurred.  I have also included the very simplified EventArgs class I am using to pass results back.  Note, I am not doing anything about threading here and I don't have any error handling (this is just a sample).  You can consume this class like so:

              static
              void Main(string[]
args)

{

              using (LdapConnection
connect = CreateConnection("localhost"))

    {

              using (ChangeNotifier
notifier = new ChangeNotifier(connect))

        {

              //register
some objects for notifications (limit 5)
            

            notifier.Register("dc=dunnry,dc=net",
SearchScope.OneLevel);

            notifier.Register("cn=testuser1,ou=users,dc=dunnry,dc=net",
SearchScope.Base);

            notifier.ObjectChanged += new EventHandler<ObjectChangedEventArgs>(notifier_ObjectChanged);

            Console.WriteLine("Waiting
for changes...");

            Console.WriteLine();

            Console.ReadLine();

        }

    }

}

              static
              void notifier_ObjectChanged(object sender,
ObjectChangedEventArgs e)

{

    Console.WriteLine(e.Result.DistinguishedName);

              foreach (string attrib in e.Result.Attributes.AttributeNames)

    {

              foreach (var
item in e.Result.Attributes[attrib].GetValues(typeof(string)))

        {

            Console.WriteLine("\t{0}:
{1}", attrib, item);

        }

    }

    Console.WriteLine();

    Console.WriteLine("====================");

    Console.WriteLine();

}

And there you have it... change notifications in .NET.  You can also download my project file for Visual Studio 2008.

A question came up the other day on how to get LINQ to SQL to participate in using the SQL Notification Services.  Of course, I didn't know, but Mike Pizzo from the ADO.NET team was kind enough to answer.  I figured it must be possible, and sure enough, it is.  Essentially, you have to create a SQL dependency context, which is very similar to a transaction context.  Any code that participates within that context will automatically be associated with the SQLDependency.  Create the dependency first, before any LINQ (or other data access technology).  Here is the relevant code (note: this code is not optimized, so you might want to do things like change the SQLDependency to static or pass it in so it won't be garbage collected).

There is also one major caveat to using this with LINQ: Beware of complex queries that can be easily generated using LINQ.  The Query Processor will invalidate the command and fire an error event saying it was too complex.  Since you can easily generate lots of complex queries using LINQ (part of its power really), you need to really be cognizant of this limitation.

Link pair attributes in Active Directory and ADAM can be quite big.  I don't know the official limit, but needless to say, for practical purposes you can assume they are quite large indeed.  By default, AD and ADAM will not return the entire attribute if it contains more than a certain number of values (1000 for Windows 2000 and 1500 for Windows 2003+ by default).  As such, if you truly want robust code, you need to always use what is called range retrieval for link value paired attributes.

Range retrieval is a process similar to paging in directory services, whereby you ask the directory for a certain range of particular attribute.  You know that you are using range retrieval when you see the attribute being requested in the following format:

"[attribute];range=[start]-[end]"

As an example, in the case of the 'member' attribute, you might ask for the first 1500 values like so:

"member;range=0-1499"

Notice, it is zero based so you need to take this into account.  The general algorithm as such is:

1. Ask for as big as you can get.  This means use the "*" for the ending range to ask for it all.
2. The directory will respond with either the actual max value (some integer), or with a "*" indicating you got everything.  If you got everything, you are done.
3. If not, using the max value now as your step, repeatedly ask for larger and larger values inside a loop until the directory responds with a "*" as the end range.

We covered how to use range retrieval in SDS in our book, and you can download sample code that shows how from the book's website.  What we didn't cover was how to do it in SDS.P.

SDS.P is a layer closer the the metal than our ADSI based System.DirectoryServices (SDS).  As such, if you are expected to do range retrieval for SDS, you can be assured that you need to do it for SDS.P as well.  Adopting the code SDS, you get something like this (but modified to some extent):

Happy coding... of course, if you are clever you will realize you can avoid all this range retrieval mess by using an attribute scope query (ASQ). :)

*edit: tried to fix the style for code to render in Google Reader correctly

I have previously covered pretty extensively the options for getting a user's group membership in Active Directory or ADAM (soon to be Active Directory LDS (Lightweight Directory Services)) here on the blog, in the forum, and in the book.  However, there is a new option for users of .NET 3.5 that should be of interest.

The Directory Services group at Microsoft has released in beta form a new API for dealing with a lot of the common things we need to do with users, groups, and computers in Active Directory, ADAM, and the local machine.  This API is called System.DirectoryServices.AccountManagement (or SDS.AM).  Here is a simple example of how to get a users groups (including nested, and primary):

          static
          void Main(string[]
args) { PrincipalContext ctx = newPrincipalContext(ContextType.Domain); using (ctx)
{ Principal p = Principal.FindByIdentity(ctx, "ryandunn"); using (p)
{ var groups = p.GetGroups(); using (groups)
{ foreach (Principal group in groups)
{ Console.WriteLine(group.SamAccountName
+ "-" + group.DisplayName); } } } } Console.ReadLine();
}

That's not too bad - in fact, it looks worse than it is because I am trying to make sure everything is wrapped in a 'using' statement where necessary.  The equivalent code to do this would be many times more (using DsCrackNames or LDAP searches) and would yield far less information being returned (just the DN in most cases).

Over the next few weeks and months, I intend to dig more deeply into this namespace and put some samples up here for everyone.  This is just a taste for now, but it should show you how powerful this namespace really is.

 *Updated to fix CSS renderings in Google Reader

One of the major changes introduced with IIS7 is the removal of the metabase.  This probably comes as a great relief to many of the admins and developers that struggled with coordinating configuration across multiple machines.  Instead of the metabase, IIS7 has chosen to schematize all the web server settings and host them centrally in a new XML file called applicationHost.config located at '%windir%\system32\inetsrv\config'.

The schema itself can be found in the 'schema' folder right below the 'config' directory.  This new centralized configuration file holds all the global default values for IIS7 as well as defines what sites, applications, virtual directories, app pools, etc. are on the server.

Let's take a look just a couple items I found in my applicationHost.config:

          <
          applicationPools
          >
<
          add
          
          
          name
          ="DefaultAppPool" />
<addname="Classic
.NET AppPool"managedPipelineMode="Classic" />
<applicationPoolDefaults>
<processModelidentityType="NetworkService" />
</applicationPoolDefaults>
</applicationPools>

Here is the configuration of the application pools on my IIS7 server.  Let's see what happens if we just edit this directly and add a new application pool.

If we open our new IIS Manager (Start > Run > inetmgr), we can see that this is all there is to it.

Further poking around will yield lists of sites, applications, and virtual directories as well - all described neatly in XML format.  Now, how did the IIS team put all this together?  Were they using their own black box implementation?  If we inspect the schema, we will find there is no magic here and the IIS team is leveraging its own schema system for IIS itself.  Opening the "IIS_Schema.xml" file found in the 'schema' directory shows us the exact settings available for 'applicationPools'.

           <
          sectionSchema
          
          
          name
          ="system.applicationHost/applicationPools">
<collectionaddElement="add"defaultElement="applicationPoolDefaults">
<attributename="name"type="string"required="true"isUniqueKey="true"validationType="applicationPoolName" />
<attributename="queueLength"type="uint"defaultValue="1000"validationType="integerRange"validationParameter="10,65535"/>
<attributename="autoStart"type="bool"defaultValue="true" />
<attributename="enable32BitAppOnWin64"type="bool"defaultValue="false" />
<attributename="managedRuntimeVersion"type="string"defaultValue="v2.0" />
<attributename="managedPipelineMode"type="enum"defaultValue="Integrated">
<enumname="Integrated"value="0" />
<enumname="Classic"value="1" />
</attribute>
<attributename="passAnonymousToken"type="bool"defaultValue="true" />
<elementname="processModel">
<attributename="identityType"type="enum"defaultValue="NetworkService">
<enumname="LocalSystem"value="0"/>
<enumname="LocalService"value="1"/>
<enumname="NetworkService"value="2"/>
<enumname="SpecificUser"value="3"/>
</attribute>  <...SNIP...>
</sectionSchema>

As we can see here, there are some basic typed attributes that describe our application pool.  They have things like types, default values, and even enumerations with possible values (managedPipelineMode is one such).  There really is no magic here.  Someone could very easily write a program that inspected the schema of IIS7 fully and presented all possible options just by inspecting this schema.

What should immediately come to mind as a developer is, "how can I leverage this system"?  If there is one word that describes IIS7, it is "Extensible".  In my next post, I will show you how to leverage this powerful schema system that IIS7 introduces for your own application purposes without code.

I was checking on the book's website the other day and noticed that we broke the 54,000 mark for downloads of our sample code.  That really surprised me.  I just didn't think that there were that many people in the world working on these types of scenarios.

 Now, I happen to know that we did not sell that many copies of the book, so this means a lot of people are downloading just the samples.  For the record, that is perfectly fine and we encourage people to look at the samples.  Admittedly, some of the samples might be head-scratchers without the book for context, but hey, its free and so is our time on the forums.

Joe and I log a lot of time here and in other forums helping people and we love to hear your feedback on what works and what doesn't.  Give us a shout when samples don't make sense, or when a scenario seems to be overly painful.  Some people have asked how they can repay us for our time (I have had offers for beer, wine, and lodging so far).  A simple thanks is enough for both of us, however, and a perhaps a recommendation to others.  If you really feel the need to contribute beyond nice words - simple, just buy the book!

I almost missed this one from Tomek, but he has a good analysis of what happens when you have many results to return from the directory and a nice comparison of how the different stacks (System.DirectoryServices vs. System.DirectoryServices.Protocols) handle it.  The moral of the story:  if you have a ton of results coming back, it might be in your interest to pursue using the Protocols stack.

Fellow MVP, Ethan Wilansky has a new article on MSDN outlining the System.DirectoryServices.Protocols stack.  I haven't had a chance to read every last word in it yet (it's a huge article!), but it appears to show roughly 80% of everything you might want to do with SDS.P.  Check it out.

Link to Introduction to System.DirectoryServices.Protocols (S.DS.P)

If hot-LDAP-filter-action is your thing, but you were let down in my last post since it required SP2 and Longhorn, then this should get you all hot and bothered again:  Hotfix for SP1.

I know, it's a hotfix - which means you have to contact Microsoft to get it.  But if you want to take advantage of the new LDAP_MATCHING_RULE_IN_CHAIN without upgrading to SP2 or Longhorn, then this is it.

Straight from Somasegar.  This is good news for developers trying to fit in with their visual counterparts.  Initially these were targeted at the professional designer instead of the developer.  I personally think that those two overlap quite a bit.  It was a good move to put this into developer's hands.  You can be sure that they will get used now...

Here is something that I am sure developers will run into as they start to create web sites on their local Vista boxes using IIS7.  I thought I would just put this out here to save people some time.  If you are like me, you will go to the 'Turn Windows features on or off' selection and simply check the IIS7 option like so:

If done correctly, this installs the ASP.NET environment and all the appropriate stuff.  If not, you get an interesting error when you browse to the first .aspx page on your site.  Specifically, you will get a nice 404.3 error similar to this:

The part that should tip you off that something is completely misconfigured  is the part of the the error message (which are sooo much nicer these days) where the module is being reported as the "StaticFileModule".  Static files are things like .html files, jpegs, etc. where we are not performing any server side logic.  We know that our .aspx files need to be processed by the .NET runtime, so we should see something else as the handler there.

Now, here comes the confusing part.  Bring up the IIS Manager (Windows Key > "Inetmgr"), and view the Handler Mappings for your site and you will see something similar to this:

Notice that all of the ASP.NET extensions are missing?  There are no handlers defined for the .aspx, .asmx, .ashx or any other .NET extensions.  If you bring up the handlers installed on the machine however, you will see that they are all just fine:

At this point, you may be like me and scratching your head asking, "why are my handlers not being inherited correctly"?  If you are like me, then you will probably try delete your web app and then re-add it back.  When that fails you will try to uninstall and reinstall IIS7 again.  When that doesn't work, you will try to reinstall ASP.NET manually from the command line using "aspnet_regiis -i" or something similar.  When that fails, you will spend hours on Google trying to see what other people have done.  It might also cross your mind to just add them manually to your configuration.  If you are like me, however, that seems dirty and you will keep trying.

To save you some time, it actually turns out it is pretty easy to fix.  Simply DELETE the "Default Web Site", and then ADD it back.  The Handlers will be re-applied correctly and your virtual directory or web site will have all the correct handlers installed.  It is confusing why this even happens with a fresh install, but it appears to be a frequent occurrence according to Google searches.  Coming from IIS 5.1 and 6, it might be counterintuitive to delete a site, but this is actually not a big deal in Vista since you can have as many of these as you like (no artificial limits anymore).  I hope this saves someone some time.

Note to the IIS7 team:  man, it would really be nice if you had a button that said something like "apply inherited handlers" or something like that.

I was speaking with Eric Fleischman at the MVP summit this year and he told me about a neat feature you will find in Window Server 2003 SP2 and Longhorn server.  It is a new type of matching rule ID filter that allows for transitive link value evaluation.  This is one filter type that is incredibly useful and you will want to know about.

First some background: a matching rule ID filter is a special syntax filter that allows for an arbitrary search behavior as defined by the matching rule.  Active Directory and ADAM only shipped with two matching rules until recently: LDAP_MATCHING_RULE_BIT_AND (1.2.840.113556.1.4.803) and LDAP_MATCHING_RULE_BIT_OR (1.2.840.113556.1.4.804).  We commonly used these matching rules to check our bitwise flag values.  For instance, here is the key portion of the filter that specifies an account is disabled:

(userAccountControl:1.2.840.113556.1.4.803:=2)

Notice that we have the attribute name we are searching on, the rule OID we want to use (the AND rule), and the value to check (in decimal).  Pretty simple, right?

The new matching rule is called LDAP_MATCHING_RULE_IN_CHAIN and it has an OID of 1.2.840.113556.1.4.1941.  This new rule allows us to search across all DN-syntax attributes recursively and evaluate the entire tree of relationships (hence the transitive name).

Evaluating Group Membership

Where we will typically see this used is in group membership evaluation.  Specifically, it answers two questions that are constantly asked by developers:  What groups are my user a member of? and What users are in this group?

It is really simple to use this filter, so here we go.  The first question is, what groups is my user a member of?

(member:1.2.840.113556.1.4.1941:=CN=User1,OU=X,DC=domain,DC=com)

The next question, what users are in this group?

(memberOf:1.2.840.113556.1.4.1941:=CN=A Group,OU=Y,DC=domain,DC=com)

If we place base this search on the main partition and use a subtree search, it will return for us all the matches across the domain.  However, if we scope the second search to a specific user object and use a base search, it is a quick and dirty way of telling us if the user is a member of the group.  Hence, this would also work for a type of IsInRole() function:

public bool IsUserMember(DirectoryEntry user, string groupDN)
{
    string filter = String.Format(
        "(memberOf:1.2.840.113556.1.4.1941:={0})", groupDN);

    DirectorySearcher ds = new DirectorySearcher(
        user,
        filter,
        null,
        SearchScope.Base);

    return (ds.FindOne() != null);
}

Now, I want to also point out that this sort of code also makes me cringe a little bit thinking about the abuse that can occur...  Remember, it is performing a search each and every time you want to check group membership.  It is still a better idea to build the entire group membership of a user and store it in one of the IPrincipal classes and use the .IsInRole() functionality to keep network access to a minimum.

Creating an Org Chart

The other area where we will find this filter being pretty handy is when we want to find all the users that directly and indirectly report to a single person.  This is the typical situation when building org charts or trying to find the users for a mailing list.  Here is one such example:

public static void GetOrgChart(DirectoryEntry entry, string bossDN)
{
    string filter = String.Format(
        "(&(mail=*)(manager:1.2.840.113556.1.4.1941:={0}))",
        bossDN);

    DirectorySearcher ds = new DirectorySearcher(
        entry,
        filter
        );

    using (SearchResultCollection src = ds.FindAll())
    {
        foreach (SearchResult sr in src)
        {
            Console.WriteLine(sr.Properties["mail"][0]);
        }
    }
}  

Performance

The next question we will want to answer for this new filter type is the performance relative to the code required to process this recursively.  I will use the code I presented here to test the recursive case and compare it to a simple filter of:

(memberOf:1.2.840.113556.1.4.1941:=CN=BigNestedGroup,OU=X,DC=Y)

So, to cut to the chase, how does the new filter compare to recursively chasing DN link pairs yourself?  Short answer... it doesn't.  The code I wrote for the book and here on the blog blows it away by a factor of 10.  I have to admit that before I ran the tests, I expected the new filter to run circles around my code and I was pretty shocked when the reverse was actually true.  I tested this using 3 nested groups each with 100 members and running both the recursive search and the transitive search 100 times and averaging the results.  To expand the lead group with 300 direct and indirect members took roughly half a second using a transitive filter (409ms) as compared to only (41ms) using the recursive search.  This would have a big impact on server apps serving many of these searches, but would probably not be a huge factor in client side apps or where a smallish number of these searches are performed.

Summary

The transitive filter is a great new addition and can greatly simplify the code that you have to write.  This new filter is not without pitfalls however.  Make sure you are cognizant of the performance tradeoffs that are inherent in choosing this filter as it is considerably slower to use. 

I have been playing with a new look for the site. I think this particular one is a bit cleaner looking than the previous one that shipped with DasBlog. I know that there are some bugs to be worked out, but I like it well enough that I think I will go ahead and put the site live with the new look and tweak stuff later (it is mostly the admin UI).

What do you think?

One of the neater abstractions we get using ASP.NET 2.0 is the ObjectDataSource. Essentially it allows us to specify our own objects or some arbitrary object graph as a datasource for databinding operations. Combined with the new GridView class it can be very powerful. Built in to both of these objects are methods for Selecting, Updating, Deleting, and Inserting. This allows you to plug-in your own code to manage each of these operations.

If we want to adapt this to support reading and updating (including adds and deletes) from AD or ADAM, we just need to put a few methods in place and hook them into the ObjectDataSource abstraction. The nice thing here is that it includes parameter support pretty easily. This allows us to add new values or update existing values. By specifying a data key (DataKeyNames) on the Gridview, it also allows us to uniquely index which object we are modifying.

I chose for this example to show a simple Select, Update, and Delete using a GridView and the ObjectDataSource. It only required me to configure 3 methods (one for each) and declaratively setup the parameters I would be using. I chose to use the 'objectGuid' for the key name since this is guaranteed to be unique and will always point me to the right object. However, I could also have used the DN as the key value in this case as well. If I had done that, it would have saved me a little bit of complication due to the need to rebind when using the GUID value for certain operations.

Keep in mind that this is just a simple sample of how this can be done and is not something that should be put into production as-is. The whole point of this is to show how the GridView gives us easy updating and reading of values, while the ObjectDataSource is used as our abstraction for operations on data. In the past, this would not have worked well because the DataGrid was so geared towards relational data like SQL. It would have been much more convoluted to get the same functionality. Being able to write only 3 methods and have working ASP.NET viewing and editing application is pretty neat.

You can download the sample here.

The task of figuring out your Active Directory NETBIOS domain name comes up now and again.  This is the process of turning something like "DC=yourdomain,DC=com" into something like "YOURDOMAIN".  This is important if you want to do things like prefix this name on the 'sAMAccountName' of a user for instance.  There are three ways of doing this (perhaps more).  I will cover each broadly.

Guess

Yes, that's right.  You can pretty much guess what it is by parsing the DN of the defaultNamingContext.  If you had something like "DC=yourdomain,DC=com", it seems a pretty good guess that the NETBIOS name is "YOURDOMAIN".  However, this method of course is not foolproof.  For whatever reason, your Active Directory admins might have decided to do something stupid - like say add a big dash (-) and some other random nonsense into the NETBIOS name.  Who knows why they do this, but hey, they can and do (I suspect they hate their users).  So, in this case, "DC=yourdomain,DC=com" might have a NETBIOS name of "YOURDOMAIN-CORP" for instance (it also means you have to type this every damn time you need to supply credentials as well in NT4 domain\user format).

DsCrackNames

You can simply use DsCrackNames to convert from DN format to NT4 format and it will work fine.  Pass the DN (e.g. "DC=yourdomain,DC=com") and you will get back the NETBIOS name.  This includes IADsNameTranslate if that is up your alley too.  Since there is no easy way to use either from .NET unless you build your own, this might not be your first choice.

LDAP Query

Finally, we get to the last method.  First, we connect to the RootDSE of the domain and inspect the following two properties:  "configurationNamingContext" and "defaultNamingContext".  Then we bind to the configuration partition (using the first of these properties) and perform the following search:  (&(objectCategory=crossRef)(nCName={0})) where {0} is the value you just got from the RootDSE for the 'defaultNamingContext'.  You should get one result.  Now, just read back the 'nETBIOSName' attribute and there you have it.

If you are shipping software that needs to do this, obviously you should use one of the last two methods.  Guessing probably will just not cut it for anything that is just not quick and dirty.

One of my co-workers forwarded this link to me today.  Essentially, it is XSDObjectGen for 2.0 with support for things like partial classes, generics, etc.  We tend to use this as a basis for our service contracts and to help serialize outward facing DTO objects.  I was looking for something similar (or the source to XSDObjectGen to do it myself) a few months back.  Very cool.

Get it here:

http://devauthority.com/blogs/ram_marappan/archive/2006/10/03/4755.aspx

A common task that any Active Directory developer will face is to expand group membership for a given group.  This is a trivially simple task if we are only interested in finding direct group membership.  Things can get much more complicated when nested or indirect group membership is also involved.  Consider the following:

Group A: members – “Timmy”, “Alice”, “Bob”, “Group B”

Group B: members – “Jake”, “Jimmy”, “Nelson”

If we wanted to fully expand the group membership of Group A, we would expect to see 6 users in this case.  The issue of course is that the membership for a group is held on the ‘member’ attribute.  If we were to inspect this attribute directly, we would see only 4 members, with one of them being ‘Group B’.  The problem of course is that we cannot tell just by looking at the ‘member’ attribute which one is a group and which ones are the object types we are interested in (in this case user objects).  Short of a naming convention to indicate which is a group, we would have to bind or search for each object and determine if it was a group in order to continue the search.  This is how it is done today using .NET 1.x.  In fact – you can find an example of this by reading Chapter 11 and specifically viewing Listing 11.7.  I am also glossing over a couple details for 1.x regarding large DN-syntax attributes – but you can read about that of course in Chapter 11 .  I also won’t post the code for expanding group membership using recursion in 2.0 because that code is already available for download from the book’s companion website (Listing 11.6).  However, I will talk about this as a basis to discover a more general pattern.

Introduced with Windows 2003 and available to .NET 2.0 users is a new type of search called Attribute Scoped Query (ASQ).  An ASQ allows us to scope our searches to any DN-syntax attribute.  This powerful feature is ideal for things like membership expansion, or indeed, any DN-syntax attribute that should be expanded.  By scoping our search on the DN, we can easily overcome some of the limitations in other methods (such as range retrieval), which leads to a simpler conceptual model.

Another example where we would want to expand DN-syntax attributes occurs when we are checking for employees managed directly and indirectly by a particular individual.  For instance, we might have an employee that manages 1 employee that in turn manages 15 other employees.  It is fair to say in most organizations that the first employee really manages 16 employees rather than just one.  We have to use recursion however to fully expand this relationship.  The employee carries their manager’s DN on the attribute ‘manager’, while the manager has a backlink to the employee on the ‘directReports’ attribute.  This is a similar class of problem as the group membership expansion.

If we look at these two examples, we should notice some similarities and some key differences.  In both cases, we have the DN of another object to describe the relationship.  In both cases, we need to chase that DN to see if it in turn references other DNs.  However, there are two key differences.  First, in the case of group membership, we don’t care to see the intermediate results (e.g. Group B), but only the fully expanded members.  Next, for group membership, we are chasing a multi-valued forward link (the ‘member’ attribute), while in the employee example, we are chasing the backlink (the ‘directReports’ attribute).  The question we should consider is whether these differences will change our pattern.  They would be almost identical problems if the employee was trying to figure out all their bosses, or the user was trying to determine all their group memberships.

<Jeopardy music playing> So, do the two differences matter?  What if the forward link is single-valued (‘manager’ as opposed to ‘member’ for example)? </Jeopardy music playing>

The answer is yes and no.  The problem with excluding intermediate results certainly must be accounted for, but whether or not it is the backlink or forward link actually has no bearing on the problem.  It turns out that ASQ searches work just fine with DN-syntax attributes of either type – even when the forward link is single-valued.

Ignoring the intermediate value issue for now, we can produce a generalized solution for any DN-syntax recursion:

          public
          class RecursiveLinkPair
{ DirectoryEntry entry; ArrayList members; Hashtable processed; string attrib; public RecursiveLinkPair(DirectoryEntry
entry, string attrib) { if (entry
== null) thrownew ArgumentNullException("entry"); if (String.IsNullOrEmpty(attrib)) thrownew ArgumentException("attrib"); this.attrib
= attrib; this.entry = entry; this.processed
= new Hashtable(); this.processed.Add( this.entry.Properties[
"distinguishedName"][0].ToString(), null ); this.members
= Expand(this.entry); } public ArrayList
Members { get { returnthis.members;
} } private ArrayList Expand(DirectoryEntry group)
{ ArrayList al = new ArrayList(5000); DirectorySearcher
ds = new DirectorySearcher( entry, "(objectClass=*)", newstring[]
{ this.attrib, "distinguishedName" }, SearchScope.Base
); ds.AttributeScopeQuery = this.attrib; ds.PageSize
= 1000; using (SearchResultCollection src = ds.FindAll())
{ string dn = null; foreach (SearchResult
sr in src) { dn = (string)
sr.Properties["distinguishedName"][0]; if (!this.processed.ContainsKey(dn))
{ this.processed.Add(dn, null);
al.Add(dn); if (sr.Properties.Contains(this.attrib))
{ SetNewPath(this.entry, dn); al.AddRange(Expand(this.entry));
} } } } return al; } //we
will use IADsPathName utility function instead//of
parsing string values. This particular function//allows
us to replace only the DN portion of a path//and
leave the server and port information intactprivatevoid SetNewPath(DirectoryEntry
entry, string dn) { IAdsPathname pathCracker = (IAdsPathname)new Pathname();
pathCracker.Set(entry.Path, 1); pathCracker.Set(dn, 4); entry.Path = pathCracker.Retrieve(5);
} } [ComImport, Guid("D592AED4-F420-11D0-A36E-00C04FB950DC"), InterfaceType(ComInterfaceType.InterfaceIsDual)] internalinterface IAdsPathname
{ [SuppressUnmanagedCodeSecurity] int Set([In, MarshalAs(UnmanagedType.BStr)] string bstrADsPath,
[In, MarshalAs(UnmanagedType.U4)] int lnSetType); int SetDisplayType([In,
MarshalAs(UnmanagedType.U4)] int lnDisplayType);
[return: MarshalAs(UnmanagedType.BStr)] [SuppressUnmanagedCodeSecurity] string Retrieve([In,
MarshalAs(UnmanagedType.U4)] int lnFormatType);
[return: MarshalAs(UnmanagedType.U4)] int GetNumElements();
[return: MarshalAs(UnmanagedType.BStr)] string GetElement([In,
MarshalAs(UnmanagedType.U4)] int lnElementIndex); void AddLeafElement([In,
MarshalAs(UnmanagedType.BStr)] string bstrLeafElement); void RemoveLeafElement();
[return: MarshalAs(UnmanagedType.Interface)] object CopyPath();
[return: MarshalAs(UnmanagedType.BStr)] [SuppressUnmanagedCodeSecurity] string GetEscapedElement([In,
MarshalAs(UnmanagedType.U4)] int lnReserved, [In,
MarshalAs(UnmanagedType.BStr)] string bstrInStr); int EscapedMode
{ get; [SuppressUnmanagedCodeSecurity] set;
} } [ComImport, Guid("080d0d78-f421-11d0-a36e-00c04fb950dc")] internalclass Pathname
{ } 

Notice I am using the IADsPathName utility interface here.  Since recursion requires us to re-base our search each time, we need to robustly update our DirectoryEntry instance’s .Path each time.  This interface does a much better job than trying to write your own string parsing routines - especially when you need to preserve server and port information for things like ADAM.  Whenever you see interfaces like this, check to make sure someone hasn’t already done the setup work for you.  You can check the .NET framework or ActiveDs interop assembly using Reflector and find the declaration oftentimes.

The final issue we must deal with now is the problem of intermediate values – specifically how to exclude them.  I am going to leave that exercise to the reader with just a hint:

• I only included 2 attributes in each search.  If you have already seen my solution for Group Expansion in the book (Listing 11.6), you will notice that I make use of a 3rd attribute (objectClass).  Did I need to?

Well, this is a long enough post for now.  Signing off…

With very little fanfare, I am announcing that the companion site for ‘The .NET Developer’s Guide to Directory Services Programming’ is available now.  We have managed to snag a fairly relevant domain name for it and rushed to put out a Community Server based site (a review on this tool later perhaps).  You can find it here:

Directory Programming .NET

Our first order of business is to get the code samples out there.  Right now, we have released what I term the ‘raw’ samples as they are verbatim from the book (available here).  The samples are still a great start even though they are slightly truncated in some cases.  The truncation will only affect the more sophisticated examples we have in the book that would have taken pages of code to print in entirety.

My next order of business is to finish converting all the book samples into a more easy to consume test harness release.  I say ‘test-harness’ in a loose manner as TDD guys will probably not be satisfied.  I have put together ad-hoc test cases for each of the non-trivial samples in the book and modified them to work with configuration (so you don’t have to hardcode your domain over and over again, for instance).  This is taking some time, but should be done shortly.  Once this is done, you can use TestDriven.NET or NUnit to run these guys pretty easily.

Future plans for the site include more and more samples (not from the book necessarily) as well as a place for us to publish errata and updates as we find them.  We have enabled the forums feature as of now and will gauge its usefulness as we go.

My co-author Joe is on the hook to convert all the samples to VB.NET.  I don’t particularly envy him – we didn’t realize how many frickin samples we had until we tried to put them all together.  He has his work cut out for him.

As for when you can get your hands on a copy of the book.  The answer is… now.  It is in stock at Addison-Wesley and Amazon and other retailers should have it stocked any time now.  Brick and mortar stores will be last, but should be in the next week or so.  Of course, purchasing it through my Amazon link on this site or the companion site would be appreciated since we are running this companion site out of our own pockets.

A little old, but I found this article on MSDN.  What a sweet looking application for the Tablet PC.  Anything Steven Toub writes seems to be pure gold (check out his Fun with DVR-MS article as well).  It makes me want to get one just to try it.  I have only played Suduko a couple times on the plane when I found a puzzle in the in-flight magazines.  I was surprised at how addictive it was – it kept me entertained the almost the whole trip (yeah, I was slow the first time).

Scott Guthrie has some good news for the ADSI folks that have struggled so much with the IIS provider until now.  These new, managed APIs for IIS should replace all the spackle that was crusted onto ADSI to wedge the IIS provider into that model.  Granted, this is not really available yet - but at least relief it in sight.

Joe and I had a great time on Wednesday presenting our talk on Directory Services Programming in .NET.  Being the first time that we have ever presented together, we did no know exactly how it would work out.  All in all, we felt it went pretty well.  Thanks to everyone that attended!

One of the cool parts for us was that our publisher sent over some draft copies of the book.  We knew our publisher was sending something, but we had thought it was a sample chapter or two.  It was quite surprising to open the box and find the full text!  Seeing your hard work in print for the first time almost gives you goose bumps.

As promised, I am attaching the presentation material to this post.  It includes the updated presentation that we used as well as all the samples that we used during it.  We actually did not get to one of the samples called Dirsync, which allows us to poll the directory periodically for updates, so check it out.

If anyone has questions on these samples or the topic itself, Joe and I can be reached through the MS newsgroups or the ASP.NET Forums.  I would also suggest checking out what I consider useful System.DirectoryServices resources.  I will try to keep that updated as I find more.

I had a great time in Las Vegas this last week at the DEC 2006 conference.  It was great connecting with so many of the participants as well as the personalities involved in the presentations.  There were some really good presentations that I attended (e.g. Guido, Dean & Joe, and Stuart’s), and getting to speak one-on-one with so many of the product manager’s of the involved technologies was great.  The conference was big, but not TechEd big, so the interactions were of much better quality in my opinion.

I was surprised to run into only a couple people from Avanade there, however.  Being a large Microsoft consulting company, I would have thought we would have more folks from our infrastructure practice there learning, if not speaking themselves.

The last day of the conference was fun.  We had a nice dinner with a bunch of folks – Katherine Coombs, Joe Richards, Dean Wells, Paul Williams, Don Wells (Dean’s dad), and Eric.  Listening to the different accents and slang (Dutch, Welsh, English, and Aussie/English mix) was a trip.  On a side note – if Paul Williams is any indicator – Welshmen eat entire cakes for dinner and prefer their cow-flesh raw.  When asked, “what temperature” he would like his burger cooked, Paul looked around quizzically and said, “warm?”.  This was after, of course, he had devoured a 10 lb. brownie (not joking here) for lunch – we are talking a dense pile of chocolate that could cause serious injury if dropped on a man’s foot.

I did not have a hotel room for the last night before my 7am flight back to Cleveland.  Initially, I had planned to stay up the night and just go to the airport nice and early.  However, after Gil, Katherine, Dean, Jorge, Paul, and Ulf decided one after another to go to bed, I would have been left alone with the hardcore gamblers/insomniacs/general freaks in Vegas at that hour.  Ulf was kind enough to let me have his extra bed for 3 invigorating hours of sleep before departing for the airport.

If Gil would have me back next year, I would definitely do it again.

One of the new features of .NET 2.0 is the System.DirectoryServices.Protocols (SDS.P) namespace that gives us access to the native LDAP api without relying on ADSI.  We can accomplish pretty much anything now in LDAP using managed code and we get around some of the wonkiness of ADSI.

Performing a simple search in SDS.P is pretty straightforward actually.  We just create a connection to the directory using the LdapConnection class, bind to the connection and then make request/response pairs on the connection.  One of the request/response pairs is SearchRequest and SearchResponse.  Without going into too many details, using these two classes in a synchronous manner is pretty easy.  What might be surprising however is that developers will often run into the following error:

System.DirectoryServices.Protocols.DirectoryOperationException : The size limit was exceeded

This departs from System.DirectoryServices (SDS) and ADSI where we do not get errors for simple searches even if we have not enabled paging.  In SDS, a similar query with DirectorySearcher would just return the MaxPageSize for the directory (usually 1000).  We know from SDS that to get more than the MaxPageSize, we need to use paging.  That is as simple as setting DirectorySearcher.PageSize > 0.

So, what about SDS.P.  It turns out that one of the really nice things that ADSI did for us was make paging so seamless.  If we wanted to use it, we simply asked for a specific page size and it just worked.  Now, since we are at a lower level, we need to take care of these details ourselves (native LDAP programmers already know this of course).

How do we do this in SDS.P?  Here is some sample code that implements paging and returns a collection of SearchResultEntry objects.

Well, it was bound to happen.  I was using free .NET 2.0 beta hosting and the account was expiring.  I had to switch servers and providers in order to keep my mail and site intact.  Now that that transistion has occurred, hopefully I will get around to posting some more interesting tidbits.