День 1782. #ЧтоНовенького
Помечаем Экспериментальные API Атрибутом Experimental
При написании библиотек и фреймворков, которые используют другие, иногда нужно сообщить клиентам, что данный API по-прежнему считается «экспериментальным». Например, предоставить другим возможность работать с частью кода, оставив для себя возможность что-то ломать. В C# 12 это можно сделать с помощью ExperimentalAttribute.
Например, в JetBrains Space SDK есть метод MapSpaceAttachmentProxy, который пока является экспериментальной функцией:
Сборка проекта, использующего этот метод, по умолчанию завершается неудачей с ошибкой “Error SPC101: ‘MapSpaceAttachmentProxy(…)’ is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.” (Ошибка SPC101: 'MapSpaceAttachmentProxy(…)' предназначен только для ознакомительных целей и может быть изменён или удалён в будущих обновлениях. Подавите эту диагностику, чтобы продолжить.)
Также с помощью свойства UrlFormat в атрибут можно добавить URL, где люди смогут найти дополнительную информацию об API. Здесь заместитель {0} MSBuild заменит диагностическим идентификатором:
Вы можете подавить диагностику экспериментальных атрибутов в файле проекта, добавив свойство <NoWarn>:
Либо с помощью директивы pragma в коде:
Что делать в старых версиях языка?
Как вариант, можно использовать атрибут Obsolete. Хотя он по умолчанию отображается только как предупреждение, но, по крайней мере, это будет видно в журнале сборки. Начиная с .NET6, вы также можете добавить к атрибуту диагностический идентификатор, давая людям возможность подавить сообщение, если они согласны использовать этот экспериментальный API:
Источник: https://blog.maartenballiauw.be/post/2023/11/08/opt-in-to-experimental-apis-using-csharp-12-experimentalattribute.html
Помечаем Экспериментальные API Атрибутом Experimental
При написании библиотек и фреймворков, которые используют другие, иногда нужно сообщить клиентам, что данный API по-прежнему считается «экспериментальным». Например, предоставить другим возможность работать с частью кода, оставив для себя возможность что-то ломать. В C# 12 это можно сделать с помощью ExperimentalAttribute.
Например, в JetBrains Space SDK есть метод MapSpaceAttachmentProxy, который пока является экспериментальной функцией:
using System.Diagnostics.CodeAnalysis;
public static class SpaceMapAttachmentProxyExtensions
{
[Experimental("SPC101")]
public static IEndpointConventionBuilder
MapSpaceAttachmentProxy(
this IEndpointRouteBuilder endpoints,
string path)
{
//…
}
}
Сборка проекта, использующего этот метод, по умолчанию завершается неудачей с ошибкой “Error SPC101: ‘MapSpaceAttachmentProxy(…)’ is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to proceed.” (Ошибка SPC101: 'MapSpaceAttachmentProxy(…)' предназначен только для ознакомительных целей и может быть изменён или удалён в будущих обновлениях. Подавите эту диагностику, чтобы продолжить.)
Также с помощью свойства UrlFormat в атрибут можно добавить URL, где люди смогут найти дополнительную информацию об API. Здесь заместитель {0} MSBuild заменит диагностическим идентификатором:
[Experimental("SPC101", UrlFormat = "https://www.example.com/diagnostics/{0}.html")]Вы можете подавить диагностику экспериментальных атрибутов в файле проекта, добавив свойство <NoWarn>:
<Project Sdk="Microsoft.NET.Sdk.Web">
<!-- ... -->
<PropertyGroup>
<NoWarn>SPC101</NoWarn>
</PropertyGroup>
</Project>
Либо с помощью директивы pragma в коде:
#pragma warning disable SPC001
Что делать в старых версиях языка?
Как вариант, можно использовать атрибут Obsolete. Хотя он по умолчанию отображается только как предупреждение, но, по крайней мере, это будет видно в журнале сборки. Начиная с .NET6, вы также можете добавить к атрибуту диагностический идентификатор, давая людям возможность подавить сообщение, если они согласны использовать этот экспериментальный API:
[Obsolete("'MapSpaceAttachmentProxy(...)' is for evaluation purposes only and is subject to change or removal in future updates. Suppress this diagnostic to remove this warning.", DiagnosticId = "SPC101")]Источник: https://blog.maartenballiauw.be/post/2023/11/08/opt-in-to-experimental-apis-using-csharp-12-experimentalattribute.html
👍11
День 1974. #ЗаметкиНаПолях
Согласованные и Воспроизводимые Сборки с Помощью global.json. Начало
Том, .NET-разработчик, только что завершил реализацию новой функции в приложении ASP.NET Core. На его машине всё работает отлично, и он отправляет код в пул-реквест. Однако в CI-конвейере сборка завершается неудачей из-за ошибки IDE0100. Не понимая причину проблемы, Том просит помощи у своего коллеги Брайана, которому удаётся её воспроизвести.
Под давлением сроков Том и Брайан не тратят время на то, чтобы выяснить, почему ошибка не появляется на машине Тома. Они решают отключить ошибку с помощью директивы #pragma, и PR успешно создаётся. Через несколько минут приложение успешно развёртывается в рабочей среде.
Вроде бы всё кончается хорошо, но это не так. Если бы Том и Брайан потратили время на более внимательное изучение ситуации, они бы обнаружили несколько нарушений в процессе сборки приложения. Вот что произошло на самом деле.
Том использует версию 8.0.200 SDK для .NET, а Брайан — версию 8.0.204. Заинтересовавшись новыми возможностями .NET 9, Брайан также установил предварительную версию 9.0.100-preview.4. Конвейер CI, размещенный в Azure DevOps, использует задачу UseDotNet@2 для установки версии SDK 8.x, включая предварительные версии.
Ошибка IDE0100 появилась в тот день, когда Microsoft выпустили SDK версии 8.0.300. В этой версии представлено исправление, изменяющее поведение анализатора Roslyn IDE0100. Том, использующий более раннюю и уязвимую версию .NET 8 SDK, не пострадал. Однако Брайан скомпилировал приложение с помощью SDK предварительной версии .NET 9, которая включала это новое поведение.
Ирония в том, что приложение развёртывается в контейнере, а в качестве базового образа используется mcr.microsoft.com/dotnet/sdk:8.0.100, первой версии пакета SDK для .NET 8, выпущенной в ноябре 2023 года. Эта версия содержит несколько известных уязвимостей и больше не отображается в Docker Hub.
Какие выводы можно сделать из этой истории, вдохновлённой реальными событиями:
1. Команда Тома и Брайана не реализовала механизм, гарантирующий, что версия .NET SDK, используемая для компиляции приложения, одинакова на всех машинах.
2. Их поведение CI может измениться без предварительного уведомления, поскольку Microsoft выпускает новые предварительные версии SDK.
3. Версии SDK, содержащие уже исправленные уязвимости, по-прежнему используются как на машинах разработчиков, так и в производстве.
Этой ситуации можно избежать, явно указав необходимую версию .NET SDK для компиляции приложения. В продолжении рассмотрим, чем отличаются версии SDK и как использовать необходимую версию с помощью файла global.json.
Продолжение следует…
Источник: https://anthonysimmon.com/automate-dotnet-sdk-updates-global-json-renovate/
Согласованные и Воспроизводимые Сборки с Помощью global.json. Начало
Том, .NET-разработчик, только что завершил реализацию новой функции в приложении ASP.NET Core. На его машине всё работает отлично, и он отправляет код в пул-реквест. Однако в CI-конвейере сборка завершается неудачей из-за ошибки IDE0100. Не понимая причину проблемы, Том просит помощи у своего коллеги Брайана, которому удаётся её воспроизвести.
Под давлением сроков Том и Брайан не тратят время на то, чтобы выяснить, почему ошибка не появляется на машине Тома. Они решают отключить ошибку с помощью директивы #pragma, и PR успешно создаётся. Через несколько минут приложение успешно развёртывается в рабочей среде.
Вроде бы всё кончается хорошо, но это не так. Если бы Том и Брайан потратили время на более внимательное изучение ситуации, они бы обнаружили несколько нарушений в процессе сборки приложения. Вот что произошло на самом деле.
Том использует версию 8.0.200 SDK для .NET, а Брайан — версию 8.0.204. Заинтересовавшись новыми возможностями .NET 9, Брайан также установил предварительную версию 9.0.100-preview.4. Конвейер CI, размещенный в Azure DevOps, использует задачу UseDotNet@2 для установки версии SDK 8.x, включая предварительные версии.
Ошибка IDE0100 появилась в тот день, когда Microsoft выпустили SDK версии 8.0.300. В этой версии представлено исправление, изменяющее поведение анализатора Roslyn IDE0100. Том, использующий более раннюю и уязвимую версию .NET 8 SDK, не пострадал. Однако Брайан скомпилировал приложение с помощью SDK предварительной версии .NET 9, которая включала это новое поведение.
Ирония в том, что приложение развёртывается в контейнере, а в качестве базового образа используется mcr.microsoft.com/dotnet/sdk:8.0.100, первой версии пакета SDK для .NET 8, выпущенной в ноябре 2023 года. Эта версия содержит несколько известных уязвимостей и больше не отображается в Docker Hub.
Какие выводы можно сделать из этой истории, вдохновлённой реальными событиями:
1. Команда Тома и Брайана не реализовала механизм, гарантирующий, что версия .NET SDK, используемая для компиляции приложения, одинакова на всех машинах.
2. Их поведение CI может измениться без предварительного уведомления, поскольку Microsoft выпускает новые предварительные версии SDK.
3. Версии SDK, содержащие уже исправленные уязвимости, по-прежнему используются как на машинах разработчиков, так и в производстве.
Этой ситуации можно избежать, явно указав необходимую версию .NET SDK для компиляции приложения. В продолжении рассмотрим, чем отличаются версии SDK и как использовать необходимую версию с помощью файла global.json.
Продолжение следует…
Источник: https://anthonysimmon.com/automate-dotnet-sdk-updates-global-json-renovate/
👍22