Microsoft net compact framework что это
Не так много разработчиков осознают, что разрабатывая приложения для платформы Windows Mobile с использованием Compact Framework, у них существуют шансы собрать это же приложение под десктоп версию Windows! Я и сам об этом долгое время только задумывался, предполагая, что подобная возможность есть, но не рассматривал её как нечто, хоть сколько-нибудь реальное.
Существует несколько важных аспектов, которые нужно понимать, чтобы успешно организовать кросс-платформенную сборку. Я потратил прилично времени, собирая обломки знаний в разных местах сети, причём местами было настолько нетривиально, что решил поделиться с хабрасообществом тонкостями.
Во-первых, во-вторых, в-третьих.
Во-первых, необходимо изначально создавать приложение для Windows Mobile (т.е. это основная платформа). Это действительно важно. Причин несколько, но основная заключается в том, что Compact Framework на то и компактный, что там существенно меньше классов и свойств у классов. Т.е. совместимость с десктопом есть, но односторонняя, т.е. только в сторону десктопа.
В-третьих, надо также готовиться к тому, что будут некоторые ограничения, касающиеся дизайна форм. А именно, нельзя открывать форму визуальным редактором при десктопе, выбранном в качестве текущего таргета — сразу же в *.Designer.cs налетит множество свойств, не поддерживаемых мобильным фреймворком — придётся откатывать.
В пятых, не все сборки и неймспесы на 100% работают на десктопе. Например, я совершенно не уверен в том, что SQL Server Compact собирается на десктопе. Не проверял, поэтому не обещаю. Точно знаю, что с SQLite всё хорошо (хотя и придётся попотеть немного).
В-шестых, нужно разобраться, как можно отлаживать приложение на десктопе, ведь все знают, что при сборке мобильного приложения необходимо выбрать некое устройство, физическое или эмулятор!
Попробуем разобраться с основными тонкостями.
Desktop Target
Начнём с того, что у нас должен быть некоторый проект, созданный для Compact Framework. Создадим новый таргет через Build->Configuration Manager:
После этого добавим символ условной компиляции в свойствах проекта:
Начало положено. Посмотрим теперь, что делать, чтобы обеспечить подключение правильных сборок в нужном таргете. По умолчанию в нашем csproj файле нет никаких разделений по таргетам:
* This source code was highlighted with Source Code Highlighter .
Чтобы иметь полный контроль, необходимо организовать примерно следующий финт:
* This source code was highlighted with Source Code Highlighter .
В результате хитрых манипуляций с csproj файлом получается такая ерунда в Solution Explorer:
Это нормально, т.к. Visual Studio не совсем пригодна к таким извращениям (хотя и позволяет их в итоге).
Немного хитрый момент. Мой проект поддерживает как QVGA, так и VGA разрешение, однако, в Designer.cs у форм свойство ClientSize всегда соответствует QVGA разрешению. На десктопе же иметь окно размером 240х268 как-то неправильно, особенно, когда есть VGA-скин. Поэтому в конструкторе после InitializeComponent() я помещаю участок условной компиляции:
Size vertSize = new Size(480, 560);
Size horisSize = new Size(640, 480);
* This source code was highlighted with Source Code Highlighter .
Как видно, у меня объявлено две переменные типа Size. Зачем это нужно? Просто-напросто, у меня по F9 происходит переключение ClientSize, для эмуляции смены ориентации экрана. Полезно, когда необходимо протестировать OnResize. Да и в конце концов, есть же нетбуки с 800х480, для них ландшафтная ориентация — единственно возможная, чтобы всё поместилось на экране :)
Также видно, что MouseWheel тоже обрабатывается только на десктопе.
System.Diagnostics.Conditional
[Conditional(“Desktop”)]
public void SomeDesktopMethod()
>
* This source code was highlighted with Source Code Highlighter .
Отладка на десктопе
- В студии открыть Tools/Options, далее в дереве выбрать Device Tools/Devices.
- В выпадающем меню выбрать платформу, для которой необходимо организовать отладку на десктопе. Это будет необходимо повторить для всех платформ, где необходимо.
- Далее нужно выбрать любой из эмуляторов и нажать [Save As…]. Удобно назвать копию “My Computer”.
- Теперь надо закрыть студию и открыть %USERPROFILE%\Local Settings\Application Data\Microsoft\CoreCon\1.0\conman_ds_platform.xsl файл в текстовом редакторе.
- В файле необходимо найти элемент, соответствующий свежесозданному «дивайсу»
- Далее добавляем следующую строку —
true
сразу после тега . - Сохраняем conman_ds_platform.xsl и перезапускаем студию
Ну вот, теперь нам доступен отладчик и все вкусности десктопной отладки.
Заключение
Чтож, в статье перечислены основные подводные камни, с которыми я столкнулся в процессе сборки своего проекта под Windows. Далее всё было делом техники — ловил исключения и разбирался в их причине. Среди них были не найденные пути, которые, очевидно, на десктопе отличаются и т.д., но это всё уже было ничто, по сравнению с начальными проблемами.
PS. Почти всё, что описано выше, я выстрадал в результате долгих поисков, и вот, в самом конце, когда я искал способ отладки на десктопе, я натолкнулся на шикарную статью Дениела Моса о кросс-платформенной компиляции для Compact Framework :) Моя статья ни в коем случае не является переводом, однако, не могу не дать на неё ссылку.
Если вы знакомы с программированием для . NET Framework, то вам не составит труда перейти к освоению особенностей программирования для КПК и мобильных телефонов под управлением Windows Mobile . Ведь писать программы придется в уже знакомой вам среде Visual Studio . NET . Более того, вам даже не обязательно иметь сам карманный компьютер или смартфон для проверки написанного кода, так как в Visual Studio . NET уже имеются эмуляторы для этих мобильных устройств.
Цель данной лекции - сформировать представление о . Net Compact Framework технологии, ее развитии и возможностях.
Конечно, технология . NET Compact Framework несколько отличается от . NET Framework. Считается, что . NET Compact Framework является частью полной библиотеки . NET Framework. Действительно, между двумя этими платформами очень много общего. Но все же говорить о . NET Compact Framework как о подмножестве полной . NET Framework не совсем корректно. Дело в том, что . NET Compact Framework поддерживает серию классов, которых нет в полной библиотеке классов. Эти классы созданы специально для мобильных устройств и позволяют поддерживать, например, программную клавиатуру, возможности инфракрасной связи и отправки SMS .
Библиотеки управляемого кода
Для работы с этими библиотеками во время проектирования используются имена System. DLL , Systems .Windows . Form. DLL и System. Xml. DLL . На устройствах эти файлы могут иметь другие имена в зависимости от потребностей целевых устройств, связанных с именованием и учетом версий файлов. В процессе компиляции библиотеки управляемого кода используются аналогично тому, как заголовочные файлы используются компиляторами С/С++ или библиотеки типов используются прежними (полученными с применением VB6 и более ранних версий) кодами на языке Visual Basic для передачи информации об интерфейсах и типах, используемых компилируемым кодом .
Обычно детали реализации в приложениях учитываться не должны, поскольку задачи поиска, загрузки и управления общими библиотеками, присутствующими на устройстве, решаются средой времени выполнения.
С точки зрения программирования каждый из этих DLL-файлов предоставляет разработчику набор иерархических пространств имен, содержащих классы и типы. Примерами пространств имен, содержащих классы и типы, могут служить:
System.* System.Xml.* System. Data.* System .Drawing.* и тому подобные.
Во всех остальных случаях, не связанных с периодом компиляции, когда компилятору предоставляется список файлов, используемых для поиска классов, на которые имеются ссылки, разработчикам можно не беспокоиться о том, в каком файле находится тот или иной класс. Вместо этого они должны думать лишь о логической иерархии используемых пространств имен, тогда как вопрос о фактическом размещении конкретных типов в указанных файлах их заботить не должен.
Библиотеки базовых классов
Базовые классы содержат распространенные типы и функциональность, которые используются разработчиками при реализации большинства алгоритмов обработки данных. Базовые классы имеют следующий состав:
- Все основные типы данных, к которым, например, относятся целые числа, строки, числа с плавающей запятой, дата/время, массивы и коллекции.
- Средства файлового ввода-вывода , потоки, сетевые сокеты.
- Средства поиска типов, методов и свойств в сборках и привязки к ним во время выполнения. Эти возможности называют отображением ( reflection ).
- Средства, позволяющие учитывать в приложениях региональную и местную специфику. Эти возможности называют глобализацией ( globalization ).
Вышеперечисленные функциональные возможности вместе с дополнительными базовыми классами инкапсулированы в следующих иерархических пространствах имен:
Библиотеки пользовательского интерфейса
При создании библиотек пользовательского интерфейса преследовались две цели:
- предоставить разработчикам возможность создавать многофункциональные приложения уровня предприятия с использованием таких современных высокоуровневых элементов управления пользовательского интерфейса, как Button , PictureBox , List View , TreeView , TabControl и так далее, и
- предоставить разработчикам возможность выполнения низкоуровневых операций рисования на мобильных устройствах с использованием расширенного набора операций для обработки растровых изображений, позволяющего рисовать такие, например, двумерные объекты, как линии, многоугольники, текст и изображения.
Описанные функциональные возможности предлагаются в двух иерархических пространствах имен:
Библиотеки XML
Почему XML придается настолько большое значение. Чтобы в этом разобраться, необходимо рассмотреть все "за" и "против" двух способов обмена данными между приложениями, использующих, соответственно, двоичный и текстовый форматы данных .
Обмен двоичными данными требует соблюдения всеми сторонами строгих договоренностей относительно способа форматирования и интерпретации данных. Двоичные форматы требуют тщательного планирования управления их версиями всеми сторонами, использующими эти форматы. Все это значительно снижает гибкость данного метода; любое изменение двоичного формата, которое предварительно не было согласовано со всеми сторонами, приведет к нарушению работы приложений, использующих эти данные. Как бы в качестве компенсации этого недостатка, двоичные форматы предлагают возможность более компактного представления данных. Тем самым обеспечивается снижение расхода памяти и увеличение скорости обработки данных.
Решение, которое традиционно обеспечивали текстовые файлы, совершенно противоположно по своему характеру: оно повышает гибкость взаимодействия между различными сторонами за счет использования более свободных договоренностей между ними и более подробного описания формата кодирования данных. В качестве метода хранения простых данных и организации обмена ими XML заменил традиционные текстовые файлы во многих областях применения. XML-файлы представляют собой обычные текстовые файлы, отличающиеся тем, что в них содержится дополнительная информация относительно собственной структуры. Это позволяет упростить их обработку стандартными способами и облегчает их повторное использование. Разработчики останавливают свой выбор на текстовых форматах по той причине, что с ними проще работать, ибо они более терпимы к изменениям схемы организации данных и облегчают учет специфики различных версий. XML поднимает текстовый способ хранения данных на более высокий уровень.
XML предлагает достижение разумного компромисса между чрезмерно сложным и чрезмерно упрощенным подходами к структуризации информации. Такое наполовину структурированное хранение данных обеспечивает значительные преимущества по сравнению с обычными текстовыми файлами. Данные сохраняются в иерархическом текстовом формате с использованием дескрипторов (tags), предоставляющих информацию о структуре содержимого. Например, информация о шрифте может быть сохранена посредством фрагмента текста ххх , который позволяет приложению, интерпретирующему текст, легко определить, что означает этот элемент данных. Приложения, работающие с XML-данными, могут выбирать лишь те порции текста, которые представляют для них интерес или смысл которых для них понятен. Таким образом, XML является важным усовершенствованием по сравнению с предыдущими текстовыми форматами, такими как файлы *.INI, контейнеры РгорertyBag или HTML-текст, так как обеспечивает одновременно и больший объем структурной информации, и большую гибкость.
Поскольку в настоящее время XML очень широко используется в качестве средства обмена информацией, наличие его поддержки является весьма важной характеристикой любой современной программной среды. Не будь ее, каждый разработчик был бы вынужден самостоятельно писать собственные наборы функций для синтаксического анализа текстовых файлов и извлечения или сохранения необходимых данных. Такое решение было бы крайне неэффективным и значительно увеличило бы вероятность появления в приложениях ошибок, которых можно было бы избежать. Поскольку большинство разработчиков заняты созданием приложений, а не синтаксических анализаторов, "самодеятельные" варианты реализации обычно способны выполнять то, что требуется, лишь в минимальном объеме и почти во всех случаях не подвергаются достаточно тщательному тестированию. Более того, в случае пользовательской реализации достижение максимальной производительности почти всегда приносится в жертву сокращению сроков разработки. В результате этого пользовательские варианты реализации оказываются, как правило, менее надежными и менее эффективными по сравнению с профессиональными решениями, предназначенными для широкого использования.
- Средства однонаправленного чтения и записи XML-документов. Для максимально быстрого выполнения однонаправленного (forward-only) чтения/записи XML-документов без применения кэширования используются классы XmlReader и XmlWriter. Задачей этих классов является чтение или запись XML данных соответственно из потоков или в потоки с поддержкой лишь минимально необходимого объема информации о состоянии. Этими возможностями могут воспользоваться разработчики, имеющие дело с XML-документами большого объема, когда на первый план выступает необходимость обеспечения высокой производительности приложений.
- XML DOM (Document Object Model - объектная модель документов). Класс XmlDocument используется для представления создаваемого в памяти дерева объектов, описывающего XML-документ. XmlDocument и связанные с ним классы представляют объектную модель документов, обеспечивающую легкий доступ к элементам представляемых деревьев XML. Документ считывается только в прямом направлении с использованием обсуждавшегося выше класса XmlReader , на основании чего создается дерево элементов, представляющее XML-документ в памяти. Аналогичным образом, данные из XML-дерева могут быть записаны в поток; для выполнения этой задачи используется класс XmlReader . Возможности класса XmlDocument больше всего подходят тем разработчикам, которые либо имеют дело с XML-документами небольших или средних размеров, либо хотят вносить как можно меньше усложнений при работе с XML-документами.
Концептуально соответствующая функциональность представлена в пространстве имен System. Xml. * .
Библиотеки данных
Как запускается и выполняется код
При первоначальном запуске приложения на основе управляемого кода загрузка, верификация и запуск кода осуществляются за несколько шагов. Когда такое приложение уже запущено и выполняется, среда выполнения управляемого кода продолжает играть важную роль во время загрузки новых классов и JIT-компиляции кода, когда это оказывается необходимым, а также в процессе управления памятью, отводимой для приложения. Полезно иметь более или менее полное общее представление о том, как все это происходит. Процесс запуска и выполнения приложения можно пояснить при помощи описанных ниже шести шагов:
- Загружается управляемое приложение. Двоичный заголовок приложения указывает операционной системе на то, что оно не является приложением в собственных кодах. Вместо того чтобы просто предоставить возможность выполняться инструкциям кода, загружается исполнительный механизм .NET Compact Framework, которому сообщается о том, что он должен запустить приложение на выполнение.
- Исполнительный механизм находит класс, содержащий "главную" точку входа "main", с которой должно начинаться выполнение приложения. Таковым является класс с сигнатурой функции, соответствующей виду static void Main() . В случае обнаружения типа с такой сигнатурой происходит загрузка класса и производится попытка выполнения "главной" процедуры (шаги 3 и 4).
- Загружается класс. Информация о классе загружается и верифицируется с той целью, чтобы убедиться в корректности и согласованности определения класса. Все методы (то есть точки входа исполняемого кода) класса обозначаются как "некомпилированные".
- Исполнительный механизм пытается выполнить указанную процедуру. Если уже имеется откомпилированный код, связанный с процедурой, осуществляется выполнение этого кода.
- Если исполнительный механизм обнаруживает, что свойство или метод, которые требуется запустить на выполнение, не откомпилированы, они компилируются по требованию. Производится загрузка содержащейся в классе информации, которая необходима методу. Код верифицируется для гарантии того, что он содержит безопасные, допустимые и корректно сформированные IL-инструкции, а затем подвергается JIT-компиляции. Если метод ссылается на другие типы, которые еще не были загружены, осуществляется необходимая загрузка определений соответствующих классов и типов. Методы, содержащиеся в классах, не компилируются до тех пор пока в этом не возникнет необходимости; именно в этом и состоит смысл JIT-компиляции.
- Выполняется скомпилированный к этому моменту метод. Если возникает необходимость в распределении памяти для типов или методов, исполнительному механизму направляются соответствующие запросы. Любые вызовы классов методами возвращают нас к шагу 5.
На первый взгляд, вышеперечисленные действия требуют выполнения большого объема работы, однако в действительности все происходит очень быстро.
Еще одно превосходное новшество Visual Studio 2008 - возможность работать с несколькими версиями . NET Framework. В предшествующих версиях Visual Studio можно строить программный код только для текущей версии среды выполнения . NET , а Visual Studio 2008 охватывает . NET Framework 2.0, 3.0, 3.5 и . NET Compact Framework. Текущая целевая версия . NET Framework отображается в раскрывающемся окне в левом верхнем углу на экране 2. Следует отметить, что при работе со старой версией . NET Framework происходит лишь изменение выполняемых файлов, подготовленных в Visual Studio 2008. При этом файлы проектов Visual Studio 2008 несовместимы с предыдущими версиями Visual Studio .
Заключение
. NET Compact Framework представляет собой богатую своими возможностями среду времени выполнения управляемого кода для мобильных устройств, пригодную для создания самых различных приложений, компонентов и каркасов приложений. Она с самого начала предназначалась для использования на устройствах, характеризующихся ограниченными ресурсами, но с самого начала проектировалась как совместимое на уровне двоичного кода подмножество платформы . NET Framework, ориентированной на настольные компьютеры и серверы. Подобно другим средам выполнения управляемого кода . NET Compact Framework включает в себя механизм выполнения собственных кодов и набор библиотек классов выполняющегося поверх него управляемого кода. Были применены стратегии проектирования, специально предназначенные для мобильных и встроенных устройств, что позволило обеспечить предоставление широкого подмножества функциональности платформы . NET Framework и одновременно учесть специфику требований мобильных устройств в отношении размеров и производительности приложений.
если исключить тех, кто на зарплате, т.е. инженеров Microsoft/Mono/Xamarin, их очень немного.
Как только список был готов, я залез в Википедию (см. список источников). В результате получилась следующая хронологическая последовательность:
Timeline maker
(Для интерактивной версии пройдите по ссылке)
Если я пропустил какие-то среды выполнения, дайте знать.
Чтобы облегчить восприятие хронологии, я поместил каждую среду в одну из следующих категорий:
Оставшаяся часть поста посвящена детальному описанию разных сред выполнения. Почему они появились, что они могут и зачем их сравнивать.
Другие среды выполнения Microsoft
Silverlight
Несмотря на то что платформа находится в режиме поддержки (или вообще умерла/движется к закату в зависимости от вашей точки зрения), интересно вернуться к первоначальному анонсу и посмотреть, для чего предназначалась Silverlight:
В 2007 г. в Silverlight 1.0 были реализованы следующие возможности (платформа даже работала на Linux):
- поддержка встроенных кодеков для проигрывания видеофайлов VC-1 и WMV, а также аудиофайлов в форматах MP3 и WMA в браузере. ;
- Silverlight поддерживает возможность постепенного скачивания и проигрывания медиаконтента с любого веб-сервера…;
- Silverlight также опционально поддерживает встроенную потоковую передачу медиафайлов…;
- с помощью Silverlight вы можете создавать многофункциональные пользовательские интерфейсы и анимацию, соединять векторную графику и HTML для создания привлекательного контента. ;
- Silverlight облегчает создание насыщенного интерактивного видеоконтента.
Также, как подсказали в комментах, Silverlight был и на Symbian S60
Среды выполнения Mono/Xamarin
Для меня неважно, кто был первым, потому что я считаю Mono средством достижения цели: технологией, которая поможет Linux закрепиться на настольных компьютерах.
В этом же посте описано, как всё началось:
Проекты сообществ
Исследовательские проекты
Shared Source Common Language Infrastructure (SSCLI) (или Rotor)
Midori
Midori – кодовое имя операционной системы с управляемым кодом, которая разрабатывалась Microsoft совместно с Microsoft Research. Сообщалось, что она может стать коммерческой реализацией операционной системы Singularity, исследовательского проекта, начатого в 2003 г. для создания высоконадёжной операционной системы, в которой ядро, драйвера устройств и приложения состоят из управляемого кода. Она проектировалась для параллельных вычислений и могла запускать программу, распределённую по нескольким узлам одновременно. В ней так же была реализована модель безопасности на основе запуска приложений в изолированной среде. Microsoft предложила несколько возможных путей миграции с Windows на Midori. Работа над операционной системой была прекращена в 2015 году, хотя многие реализованные в ней идеи попали в другие проекты Microsoft.
Singularity (операционная система) (также Singularity RDK)
Singularity – экспериментальная операционная система, которая разрабатывалась Microsoft Research между 2003 и 2010 гг. Предполагалось, что это будет высоконадёжная операционная система, в которой ядро, драйвера устройств и приложения состоят из управляемого кода. Средства внутренней безопасности используют безопасность типов вместо аппаратной защиты памяти.
Redhawk
И последняя, но не менее важная среда – Redhawk:
кодовое название для экспериментальной, минимальной версии среды выполнения с управляемым кодом, которая превратилась в CoreRT.
Ссылки на источники
Ниже приведены статьи Википедии, которые я использовал для создания хронологической шкалы:
Нашлись ещё варианты
Net60
В комментариях bmforce подсказал, что была ещё одна платформа, Net60. Информации о ней не так много, но удалось найти упоминание на форуме + статья на CodeGuru:
Moonlight
Не упоминается Moonlight, который основан на Mono — Opensource версию Silverlight:
Moonlight — это open source реализация Silverlight, сделанная в основном для Linux и других Unix/X11 операционных систем. Последний релиз Moonlight (Moonlight 4 Preview 1) предоставляет поддержку основного набора возможностей Silverlight 3, плюс совместимость с Silverlight 4.
Blazor
PageFX
Конечно, в самой идее предлагать специализированный набор возможностей, удовлетворяющих определенными потребностям, нет ничего плохого. Это становится проблемой, когда отсутствует системный подход и специализация происходит на каждом слое без учета того, что происходит в соответствующих слоях других вертикалей. Последствием таких решения является набор платформ, которые имеют ряд общих API только потому, что они когда-то начинались из единой базы кода. Со временем, это приводит к росту различий, если только не проводить явные (и дорогие) упражнения для достижения единообразия API.
В какой момент возникает проблема с фрагментацией? Если вы нацелены только на одну вертикаль, то в реальности никакой проблемы нет. Вам предоставлен набор API, оптимизированный именно для вашей вертикали. Проблема проявляет себя, как только вы хотите делать что-то горизонтальное, ориентированное на множество вертикалей. Вот теперь вы задаетесь вопросом о доступности различных API и думаете, как производить блоки кода, которые работали бы на разных целевых вертикалях.
Рождение переносимых библиотек классов (Portable Class Library, PCL)
К моменту выхода Windows 8 мы пришли к плану, как бороться с этой проблемой. Когда мы проектировали профиль Windows Store, мы ввели новую концепцию для лучшего моделирования подмножества: контракты.
Идея контрактов заключается в том, чтобы предоставить продуманный набор API, подходящих для задач декомпозиции кода. Контракты – это просто сборки, под которые вы можете компилировать свой код. В отличие от обычных сборок, сборки контрактов спроектированы именно под задачи декомпозиции. Мы четко прослеживаем зависимости между контрактами и пишем их так, чтобы они отвечали за что-то одно, а не были свалкой API. Контракты имеют независимую версионность и следуют соответствующим правилам, например, если добавляется новый API, то он будет доступен в сборке с новой версией.
Сегодня мы используем контракты для моделирования API во всех вертикалях. Вертикаль может просто взять и выбрать, какие контракты она будет поддерживать. Важным моментом является то, что вертикаль обязана поддерживать контракт целиком или не поддерживать вовсе. Другими словами, она не может включить в себя подмножество контракта.
Это позволяет говорить о различиях в API между вертикалями уже на уровне сборок в отличие от индивидуальных различиях в API, как это было раньше. Это позволяет нам реализовать механизм библиотек кода, которые нацелены на множество вертикалей. Такие библиотеки сегодня известны как переносимые библиотеки классов (portable class libraries).
Объединение формы API против объединения реализаций
Намного лучше унифицировать реализации: вместо того, чтобы только предоставлять хорошо декомпозированное описание, мы должные подготовить декомпозированную реализацию. Это позволит вертикалям просто использовать одну и ту же реализацию. Сближение вертикалей больше не будет требовать дополнительных действий; оно достигается просто за счет правильного конструирования решения. Конечно все равно будут случаи, в которых необходимы различные реализации. Хороший пример этого – это файловые операции, требующие использования разных технологий в зависимости от окружения. Однако, даже в этом случае намного проще попросить каждую команду, отвечающую за конкретные компонент, подумать, как из API будут работать в разных вертикалях, чем постфактум пытаться предоставить единый набор API поверх. Переносимость – это не есть что-то, что вы можете добавить после. К примеру, наш File API включает поддержку Windows Access Control Lists (ACL), которые не поддерживаются всем окружениями. При дизайне API нужно учитывать такие моменты и, в частности, предоставлять подобную функциональность в отдельных сборках, которые могут отсутствовать на платформах, не поддерживающих ACL.
Фреймворки для всей машины против локальных фреймворков для приложения
- Централизованное обслуживание
- Уменьшает размер требуемого места на диске
- Позволяет разделять нативный код между приложениям
- Добавление интерфейса к существующему типу может нарушить работу приложений, так как это может повлиять на то, как тип сериализуется.
- Добавление перегрузки к методу, который раньше не имел любых перегрузок может нарушить работу с рефлексиями в тех случаях, когда в коде не обрабатывается вероятность найти более, чем один метод.
- Переименование внутреннего типа может нарушить приложения, если имя типа определялось через метод ToString().
Это все очень редкие случаи, но, когда у вас пользовательская база в 1.8 миллиарда машин, быть совместимым с 99.9% по-прежнему означает, что 1.8 миллиона машин затронуто.
Такой подход в общем-то почти полностью снимает все проблемы, мешающие вам обновиться до свежей версии. Ваши возможности перейти на новую версию ограничены только вашей возможностью выпустить новую версию вашего приложения. Это также означает, что вы контролируете, какая версия библиотеки используется конкретным приложением. Обновления производятся в контексте одного приложения, никак не затрагивая другие приложения на той же машине.
Это позволяет выпускать обновления в гораздо более гибкой манере. NuGet также предлагает возможность попробовать предварительные версии, что позволяет нам выпускать сборки без строгих обещаний относительно работы конктретных API. Такой подход позволяет нам поддерживать процесс, в котором мы предлагаем вам наш свежий взгляд на дизайн сборки – и, если вам не нравится, просто его изменить. Хороший пример это – это неизменяемые коллекции (immutable collections). Бета-период длился порядка 9 месяцев. Мы потратили много времени, пытаясь добиться правильного дизайна прежде, чем выпустить первую версию. Нет необходимости говорить, что финальная версия дизайна библиотеки, — благодаря вашим многочисленным отзывам, — намного лучше, чем начальная.
NuGet как первоклассный механизм доставки
Для слоя BCL у нас будет прямое соответствие между сборками и пакетами NuGet.
В дальнейшем NuGet-пакеты будут иметь те же имена, что и сборки. К примеру, неизменяемые коллекции перестанут распространяться под именем Microsoft.Bcl.Immutable и вместо этого будут в пакет, называющемся System.Collections.Immutable.
В дополнение, мы решили использовать семантический подход для версионности сборок. Номер версии NuGet-пакета будет согласован с версией сборки.
Согласованность именования и версионности между сборками и пакетами сильно облегчит их поиск. У вас не должно возникнуть вопроса, в каком пакете содержится System.Foo, Version=1.2.3.0 – он находится в пакете System.Foo с версией 1.2.3.
Готов для корпоративного использования
Основа для открытого кода и кросс-платформенности
Из прошлого опыта мы знаем, что успех открытого кода зависит от сообщества вокруг него. Ключевой аспект этого – это открытый и прозрачный процесс разработки, который позволит сообществу участвовать в ревью кода, знакомиться с документам по проектированию и вносить свои изменения в продукт.
Конечно, отдельные компоненты, например, файловая система, требуют отдельной реализации. Модель доставки через NuGet позволяет нам абстрагироваться от этих различий. Мы можем иметь единый NuGet-пакет, предоставляющий различные реализации для каждого из окружений. Однако важный момент тут как раз в том, что это внутренняя кухня реализации компонента. С точки зрения разработчика это единый API, который работает на разных платформах.
Наличие всех трех элементов позволяет нам добиться широкого спектра гибкости и зрелости решений:
Нам кажется, что мы нашли хороший баланс между тем, чтобы заложить основу для будущего, сохраняя при этом хорошую совместимость с существующими стеками. Давайте посмотрим детальнее на часть из этих платформ.
Windows Store и Windows Phone
Более детально выбор между двумя подходами описан в статье «Sharing code across platforms».
Итоги
На нас лежит ответственность за продолжение выпуска критичных обновлений безопасности, не требующих работы со стороны разработчиков приложений, даже если затрагиваемые компоненты распространятся эксклюзивно как NuGet-пакеты.
А вот и другие наши статьи по схожей тематике:
Читайте также: