Какие различия существуют в DevForce между платформами Silverlight и не Silverlight?

Question

Недавно мы обнаружили ошибку в нашем коде, которая была вызвана тонкой разницей в том, как DevForce ведет себя под Silverlight по сравнению с средами, отличными от Silverlight. Мы обнаружили трудный способ, когда DevForce вызывает событие «все свойства изменили» в Silverlight, он делает это, используя string.Empty в событии PropertyChanged. Однако в не-Silverlight используется null. Это было не так уж сложно, но мы наверняка следили за null или string.Empty. Но нас беспокоило, есть ли другие тонкие различия, которые мы должны искать.

Есть ли другие известные различия между Silverlight и non-Silverlight, как это? Очевидно, есть некоторые различия, такие как Silverlight, не позволяющие синхронные запросы ... но это хорошо документировано. Я ищу такие мелкие вещи, которые могут сломать код, который ранее отлично работал в Silverlight.

Answer 1

Извините, что вы столкнулись с проблемой PropertyChanged. Эта дивергенция на самом деле возникла из-за старой ошибки в SL DataForm, но она никогда не была повторно рассмотрена в DevForce, потому что в документации MS говорится, что и пустая строка, и пустая строка делают то же самое. FWIW, DF использует пустую строку здесь во всех несовместимых средах .NET.

У нас нет документации по этим тонким отличиям. В целом, большинство различий в среде приводят к разной площади поверхности, обычно с уменьшенным API. Итак, как вы отметили, синхронные методы найдены только в сборках .NET, в то время как вы найдете API-интерфейсы, связанные с XAP, в сборках SL. Другие «отсутствующие» или измененные функции будут такими, как обработка файлов ввода/вывода и .config.

В целом DF пытается рационализировать API и поведение в разных средах, хотя в базовых реализациях могут быть незначительные различия или влияние производительности. Например, WCF, состав (MEF), сериализация и отражение - это несколько областей, которые мы обнаружили, не всегда работают одинаково в разных средах, хотя мы попытались смягчить их в DevForce, поэтому приложения не видят вопросы. DF также имеет реалистичные реализации для некоторых атрибутов (в основном для ODATA и аннотаций данных) в среде не.NET, что может вызвать проблемы, если вы ожидаете реальных типов.

Я просмотрел несколько отличий, которые могут быть неочевидны: 1) при клонировании в не.NET требуется конструктор без параметров; 2) выполняется проверка времени использования атрибутов ProvideEntityAspect и ProvideComplexAspect; только в .NET, 3) попытки выполнить шифрование/дешифрование с помощью набора параметров FIPS вызовут исключение NotSupportedException в не.NET.

Существуют различия в поддержке времени разработки. В SL странные исключения безопасности и сериализации будут выбрасываться VS при использовании ECS или с использованием данных времени разработки на основе первой модели кода.

Следует также отметить, что если вы выполняете модульное тестирование .NET кода SL, вы не можете предположить, что код также будет работать в SL. Вам действительно нужно протестировать в SL, чтобы избежать сюрпризов.

Если у вас есть вопросы о каких-либо конкретных областях DevForce или столкнетесь с непредвиденными различиями в среде, сообщите нам об этом.