Путь Microsoft Teams к .NET Core

Область этой миграции велика, поскольку MiddleTier — служба очень большого размера в аспекте предоставляемой функциональности благодаря сотням разработчиков, которые ежедневно трудятся над ней.

Мотивация миграции

Команда была заинтересована в переходе на .NET Core 3.1 по следующим причинам:

• Повышение производительности и экономической эффективности
• Платформа .NET Framework 4.6.2, видимо, скоро будет выведена из употребления
• Кроссплатформенная поддержка
• Переход на современную платформу для лучшего взаимодействия с разработчиком

Преимущества после перехода на .NET Core 3.1

После перехода на .NET Core 3.1 команда заметила следующие улучшения:

• Улучшение ЦП на 25%
• Сокращение затрат на инфраструктуру примерно на 25%
• Улучшено использование пула потоков
• Сокращение технического долга и усилий по переходу на ежегодные выпуски .NET.

На следующих диаграммах показано сравнение между .NET Framework и .NET Core. В будущем, с .NET 6, мы должны увидеть еще больше улучшений.

Подход

Общая миграция была разделена на три этапа:

Они также выбрали многоцелевое приложение для .NET Framework и .NET Core, чтобы у них были доступны оба двоичных файла, и они могли продолжать медленное развертывание .NET Core.

Обучение

OData и другие REST API не могут совместно использовать префикс маршрута

Их служба также имеет несколько конечных точек OData и множество конечных точек REST. Эти двое используют один и тот же префикс маршрутизации для конечных точек. Раньше это нормально работало в .NET Framework, но из-за изменений маршрутизации перестало работать в .NET Core. Чтобы решить эту проблему, им пришлось переместить API-интерфейсы OData на другой префикс маршрута.

Проблемы производительности с клиентскими библиотеками OData

The HttpWebRequest pattern with OData clients to make calls to downstream OData APIs results in higher latency compared to .NET Framework. This was due to a regression in .NET Core in which the framework doesn't cache connections. This is already resolved in newer versions of .NET.

Проблемы с пакетами SDK служебной шины Azure

The Azure Service Bus SDK had to be upgraded as part of this migration since the old version isn't .NET Standard compatible. The latest version of the Azure Service Bus SDK sends the request payload in JSON format whereas the older SDK sends the payload in XML format. To continue using XML payload, they had to use the DataContractSerializer.

Проблемы в проекте Service Fabric для множественного таргетинга

Проект Service Fabric (sfproj) по своей сути не поддерживает множественное нацеливание. Им пришлось использовать обходные пути в конвейере сборки, чтобы создать пакеты Service Fabric для обеих целевых платформ.

Проблемы со старой версией MimeKit NuGet

The older version of MimeKit can have issues with double byte characters, thus language specific validation is advised in this scenario. They uncovered similar issues when they rolled out to deployments located in Asian geography.

Классические особенности ASP.NET

• Пришлось отказаться от использования некоторых классов .NET Framework, которые были помечены как внутренние в .NET Core.
• MVC async suffix dropped from action names as mentioned in the ASP.NET Core breaking changes for versions 3.0 and 3.1 article. If any of the code paths are dependent on the action name, it can cause a change in behavior.
• Synchronous IO operations are by default turned off on all servers starting in .NET Core 3.0 as mentioned in the dotnet/aspnetcore#7644 GitHub issue.
• Заголовок Content-Length не задан в Content.Headers при отправке StreamContent в виде содержимого HTTP-запроса. Это может привести к ошибкам от нижестоящих вызовов.
• Платформа .NET создает стабильный хэш-код для строки, а .NET Core — нет.
• The Required attribute from the System.ComponentModel.DataAnnotations namespace behaves differently in .NET Core. On .NET Framework, this attribute doesn't do any model validation for non-null fields but on .NET Core it does.