Hashtables and Web Services and .NET. What’s up with that?

The UserSet class was supposed to be implemented like this:

public class UserSet
public NFFTI.User user;
public NFFTI.GroupCollection groupCollection;
public Hashtable propertyCollection;


propertyCollection being (quite obviously) a Hashtable member that the Web Service could access by using the name of the property (ex: string fakeID = us.propertyCollection[“Fake ID”];). That makes sense, right? Except that Hashtable does not implement IXmlSerializable, thus rendering it useless as a member of a class that’s supposed to be returned by a web service method call.


After a bit of discussion with my partners in crime, Dominic Pease and Jamie Cansdale, we found a sample SerializableHashtable class on Usenet that implements both Hastable and IXmlSerializable. That looked perfect and it worked, except for the fact that the unserialized member would come out as a DataSet, and not an Hashtable. I’m sure that it would be possible for a better developer than me to modify SerializableHashtable to output a proper type, but in the end I decided to modify the Reference.cs generated file in the Test Harness project by adding

using UserSet as NFFTI.UserSet;

at the beginning and commenting out the UserSet proxy class in this file. Contrary to popular (and my) belief, it worked fine and now I can access properties by name. The main drawback of this fix is that I have to reference the Business Object project from the Test Harness in order to know about the UserSet class. I’ll gladly accept suggestions on how to avoid having to rely on this kludge 🙂

[Now Playing: Depeche Mode – Wild Boys]

Leave a Reply

Your email address will not be published. Required fields are marked *