У меня есть код библиотеки, который работает в различных средах выполнения .NET (обычный, CF, Silverlight и т. д.), Но небольшой блок кода нарушает Только на CF 2.0 с MethodAccessException. Я почти уверен, что это ошибка времени выполнения, но знает ли кто-нибудь хорошие обходные пути? Он отлично работает в CF 3.5, но мне также нужна поддержка CF 2.0.
В частности, это относится к библиотечной сборке с использованием универсальных шаблонов, которой вызывающий дает непубличный T. Я не делаю ничего гадкого с T (например, отражения), но он все равно ломается ...
Все, что он делает, - это переносит значения и добавляет их в список,
затем отсортируйте список через Comparison<>. Еще пробовал Array.Sort,
IComparer<Wrapper<T>>, IComparable<Wrapper<T>> и др. - все
сбой таким же образом: MethodAccessException -
с подсказкой VS:
If the access level of a method in a class library has changed, recompile any assemblies that reference that library.
Но сделайте T общедоступным, и все будет хорошо ... обратите внимание, что мы никогда не выполняли сортировку по T - мы работали только с Wrapper<T> ...
Любой вклад приветствуется ...
Сборка библиотеки:
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; }
}
Вызов сборки:
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; }
}
хе-хе - я подумал, что выберу коллективный мозг, чтобы посмотреть, знает ли кто здесь какие-нибудь уловки ...





Вы пробовали написать свой собственный вид - возможно, встроенный выполняет некоторые махинации с отражением ... Не для того, чтобы использовать свой собственный в долгосрочной перспективе - а как средство отладки проблемы. Надо быстро закодировать что-то еще и хотя бы посмотреть, что тогда.
Я предполагаю, что вы не получите трассировку стека, когда он взорвется.
Действительно, трассировки стека нет. Я бы предпочел не переписывать такой фундаментальный метод, но мысль пришла в голову ...
Я предполагаю (при отсутствии каких-либо других ответов), что переписывающая сортировка должна быть достаточной ...
Я помню, что у меня (иногда) возникали проблемы с тем, чтобы убедиться, что на целевом устройстве есть нужный файл dotNET. Это было в dotNET CF 1.0 дней. Может ли это быть проблемой здесь?
Я так не думаю - достаточно просто показать, что он работает нормально, за исключением конкретного случая использования. Спасибо хоть.
Дох! Увидел вопрос, сразу подумал о том, чтобы сослаться на ваше сообщение в блоге ... потом увидел, что это вы спрашиваете :(