Дотошный читатель мог заметить, что при ссылках на первый выпуск .NET Compact Framework в качестве номера версии используется не номер 1.0, а номер 1.1. На то имеются свои основания.
Первый выпуск .NET Compact Framework проектировался так, чтобы обеспечивалась его совместимость с версией 1.1 .NET Framework для настольных компьютеров и серверов, и предполагался к поставке одновременно с ней. Версия 1.0 .NET Framework поставлялась в 2002 году вместе с Visual Studio.NET 2002. Версия 1.1 .NET Framework и NET Compact Framework поставлялись вместе с Visual Studio .NET 2003. В согласии со смыслом номеров версий, номер 1.1 соответствует младшему выпуску продукта, функциональность которого обновлена по сравнению с версией 1.0.
По причинам, обусловленным совместимостью версий на уровне двоичных кодов и рыночными соображениями, было решено синхронизировать номера версий .NET Framework и .NET Compact Framework. Таким образом, версию 1.1 .NET Compact Framework можно рассматривать как совместимое на уровне двоичных кодов подмножество функциональности, предоставляемой версией 1.1 выпуска .NET Framework, предназначенной для настольных компьютеров и серверов.
Заранее приносим свои извинения за возможные недоразумения по этому поводу.
.NET Compact Framework как подмножество платформы для настольных компьютеров
Приступая к проектированию .NET Compact Framework, мы знали, что в конечном счете должны получить некое совместимое подмножество среды .NET Framework, предназначенной для настольных компьютеров, которое удовлетворяло бы требованиям разработчиков. Вопрос о том, каким именно образом следовало определить это подмножество, стал предметом серьезного обсуждения. Следует ли отталкиваться от платформы .NET Framework, постепенно исключая из нее все то, что не нужно, или же лучше начать проектирование новой платформы с нуля, включая в нее только те средства, которые являются действительно необходимыми? Будучи не в состоянии решить эту философскую дилемму, мы остановились на том, чтобы использовать оба подхода и посмотреть, какой из них окажется более приемлемым. Такой способ действий требовал большего времени и ресурсов, однако, по моему мнению, только с его помощью и можно было окончательно разрешить указанные разногласия. Действуя в направлении сверху вниз, мы могли определить максимальный состав тех ключевых возможностей, поддержку которых мы хотели бы обеспечить, тогда как подход, соответствующий продвижению снизу вверх, позволял нам составить хорошее представление о том, какой может быть минимальная реализация и как влияет на размерные показатели и производительность добавление тех или иных возможностей. (Ради справедливости замечу, что лично я принадлежал к числу тех проигравших участников дебатов, которые рекомендовали использовать для создания библиотек программ разработку в направлении сверху вниз. Эта модель оказалась полезной в отношении понимания того, что же именно мы хотим создать, но не могла обеспечить необходимую производительность. Единственным путь, гарантирующий достижение этой цели, был связан с осуществлением разработки по принципу "снизу вверх".)