Drew Marsh has come across a change in XML-RPC.NET 0.7.0 which I should have documented: when mapping the members of an XML-RPC struct to the members of the corresponding .NET struct type, an exception is now thrown if any of the public members of the .NET struct do not have corresponding values in the XML-RPC struct. Previously missing members were ignored and the members of the .NET struct remained set to their default value.
I made this change because I didn't like the case where it was not possible to determine if a .NET struct member had been set to its default value from the corresponding member in the XML-RPC struct, or if the member was missing from the XML-RPC struct and the member in the .NET struct had been left with its default value.
It is perfectly valid for XML-RPC structs to be flexible as to which members they contain. The word "struct" was perhaps the wrong one to use for XML-RPC with its connotations from C and C++. Maybe something like "table" would have been better. To handle situations where the members of a struct are not fixed I implemented the XmlRpcStruct type which is basically a Hashtable with some extra type safety.
However using the XmlRpcStruct type in an interface does not convey much about what the corresponding XML-RPC type may contain and so where possible it is preferable to use a .NET struct type. The interface is easier to use, and from a service point of view you can document individual members using XmlRpcMemberAttribute which results in the documentation appearing in the service's automatically generated web page.
I don't like things which can fail silently in a non-benign way and so I'd like to retain the new default behaviour: if a member is missing from the XML-RPC struct and so can't be mapped to the corresponding member in the .NET struct, an exception is thrown. However for situations where the implementor is unconcerned about the possible confusion described above, I'd like to add a new attribute which can be applied at to the interface/class level, the struct as a whole, or individual members, and which can be used to suppress the missing member mapping exception Drew pointed me to the MissingMappingAction property of the System.Data.Common.DataAdaptor class as the model for this, the difference being that using an attribute provides more flexibility as to where it can be applied.