SDK тебе, SDK мне, SDK всем! Как делать SDK и зачем это нужно

[lelik363]

На картинке настоящий ящик с инструментами?

[Liudar]

Да, созданный мастером по изготовлению пианино и фортепиано Генри Стадли. Очень функциональный, подходящий как для грубых работ по дереву, так и тонкой настройки. Оригинал

[Liudar]

Спасибо, поправил

[gdt]

Ещё бывает полезно предоставлять варианты метода с выбрасыванием исключений и с кодом ошибки, грубо говоря:

public CoolResult DoSomethingCool(...); // кидает исключение
public bool TryDoSomethingCool(..., out CoolResult result); // возвращает флаг

Ещё желательно позаботиться об обработке unhandled exceptions (отовсюду, в шарпах это значит, что надо ловить и AppDomain.CurrentDomain.UnhandledException, и TaskScheduler.UnobservedTaskException, и Dispatcher.UnhandledException) или хотя бы предоставить в SDK такую возможность, это несложно и очень упрощает жизнь.

Опять же, если пишете на C# — надо продумать всё, что связано с контекстом, и определить правила, которых вы будете придерживаться. Например, мы у себя не используем ConfigureAwait(false) по ряду причин, и для гарантированного переключения контекста у нас есть специальная небольшая структура.

Также, если у вас есть асинхронный код (а это скорее всего так), и вы его передаёте в диспетчер или Task.Run — лучше сразу позаботиться о том, чтобы в случае чего вы получили грамотный call stack, а не обрывок.

Если у вас большой solution, удобно использовать файл Directory.Build.props для задания свойств и действий, которые будут применяться ко всем проектам — например, вы можете через этот файл подключить один AssemblyInfo.cs ко всем проектам, а также настроить CodeAnalysis и StyleCop в одном месте. Если надо будет на время отключить стайлкоп — достаточно поправить один файл, то же касается версий и т.д.

[Liudar]

Очень содержательно, спасибо!
Про Unhandled и Aggregate Exceptions стоило упомянуть, спасибо, что дополнили. Про управление задачами и контекстами — это касается всех многопоточных приложений, в статье же речь только о SDK, но тут тоже очень в тему. Про комплексную сборку тоже очень дельный совет.

[gdt]

Да, но дело в том, что если вы пишете библиотечный код, то обычно не можете знать, в каком контексте он будет вызван. Обычная рекомендация — добавлять везде .ConfigureAwait(false), но эта конструкция семантически некорректна, и очень легко забыть написать её в каком-то одном месте, и получить дедлок у клиента.