Clipboard behaves differently in .NET 3.5 and 4, but why?

Question

We recently upgraded a very large project from .NET framework 3.5 to 4, and initially everything seemed to work the same. But now bugs have started to appear on copy paste operations. I have managed to make a small reproducible app, which shows the different behavior in .NET 3.5 and 4. I have also found a workaround (manually serialize the data to the clipboard), but I'm left with a need to know "why" there is a difference in behavior.

This is the small test app I made:

using System;
using System.Collections.Generic;
using System.IO;
using System.Runtime.Serialization.Formatters.Binary;
using System.Windows.Forms;

namespace ClipboardTest
{
    public class Program
    {
        [Serializable]
        public class Element
        {
            public Element(string name)
            {
                this.name = name;
            }

            public string name;
        }

        public static List<Element> TestSerializer(List<Element> obj)
        {
            var memoryStream = new MemoryStream();
            var formatter = new BinaryFormatter();
            formatter.Serialize(memoryStream, obj);
            return (List<Element>)formatter.Deserialize(new MemoryStream(memoryStream.GetBuffer()));
        }

        public static List<Element> TestClipboard(List<Element> obj)
        {
            Clipboard.SetDataObject(obj);
            return (List<Element>)Clipboard.GetDataObject().GetData(typeof(List<Element>));
        }

        public static void DumpObject(string testName, List<Element> obj)
        {
            if (obj == null)
            {
                Console.WriteLine("{0} : List is null", testName);
                return;
            }
            foreach (var prop in obj)
            {
                Console.WriteLine("{0} : {1}", testName, prop.name);
            }
        }

        [STAThread]
        static void Main()
        {
            var copyData = new List<Element> { new Element("all good") };
            DumpObject("Serializer", TestSerializer(copyData));
            DumpObject("Clipboard", TestClipboard(copyData));
        }
    }
}

.NET 3.5 output:
Serializer : all good
Clipboard : all good

.NET 4 output:
Serializer : all good
Clipboard : List is null

I have looked at the .NET source for the Clipboard & DataObject class, but I couldn't see what serializer was used. The MSDN documentation says that the type must be serializable, which in this case both the List<> and Element classes are. Copying an Element object works just fine, but as soon as I copy a list of elements, it breaks.

To test, I have created 2 C# "Console Application" projects in Visual Studio 2010 SP1. The first project I have left with the default "Target framework" setting of ".NET Framework 4 Client Profile". The second project I have modified to use ".NET Framework 3.5 Client Profile".

Additional information about my Forms DLL version:
Original filename: System.Windows.Forms.dll
File version/Prouct version : 4.0.30319.235
Language: English (United States)
Date modified: 16-02-2012 22:50

Answer 1

I repro. You can get more insight into the bug with Debug + Exceptions, tick the Thrown checkbox for CLR exceptions. That will stop the program when an internal exception is thrown by the clipboard code in the framework. The IDataObject.GetDataHere() implementation method fails with a COM exception, "Invalid FORMATETC structure (Exception from HRESULT: 0x80040064 (DV_E_FORMATETC))".

There is something wrong with the format. That becomes clear when you set a breakpoint after the Clipboard.SetDataObject(obj) statement. And put Clipboard.GetDataObject().GetFormats() in a debugger watch expression. I see:

"System.Collections.Generic.List`1[[ClipboardTest.Program+Element, ConsoleApplication1, Version=1.0.0.0, Culture=neutral, Public"

Note how the string is truncated, the PublicKeyToken part got mangled. You can arbitrarily alter this truncated string by changing the namespace name and the project name. Make them short enough and the program won't fail.

Clearly this is the cause of the problem. The string length is clipped to 127 characters, any type whose full name is longer than that is going to cause this failure. With a high likelihood that this will be a generic type since they have very long names.

Please report this bug at connect.microsoft.com. Your code demonstrates the bug very well, just posting a link to it in your bug report will be sufficient. I don't have a very good workaround, ensuring the name is short enough is not very practical. But you can with code like this:

        // Put it on the clipboard, use a wrapper type with a short name
        var envelope = new List<object>();
        envelope.AddRange(obj);
        Clipboard.SetDataObject(envelope);

        // Retrieve from clipboard, unwrap back to original type
        envelope = (List<object>)Clipboard.GetDataObject().GetData(typeof(List<object>));
        var retval = new List<Element>();
        retval.AddRange(envelope.Cast<Element>());
        return retval;

---

UPDATE: this bug is reported fixed in VS2013.