MethodAccessException on CF 2.0 List<T>.Sort

Question

I've got some library code that works on a range of .NET runtimes (regular, CF, Silverlight, etc) - but a small block of code is breaking only on CF 2.0, with a MethodAccessException. I'm pretty sure it is a runtime bug, but does anybody know any good workarounds? It works fine in CF 3.5, but I need to be able to support CF 2.0 too.

Specifically, this relates to a library assembly using generics, being given a non-public T by the caller. I don't do anything nasty to the T (such as reflection), but it breaks anyway...

All it does is wrap the values and add them to the list, then sort the list via a Comparison<>. I have also tried Array.Sort, IComparer<Wrapper<T>>, IComparable<Wrapper<T>>, etc - all fail in the same way: MethodAccessException - with the VS tip:

If the access level of a method in a class library has changed, recompile any assemblies that reference that library.

But make the T public and it all works fine... note that we were never sorting on T - we were only working with Wrapper<T>...

Any input appreciated...

---

Library assembly:

public static class LibraryClass
{
    public static void Test<T>(T foo, T bar)
    {
        // vastly simplified... I am aware that it is already in order here ;-p
        var list = new List<Wrapper<T>>();
        list.Add(new Wrapper<T> { Tag = 1, Value = foo });
        list.Add(new Wrapper<T> { Tag = 2, Value = bar });

        list.Sort((x,y) => x.Tag.CompareTo(y.Tag)); // BOOM!!
    }
}

public class Wrapper<T> // public to prove this isn't a factor...
{
    public T Value { get; set; }
    public int Tag { get; set; }
}

---

Calling assembly:

public static class Program
{
    static void Main()
    {
        MyData foo = new MyData {Name = "foo"},
            bar = new MyData {Name = "bar"};

        LibraryClass.Test<MyData>(foo, bar);
    }
}

class MyData // but make MyData public and it works...
{
    public string Name { get; set; }
}

Answer 1

Have you tried writing your own sort - perhaps the built in one is doing some reflection shenanigans... Not with a view to using your own in the long term - but as a means of debugging the problem. It should be quick to code in something else and at least see whats then.

I presume you don't get a stack trace when it goes boom.

Answer 2

I remember having troubles (sometimes) to make sure that the right dotNET stuff is on the target device. This was in dotNET CF 1.0 days. Could this still be the issue here?