Peter Ritchie's MVP Blog : .NET 3.5

DataContractSerializer.ReadObject is easily confused.

PeterRitchie — Thu, 30 Apr 2009 02:14:41 GMT

With WCF services you need to declare contracts and generate contract classes that encapsulate those contracts. Most of the time you can simply let the framework deal with whatever it needs to do to deal with these objects. Sometimes, you need to actually see without running a service what XML would result from a contract object or serialize a contract object from XML text.

In .NET 3.5 there exists the System.Runtime.Serialization.DataContractSerializer class that perform serialization of data contracts.

Based on its documentation it seems fairly simple to create data contract object to/from XML methods. For example:

    public static T XmlToContractObject<T>(string xml) where T : class, IExtensibleDataObject
    {
        MemoryStream memoryStream = new MemoryStream(Encoding.Unicode.GetBytes(xml));
        using (
        XmlDictionaryReader reader = XmlDictionaryReader.CreateTextReader(memoryStream, Encoding.Unicode,
                   new XmlDictionaryReaderQuotas(), null))
        {
            DataContractSerializer dataContractSerializer = new DataContractSerializer(typeof(T));
            return dataContractSerializer.ReadObject(reader) as T;
        }
    }
 
    public static string ContractObjectToXml<T>(T obj) where T : IExtensibleDataObject
    {
        DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
 
        String text;
        using (MemoryStream memoryStream = new MemoryStream())
        {
            dataContractSerializer.WriteObject(memoryStream, obj);
 
            text = Encoding.UTF8.GetString(memoryStream.GetBuffer());
        }
        return text;
    }

But, when you try to perform a round-trip from a contract object to XML and back you'll notice that you get SerializationException with the cryptic message of "There was an error deserializing the object of type <sometype>. The data at the root level is invalid", despite that the XML seems view when examined.

When Encoding.UTF8.GetString is called, it literally translates the entire array into a String object. This means that it reads any and all 0 bytes in the array and dumps out null characters ('\0') into the string. Why do I mention this? Well, MemoryStream uses a self-expanding buffer to write to. When MemoryStream runs out of space in its buffer, it doubles the size of the buffer, zeroes it out, then copies the original buffer to the start of the new buffer. When MemoryStream.GetBuffer is called it simply gets a reference to this buffer, regardless of how many bytes have been written to the stream. So, most of the time you get a buffer with zeroes padded to the end of it.

If you look closely at the resulting XML, there are a bunch of '\0' characters at the end of the string.

As it turns out, DataContractSerializer.ReadObject (or something it calls) doesn't like all the extra null characters and this is the cause of the SerializationException.

Irritating as this may be, the fix is fairly straightforward. Simply, create a new buffer equal to the length of the stream and copy the data from the MemoryStream buffer to the new one--trimming all the extra zeroes. For example:

    public static string ContractObjectToXml<T>(T obj) where T : IExtensibleDataObject
    {
        DataContractSerializer dataContractSerializer = new DataContractSerializer(obj.GetType());
 
        String text;
        using (MemoryStream memoryStream = new MemoryStream())
        {
            dataContractSerializer.WriteObject(memoryStream, obj);
            byte[] data = new byte[memoryStream.Length];
            Array.Copy(memoryStream.GetBuffer(), data, data.Length);
 
            text = Encoding.UTF8.GetString(data);
        }
        return text;
    }

DevTeach 2009 Vancouver

PeterRitchie — Thu, 26 Mar 2009 16:33:00 GMT

The schedule for DevTeach 2009 Vancouver has been announced (http://www.devteach.com/). There’s lots of great software development sessions from some of the leaders in our industry.

If you’re planning on improving yourself, this is the conference to go to. Not only can you attend excellent sessions; but you can hob-knob with the presenters and pick their brains.

If you have a friend or co-worker who’s interested, there’s a limited-time two-for-one offer for an even better price: http://www.devteach.com/Register.aspx

Trials and Tribulations of DataGridView, Column Selections, and Sorting

PeterRitchie — Tue, 26 Aug 2008 20:06:00 GMT

I had to implement some custom sorting in a DataGridView recently. Essentially, the stakeholders wanted full column selection (like Excel) while still having the ability to sort the data based on a particular column.

This particular DataGridView is data-bound. DataGridView offers the Sort(DataGridViewColumn, ListSortDirection) method to perform this. Nice and easy I thought: I’ll set the SelectionMode to DataGridViewSelectionMode.ColumnHeaderSelect and simply call Sort with the selected column.

Well, much to my chagrin this had the side effect of making that column look selected all the time. No matter where else I clicked, that recently sorted column looked selected (SelectedColumns had a count of zero). And to add insult to injury, when I control-clicked that column (thinking it was selected) to unselected it, it caused a NullReferenceException deep in the framework.

Suffice it to say, this makes it very difficult to sort by columns in DataGridView without using the built-in sort-column-when-header-is-clicked mode.

What I’m now attempting to do is to unselect the column before sorting it. This, in itself, is not trivial either; there’s no public method to select or deselect a column in the DataGridView. I’ve had to create a new DataGridView derivative and call the protected method SetSelectedColumnCore. A few hoops…

I’ve logged a couple of issues on Microsoft Connect about these problems. The first is about ctrl-clicking the column and getting an exception: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 The second is about the visual state of the column remaining “selected”: https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=363623 Attached to this post you will find the project referenced by the two Connect issues.

[Update: I've currently only tried this with a .NET 2.0 project in Visual Studio 2008 SP1; if you find this problem occurs in Visual 2008 RTM, please comment.]

[Update: I overlooked the DataGridViewColumn.Select property, so there's no need to derive from DataGridView]

Drag-copying in Visual Studio Solution Explorer.

PeterRitchie — Fri, 18 Jul 2008 16:46:00 GMT

NOTE: I've tried this in Visual Studio 2008 (VS2k8), I'm assuming the same thing happens in Visual Studio 2005 (VS2k5).

In the process of refactoring, it's *very* common for me to rename a type. This is most easily done by renaming the file in the Solution Explorer (SE)--which renames the file, the type, and and any uses of the type in the entire solution.

Occasionally, I need to create a new type based on another. Copying an abstract type in order to implement the abstract type is often handy--I just fill in the abstract members (and delete "abstract") in the copied type after renaming it.

Drag-copy in the SE seems like it would take care of a couple of steps at once for me: make a copy and rename it. Unfortunately it doesn't do that. It makes a copy of the file (as "Copy of typename.xx") but doesn't rename any types in the class that match the file name.

This might seem somewhat trivial... I can simply rename the file name then refactor rename the type in the file so that the type and all it's constructors are renamed in one fell swoop. Alas, this simply opens a can of worms that can completely confound a newcomer and annoy an expert.

That simple, intuitive method of renaming a copy of a file then the type within the file actually renames *all* types of that name. Since we've just made a copy of the type, that means it's always going rename types in two files. The side-effect of drag-copy in SE means you *must* manually rename the type in the file you just copied. You can do this with search-replace; but that's friction I don't want and really makes SE drag-copy unusable.

I've logged a bug about it on Connect; but the olde "by design" card was played...

Nested Types

PeterRitchie — Tue, 15 Jul 2008 14:47:00 GMT

Recently Michael Features blogged about nested types. The title was almost "nested types considered harmful".

I don't agree. I don't agree that they're any more harmful than any other C# construct (except goto...). Nested types are like anything else in our tool-belt: they have a time and place and can be abused.

But, when to use them? Well, for the most part I agree with Michael, you should avoid them. But, there are times when they're simply the best solution in a given set of circumstances.

Let's look at asynchronous programming model (APM) in .NET.

        // Paraphrased from MSDN

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                listener);

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            // Get the listener that handles the client request.

            TcpListener listener = (TcpListener)ar.AsyncState;

            // End the operation and display the received data on

            // the console.

            TcpClient client = listener.EndAcceptTcpClient(ar);

            // TODO: do something with client.

            // Process the connection here. (Add the client to a

            // server table, read data, etc.)

            Trace.WriteLine("Client connected completed");

In this simple scenario we are getting by with a state of simply a TcpListener object. In a more complex scenario, you'll likely also want a connection-specific queue, some sort of information about what to do after a connection, etc. While you can use existing types of have several collection instance fields to keep track of each of these things; you then have to introduce synchronization of those collections, managing the content of those collections, etc.--it's much easier and safer to send that information on the stack. One method I've tried is simply passing an Object collection as the state; but that quickly becomes hard to manage because of the lack of type-safety on the elements in the array (if I remove an element and replace it with another type, the compile can't know and I'll get a run-time error instead of a compile-time error). To get type safety I generally introduce a new type to aggregate all the types I need in this asynchronous callback. While this new type *could* be reusable by other classes; it likely isn't and I don't want to then be bound that that explicit contract I've signed by making the types publicly available. The only option of not making them publicly available is as private nested types. For example:

        private class AcceptTcpClientParameters

            public CommandQueue CommandQueue { get; private set; }

            public Command NextCommand { get; private set; }

            public TcpListener TcpListener { get; private set; }

            public AcceptTcpClientParameters(int commandQueue, int nextCommand, TcpListener tcpListener)

                CommandQueue = commandQueue;

                NextCommand = nextCommand;

                TcpListener = tcpListener;

        // Accept one client connection asynchronously.

        public static void DoBeginAcceptTcpClient(TcpListener

            listener, CommandQueue commandQueue, Command nextCommand)

            // Start to listen for connections from a client.

            Trace.WriteLine("Waiting for a connection...");

            // Accept the connection.

            // BeginAcceptSocket() creates the accepted socket.

            listener.BeginAcceptTcpClient(

                DoAcceptTcpClientCallback,

                new AcceptTcpClientParameters(commandQueue, nextCommand, listener));

        // Process the client connection.

        public static void DoAcceptTcpClientCallback(IAsyncResult ar)

            AcceptTcpClientParameters parameters = ar.AsyncState as AcceptTcpClientParameters;

            if(parameters == null) return;

            TcpClient client = parameters.TcpListener.EndAcceptTcpClient(ar);

            parameters.NextCommand.Process(parameters.CommandQueue, client);

I find this use of nested types to be more object-oriented (the needs of the DoAcceptTcpClientCallback are abstracted), more intention revealing, better implements Single Responsibility Principle (SRP), better separates concerns, more maintainable and more agile.

Now, to be clear; this is forced set of circumstances. You're using a library that implements the APM (right? You haven't implemented APM yourself...). But, that's my point--nested types are almost essential in a given set of circumstances.

Upcoming C# 3 Guidance From Microsoft

PeterRitchie — Thu, 13 Mar 2008 15:46:00 GMT

Mircea Trofin has some design guidelines with regard to some C# 3 language additions (that I assume will make it into a revised Framework Design Guidelines of some sort). They more less agree with the guidelines I published in Code Magazine a while ago. There are some slight differences:

Consider using extension methods in any of the following scenarios: to provide helper functionally relevant to every implementation of an interface... and,

Do define extension methods in the same namespace as the extended type, if the type is an interface, and if the extension methods are meant to be used in most or all cases. This applies to framework designers that are publishing interfaces but also want to publish callable methods that apply to all implementation of those interfaces. My article approaches the guidelines more from a non-framework designer. I do agree that extension methods to extend interfaces is very useful and is probably one of the most adept use of extension methods. Although, I think the wording of this guideline could use improvement.

Avoid defining extension methods on System.Object, unless absolutely necessary. Good advice.

Do not define extension methods pertaining to a feature in namespaces normally associated with other features. Instead define them in the namespace associated with the feature they belong to, or a namespace of it. This is really unclear (and seems to suggest contradicting the first guideline: Avoid frivolous use of the extension methods feature when defining methods on a new type. Use the canonical, language-specific means for defining type members). I'm assuming the jist of this is, as a framework designer, don't arbitrarily put extension methods in the namespace of the type the method applies to, consider putting the extension method in a more applicable namespace, if possible. For example, if you want to declare an extension method "Forward" for Telecom.INode implementations, putting the method in a "Routing" namespace would be better than arbitrarily putting it in the "Telecom" namespace. I've changed the Mircea's guidance slightly to use a interface in the example--which I think makes it more clear.

Mircea also includes Consider using extension methods in any of the following scenarios:... when object model considerations would dictate taking a dependency on some assuming but taking such a dependency would break dependency management rules. This means, should you need to add a method to a class but adding that method would create cyclic dependency or would cause a lower level assembly/class to be dependant on a higher level class, break the method out into another assembly as an extension method. Use this advice with caution; I would argue that if you think you need a method like this at all (even if implemented as an extension method), you likely have some design problems and should only be considered when revising a published framework, and not when creating a new framework.

Another tidbit of guidance that came about after I wrote the article and Mircea doesn't mention is that extension methods can make writing fluent interfaces much cleaner by separating the state management concern of supporting a fluent interface from the class that it applies to.

Thoughts? Any additional guidance you feel has been overlooked (with regard to extension methods and LINQ)?

Playing with LINQ

PeterRitchie — Fri, 08 Feb 2008 18:52:00 GMT

If you're interested in seeing what you can do with LINQ and want to learn the syntax, there's a wonderful new utility called LINQPad that is available. It basically lets you type in LINQ statements (or create statements from tables) and see what the result would be with a given database.

CoDe Magazine Article.

PeterRitchie — Mon, 04 Feb 2008 18:31:00 GMT

The January/February edition of Code Magazine includes my article "C# 3.0 Syntax Additions-Design Guidelines".

Visual C# Developer Center Article

PeterRitchie — Thu, 03 Jan 2008 20:27:00 GMT

My latest Visual C# Developer Center Article Inferred Typing with Factory Methods as Extension Methods is now online.

New Warning CS1060 in C# 3 (Visual Studio 2008)

PeterRitchie — Sun, 09 Dec 2007 22:38:00 GMT

Recompiling C# 2 (Visual Studio 2005) code in C# 3 (Visual Studio 2008), you may incounter a new warning that didn't used to ocur:

Warning CS1060: Use of
possibly unassigned field 'fieldName'. Struct instance variables are initially unassigned if struct is unassigned.

Dealing strictly with syntax, C# let's you declare a value type (struct) with a reference member, for example:

namespace Examples
{
    using System.Drawing;
    public static class Program
    {
        public static void Main()
        {
            LabelEntry labelEntry;
            labelEntry.Location.Point.X = 0;
        }
    }
 
    public struct LabelEntry
    {
        public LabelLocation Location;
        public String Label;
    }
 
    public class LabelLocation
    {
        public Point Point;
    }
}

Unfortunately, in C# 2, and previous, it wouldn't give you an warning if you tried to read a value type reference member before initializing it, as in the highlighted code.

As I've alluded to before, syntactic correctness does not imply conceptional correctness and this warning improves syntax correctness.

If avoiding reference members in structs isn't clear, let me know and I can do a post on that.

New warning CS0809 in C# 3 (Visual Studio 2008)

PeterRitchie — Mon, 26 Nov 2007 20:31:00 GMT

There were several breaking changes (fixes) in C# 3 from C# 2. One is the ability to attribute a member override with ObsoleteAttribute without also attributing it the virtual member in the base class.

For example, the following will compile without error In C# 2 (Visual Studio 2005/.NET 2.0):

using System;

internal class BaseClass

    public virtual void Method()

internal class DerivedClass : BaseClass

    [Obsolete]

    public override void Method()

public static class Progam

    public static void Main()

        BaseClass baseClass = new DerivedClass();

        baseClass.Method();

This same code will generate a CS0809 warning with C# 3.

This change was done because, as you can see in the example, if DerivedClass.Method is accessed via a BaseClass reference, the compiler can't reliably warn you that you're in fact calling an Obsolete method.

In reality, even you you did call DerivedClass.Method() via a DerivedClass reference you still wouldn't get a warning. This may have something to do with a quirk in the way the compiler detects attributes with overrides and virtual methods; but I'm surmising.

The fix, if you have access to the base class, is to attribute bot the base and the derived class member with ObsoleteAttribute. If you don't have access to the base class, you'll have to live with or suppress the warning.