Все приложения .NET зависят от классов и методов из библиотеки базовых классов (BCL) как часть их реализации — Strings, System.Console, System.IO.Path, System.Net.Http.HttpClient и т. д.

При работе со многими платформами, такими как Xamarin.iOS или настольная консоль, выбор библиотеки BCL для компоновки, как правило, является фиксированным, и здесь нечего учитывать. С Xamarin.Mac все не так просто, поскольку он поставляется с двумя различными поддерживаемыми целевыми платформами, а также допускает неподдерживаемое связывание с системным моно. Чтобы понять, как появились три варианта и почему они переименовываются, сначала потребуется небольшой урок истории.

Осень 2014 г. — выпущена версия Xamarin.Mac 1.10, включающая предварительную версию нового «унифицированного» профиля. Этот единый профиль позволял:

  • Устранение ряда системных проблем, препятствующих поддержке 64-битной версии.
  • Унификация пространств имен, которая вызывала значительные затруднения при совместном использовании кода между проектами Xamarin.Mac и Xamarin.iOS.
  • Множество улучшений API, несовместимых с предыдущими версиями.

В отличие от классической версии, созданной на основе установленной моносистемы, копия BCL была включена в платформу Xamarin.Mac для унифицированной версии. Это уменьшило потребность в одновременном обновлении моно и Xamarin.Mac. Поскольку этот переход с классической версии на унифицированную был нарушением работы API, этот BCL был основан на модифицированной версии версии Xamarin.iOS. Он был значительно тоньше, и, поскольку он не включал System.Configuration, можно было безопасно включить связывание в качестве опции, что значительно уменьшило окончательный размер приложения за счет удаления мертвого кода из встроенных библиотек и самого приложения.

Вскоре после выхода версии 1.10 на форуме появились сообщения и отчеты об ошибках, описывающие боль, с которой сталкиваются пользователи, пытаясь перенести свои приложения на унифицированную версию. Многие приложения зависели от пакетов nuget или других сторонних библиотек, созданных на основе обычного «настольного» BCL. Убедить сопровождающих библиотек добавить дополнительную сборку для этой новой унифицированной цели Mac во всей экосистеме nuget оказалось задачей уровня «вскипятить океан».

Был добавлен краткосрочный бинт, позволяющий привязываться к системному моно (как это делала классика), но мы знали, что для 2.0 нам нужна лучшая история, и быстрая. Он должен был быть как можно более совместимым с широким спектром пакетов nuget, которые использовали клиенты, но главной целью по-прежнему было сокращение поверхности библиотеки. Некоторые уголки библиотеки моноклассов имели только частичные реализации или часто имели критические изменения. Удаление их из «поддерживаемого» BCL помогло предотвратить зависимость клиентов от одной из этих библиотек, сбои в работе после обновления, а затем чувство оправданного разочарования.

Результатом стала целевая платформа Xamarin.Mac 4.5 (XM 4.5). Он урезал стандартный настольный монопрофиль net_4_5 и сделал несколько творческих искажений правды в msbuild, чтобы убедить всех, что это действительно настольная BCL, которую все знали и любили.

Это не было идеальным решением, и искажение правды вернулось и вызвало ряд проблем, которые нужно было искоренить, но в целом это был успех.

Но как только у нас появилась целевая платформа XM 4.5, нам понадобилось имя для изначально разработанной. Поскольку он работал на тех же битах, что и Xamarin.iOS, название «Мобильный» казалось логичным.

Начиная с Xamarin.Mac 2.0 несовершенство двух названий становится все более очевидным. Клиенты, как правило, уклоняются от мобильных устройств, когда видят это диалоговое окно, поскольку они «создают десктопное приложение, зачем тогда мобильное». XM 4.5 теперь поддерживает сборки с API .NET 4.6, и с течением времени это имя будет все больше и больше не соответствовать действительности. Монопрофиль, на котором он был основан, теперь называется net_4_x по определенной причине.

Именование — одна из двух больших сложных проблем в информатике (наряду с аннулированием кеша и ошибками off by one), и потребовалось несколько долгих дискуссий и потоков электронной почты, чтобы выбрать наименее плохие предложенные имена.

Запланированные новые имена и описания:

  • Modern (оптимизированный профиль, также поддерживающий Xamarin.iOS) заменяет Mobile.
  • Полная (совместимость с расширенным API рабочего стола) заменяет XM 4.5.

Поскольку внедрение netstandard продолжает распространяться в сообществе nuget, ожидается, что многие приложения смогут перейти на целевую платформу Modern. Однако целевая платформа Full будет по-прежнему доступна, когда требуется расширенная поверхность библиотеки Full (например, System.Configuration).