diff --git a/input/Radio/Transcriptions/RadioDotNet-130.txt b/input/Radio/Transcriptions/RadioDotNet-130.txt
new file mode 100644
index 0000000..2d67be4
--- /dev/null
+++ b/input/Radio/Transcriptions/RadioDotNet-130.txt
@@ -0,0 +1,420 @@
+0.00 14.04 "Анатолий Кулаков" Приветствую вас, дорогие слушатели, в эфире Радио.нет выпуск номер 130, в студии его постоянный ведущий Анатолий Кулаков.
+14.04 16.20 "Игорь Лабутин" И Игорь Лабутин, всем привет.
+16.20 44.16 "Анатолий Кулаков" А за нашими спинами наши великолепные помогаторы Александр, Сергей, Владислав, Гурий Самарин, Александр Лапердин, Виктор, Руслан Артамонов, Сергей Бензенко, Шевченко Антон, Ольга Красавица Бондаренко, Сергей Краснов, Константин Ушаков, Постарнаков Андрей, Дмитрий Сорокин, Дмитрий Павлов, Александр Ерыгин, Егор Сычев, Гольдебаев Александр, Лазарев Илья, Тимофей, Виталий, Анатолий Крыжановский, Александр Гаранин, Евгений Асташев, Юрий Лодейкин, Котков Михаил и Михаил Королев.
+44.16 46.04 "Анатолий Кулаков" Спасибо всем, кто нас поддерживает, друзья.
+46.04 57.40 "Игорь Лабутин" В прошлых выпусках подкаста мы уже немного рассказывали, как данные о спортивных матчах попадают со стадионов в информационную систему Altenar и какие расчеты можно делать на их основе.
+57.40 60.88 "Игорь Лабутин" Все сервисы для этого существуют в рамках большого продукта Altenar DataFeed.
+60.88 67.24 "Игорь Лабутин" Но есть нюанс, DataFeed это по сути черный ящик, ведь у большей части его проектов нет своих пользовательских интерфейсов.
+67.24 72.72 "Игорь Лабутин" Поэтому одна из дотнет команд в компании разрабатывает админку, окошкой в мир DataFeed.
+72.72 79.72 "Игорь Лабутин" Ребята занимаются сбором и агрегацией событий со всего продукта, используя event sourcing, чтобы пользователь видел результирующее состояние системы.
+79.72 87.68 "Игорь Лабутин" Помимо отображения процессов, импорта, процессинга и маппинга данных, они постоянно дорабатывают возможности этого инструмента для B2B клиентов из разных стран.
+87.68 96.52 "Игорь Лабутин" В мире ежечасно проходят десятки и сотни матчей по разным видам спорта, клиентам компании хочется самим выбирать, какие данные из каких источников получать.
+96.52 103.40 "Игорь Лабутин" Для удобства ребята создают шаблоны, которые реализуют популярные кейсы и варианты импорта и экспорта данных, и допиливают тонкие настройки.
+103.40 108.80 "Игорь Лабутин" А еще автоматически подсвечивают матчи, в которых что-то может идти не так с точки зрения данных, и отправляют к группе мониторинга.
+108.80 113.40 "Анатолий Кулаков" Ну что ж, у нас сегодня есть интересные статейки.
+113.40 115.36 "Анатолий Кулаков" Кстати, ни одной новости про Aspire нет.
+115.36 126.00 "Анатолий Кулаков" Кстати, помнишь, что если сейчас везде хайпает или по крайней мере хайпал Aspire, то раньше, если вспомнить пару лет назад, у нас был другой хайп, это какой-нибудь Blazer.
+126.00 130.44 "Анатолий Кулаков" И Blazer не просто так, а под каким-нибудь соусом вебэсом были.
+130.44 131.44 "Анатолий Кулаков" Вот их давно как раз не было слышно.
+131.44 142.56 "Игорь Лабутин" Да, про Aspire, кстати, тут была какая-то микро-новость про то, что теперь это не .NET Aspire, а просто Aspire, и это нужно для того, чтобы был маркетинг в правильную сторону не только для .NET стека, а для всех остальных.
+142.56 149.34 "Игорь Лабутин" Там это было буквально какой-то коротенькой новостью, и в общем, поэтому мы не будем на этом сильно останавливаться, а вот про вебэсэмбли поговорим поподробнее.
+149.34 165.84 "Игорь Лабутин" В блоге Unoplatform вышла довольно большая статья под названием The State of WebAssembly 2025-2026, то есть что происходило и происходит с вебэсэмбли, ну и какие планы есть с точки зрения прошедшего года и наступившего.
+165.84 167.32 "Игорь Лабутин" И давайте разберемся.
+167.32 183.20 "Игорь Лабутин" Для начала вспомним, что вебэсэмбли это штука, которая позволяет запускать код в браузере, причем не только джейлоскриптовый, а в общем-то любой код, который будет готов скомпилироваться в специальной вебэсэмбли инструкции.
+183.20 197.32 "Игорь Лабутин" И естественно, у нас есть, ну все знают браузеры там Chrome, Firefox, Safari, есть еще Edge и Opera, но они по сути, поскольку основаны на Chromium, то в общем можно в рамках сегодняшнего обсуждения считать их тоже Chrome.
+197.32 213.44 "Игорь Лабутин" И по большому счету так получается, что именно поддержка Safari определяет, насколько та или иная фича готова к такому большому продуктовому использованию, потому что правило, ну видимо так получается, Safari типа последний всегда.
+213.44 216.56 "Игорь Лабутин" Вот, да, пиливает все свои фичи.
+216.56 220.00 "Игорь Лабутин" Значит, что же происходило в 25-м году?
+220.00 249.84 "Игорь Лабутин" Ну есть там прямо в статье отдельный раздел про критические апдейты от Safari, про exception handling, поддержку нового XnRef и для JavaScript API, там были некоторое количество багов, в JavaScript стринговые built-in функции в Safari 26.2 и всякие улучшения рантайма, поддержка JIT-less так называемого режима, то есть без JIT-а, более быстрое исполнение больших модулей и так далее.
+249.84 260.24 "Игорь Лабутин" Дальше идет, видимо это позволило всякие вот эти фичи затащить более-менее в основу, в production, грубо говоря в WebAssembly, по всем браузерам.
+260.24 271.44 "Игорь Лабутин" Собственно это позволило дойти до так называемой фазы 5, для standardized features, face 5 соответственно.
+271.44 290.56 "Игорь Лабутин" Там есть поддержка обработки исключений с помощью той самой вот механизма XnRef, очень странная такая, даже не английское слово, но видимо это какая-то плюс-минус аббревиатура, очень сложно ее произносить, и там была поддержка, сделана поддержка 64-битного режима, так называемой memory64.
+290.56 328.60 "Игорь Лабутин" Единственное, у него есть некоторая тонкость, если вы надеетесь, что теперь вы можете в браузере сделать в WebAssembly, с которой жжет дофига памяти, ну потому что 64-биты, вы можете использовать любое количество памяти, но на самом деле нет, во-первых браузеры ограничивают вас 16 гигабайтами, больше нельзя даже в 4-битном режиме, а второй момент, если вы используете 64-битный WebAssembly, он работает от 2 до 7 раз медленнее, чем 32-битный, поэтому рекомендация в статье, если вам не нужно супер много памяти, не надо пока лезть в 64-битный WebAssembly, он скорее всего будет медленнее.
+328.60 370.32 "Игорь Лабутин" Дальше продолжается прогресс по всяким разным фичам другим, во-первых, по симдам есть некоторый прогресс, он вышел из-под фичи флагов Firefox, но все еще остается экспериментальным в Safari, есть прогресс по JavaScript promise integration, то есть это позволит сделать асинхронные WebAPI call прямо из синхронного кода, это живет уже в Хроме, это за фича флагов Firefox, а Safari, как написано в статье, перестал возражать против этой фичи в конце 2025 года, то есть они там как-то даже еще не начинали видимо делать или только-только начали.
+370.32 392.68 "Игорь Лабутин" Полезная штука под названием в WebAssembly CSP, CSP это content security policy, если вы занимались много веб-произработкой, вы знаете, что это такое, то есть это набор, грубо говоря, HTTP заголовков, как правило, и некоторое внутреннее поведение браузера, которое позволяет предотвращать некоторые атаки, которые могут возникнуть из-за подмены ресурсов, злоумышленниками и так далее.
+392.68 414.00 "Игорь Лабутин" Вот теперь в WebAssembly CSP улучшился, то есть он позволяет теперь разрешить в WebAssembly не разрешая небезопасный JavaScript, раньше можно было либо разрешить вообще все включение безопасный JavaScript, условно там и валы откуда угодно с любых сторонних сайтов, теперь можно это сделать только для WebAssembly, что легко увеличивает секьюрность.
+414.00 417.92 "Игорь Лабутин" Поддержано везде, сейчас в процессе стандартизации.
+417.92 437.96 "Игорь Лабутин" Поддержка 128-битных чисел, если вам зачем-то это нужно, ну и, соответственно, штука под названием Stack Switching, которая сейчас находится в фазе 3, чтобы это не значило, которая позволит сделать нормальный Async/Await, позволит сделать нормальные коррутины и, в общем, вот это все потихонечку развивается.
+437.96 484.72 "Игорь Лабутин" Добрались мы, по сути, в 2025 году до так называемого WebAssembly 3.0 этапа, а история, собственно, такая, что в 2017, напомню, кстати, да, внезапно в WebAssembly старше в каком-то смысле, можно сказать, нашего подкаста уже, в 2017 году вышла v1.0 MVP-версия, в 2022 году через 5 лет, получается, вышла версия 2.0, и сейчас, вот еще через 3 года, в 25-м вышла версия 3.0, в которой, ну вот если так подытожить, есть, соответственно, поддержка исключений, сборка мусора, сверхбитная память, CMD какие-никакие, tail calls, оптимизации, ну вот это все.
+484.72 491.88 "Игорь Лабутин" То есть все, что позволяет нормально с перфомансом работать, ну, может быть, еще не все, но, по крайней мере, фокус на это есть.
+491.88 503.84 "Игорь Лабутин" Но это все понятно, что WebAssembly, но мы-то все-таки .NET подкаст, давайте сообразим, что же тут у нас с .NET происходит в контексте WebAssembly.
+503.84 524.12 "Игорь Лабутин" Естественно, ну, Unoplatform, поскольку они все-таки немножко про себя старались написать, но начали они все-таки с 10 .NET, который вышел в ноябре, собственно, прошлого года, 25-го, существенно улучшилась, понятно, перфоманс, реалабилити, ну, каждый релиз они такое говорят.
+524.12 537.28 "Игорь Лабутин" Гораздо лучше стала диагностика, мы, по-моему, раза два или три в разных подкастах про разные превью говорили, что у нас диагностика сильно улучшилась, наверное, это все было в контексте Blazor, обычно я довольно часто пропускаю эту секцию детально, ее не рассказываю, но тем не менее.
+537.28 545.72 "Игорь Лабутин" Улучшилась диагностика C# в ходу, улучшилась диагностика JavaScript интеропа, заинтегрировались нормально с браузер-девтулами, в общем, все стало хорошо.
+545.72 556.28 "Игорь Лабутин" Дальше, отладка позволила сейчас отлаживаться прямо из EDE без необходимости браузер-девтул через специальный прокси.
+556.28 568.38 "Игорь Лабутин" И вот, по-моему, мы в одном из последних подкастов посвященных превьюшкам рассказывали про новую фичу под названием performance profiling и diagnostics data extraction, то есть они позволяют профайлить VBS-эмбли прямо в браузере.
+568.38 574.56 "Игорь Лабутин" И UnoPlatform, ну куда же без него, поскольку это блок все-таки UnoPlatform, тоже потихонечку развивалось.
+574.56 600.52 "Игорь Лабутин" В раннем версии 2025 года, версия 5.6, они сделали out-компиляцию, которая стала в два с половиной раза, то есть не сделали, она и была, ушкорили в два с половиной раза, а местами до десяти раз в некоторых случаях, out-компиляцию, а к октябрю сделали существенное улучшение с точки зрения обработки изображений, ну потому что графика и обработка изображений там может быть довольно много.
+600.52 608.76 "Игорь Лабутин" А в ноябре уже выпустил я релиз, который основан на десятом дотнете, полноценно учитывает все его особенности и использует все улучшения.
+608.76 647.48 "Игорь Лабутин" При этом мы уже, по-моему, говорили, что UnoPlatform сильно заколлаборировался с Microsoft, с точки зрения развития дальнейшего, они уже контрибьютили в open-source.net, но теперь, соответственно, они будут, по-моему, мы это раскладывали в контексте Maui, они собирались контрибьютить сильно в Maui в поддержку многопоточности, чтобы сделать нормальную полноценную многопоточность в веб-СМЛ-варианте, как я понимаю, и вроде как это одна из самых, ну скажем так, требуемых фич с точки зрения комьюнити, которую они хотят.
+647.48 667.12 "Игорь Лабутин" Ну и это, понятное дело, не прямо сейчас, это будет делаться в том числе в 11 и даже немножко в 12 дотнете, и здесь roadmap примерно следующий, это не только у UnoPlatform, это в целом у Microsoft, как я понимаю, вот после их, так сказать, совместного анонсмента они договорились примерно о следующем.
+667.12 677.08 "Игорь Лабутин" Значит, в дотнете 11, скорее всего, в веб-СМЛ с точки зрения дотнета мы увидим не очень много всяких разных улучшений.
+677.08 678.08 "Игорь Лабутин" Почему?
+678.08 683.30 "Игорь Лабутин" Потому что есть сейчас в процессе переход от моно-рантайма в Core CLR.
+683.30 710.96 "Игорь Лабутин" Мы уже рассказывали, что, вот я сейчас не помню уже детали, но какой-то из платформ они практически полностью уже смогли отказаться от моно-рантайма, ну вот соответственно этот процесс продолжится, и в итоге, если делать какие-то супер большие фичи сейчас, придется их делать на двух рантаймах, поэтому сначала они хотят в 11 дотнете полностью идти от моно-рантайма в Core CLR, а вот уже потом, ну будем тогда полностью пилить в 12 дотнете уже большую штуку.
+710.96 730.84 "Игорь Лабутин" И вот там как раз таки 12 дотнет будет таргетить веб-СМЛ 3.0, напомню, веб-СМЛ 3.0 как стандарт тут он уже сейчас плюс-минус оформлен, и там будет уже дотнет 12, то есть это 27-й год, да, через, считайте, 2 года настоящего момента, поддерживать сборку мусора и 64-битную память веб-СМЛ.
+730.84 747.84 "Игорь Лабутин" Понятно, что какие-то превью, наверное, выйдут в 11 дотнете, ну вряд ли они так будут ждать или до 12, но скорее всего каких-то больших изменений вот именно с этой точки зрения мы можем увидеть только в, ну года через полтора, я думаю.
+747.84 759.68 "Игорь Лабутин" Что еще, еще можно поговорить про WASI, то есть то, что мы говорили, это WASM, да, веб-СМЛ, есть еще WASI, что такое WASI?
+759.68 765.60 "Игорь Лабутин" WASI – это веб-эссембли, сейчас, веб-эссембли, систем-интерфейс по-моему, да ведь?
+765.60 767.36 "Игорь Лабутин" Что-то я сейчас не помню, как расшифровывается.
+767.36 768.36 "Анатолий Кулаков" Да, систем-интерфейс.
+768.36 784.96 "Игорь Лабутин" Вот, ну в общем, это смысл такой, эта штука, которая некоторый стандарт, да, стандарт-протокол, который позволяет вам, который позволяет писать какие-то модули, которые могут исполняться, в общем-то, где угодно и интегрировать, самое главное, эти модули куда угодно.
+784.96 792.40 "Игорь Лабутин" Для, как правило, естественно, когда мы говорим куда угодно, то это подразумевается вне браузера, да, вы можете там плагинчик себе написать или еще что-то.
+792.40 823.98 "Игорь Лабутин" И там, если WASM добрался до версии уже 3.0, WASI пока до версии 0.3 должен добраться к февралю 26-го года, и версия 1.0, она ожидается только к концу 26-го или может быть к началу 27-го, вот, тут пока .NET не сильно светится, то есть, в общем, ну, опять же, это скорее стандарт, да, нежели чем какие-то специфики .NET нужны, ну, вот, решили они это в статью тоже добавить для полноценности.
+823.98 859.36 "Игорь Лабутин" С точки зрения вообще применения, применения, применимости WebASM или насколько он распространен, значит, статистика сейчас показывает следующее, что примерно, если мы говорим про Chrome, то 5,5% сайтов, которые посещаются через Chrome, ну, отведем к угловой статистике, поэтому именно Chrome, используют тем или иным образом WebAssembly, и рост сейчас пока виден как будто бы примерно 1% в год, не то чтобы прям что-то взрывное, не то чтобы супер много, но тем не менее рост есть.
+859.36 863.68 "Анатолий Кулаков" Ну, с другой стороны, у WebAssembly же нет задачи захватить весь рынок.
+863.68 889.96 "Игорь Лабутин" Конечно, конечно, то есть его все-таки юзкейсы это всякие IOT, где есть не так много памяти, ну, нет возможности что-то большое полноценное запускать, ну, в общем, такие штуки или то, где вам нужно довольно много какого-нибудь, а, ну, безопасность, те же плагины, как я говорю, почему нет, то есть ниша не самая широкая, но тем не менее она есть.
+889.96 903.96 "Игорь Лабутин" Более того, как там тоже в статье сказано, что, ну, как бы с точки зрения поддержки языков, там написано, что почти все из top 25 languages поддерживают так в том или ином виде WebAssembly.
+903.96 924.88 "Игорь Лабутин" Ну, какой топ, непонятно, ну, в общем, понятно, что наверное, любой более-менее популярный современный язык, там есть наверняка компилятор плюс-минус в Wasm, причем, более того, там сказано даже некомпилируемые языки, например, как SQL, тоже, можно сказать, поддерживают WebAssembly, но только в формате, например, хранилищных процедур на нем.
+924.88 925.88 "Игорь Лабутин" Почему бы нет?
+925.88 928.40 "Игорь Лабутин" Кто помнит хранимые процедуры на дотнете?
+928.40 929.40 "Игорь Лабутин" Ну, да.
+929.40 937.24 "Игорь Лабутин" А можно написать на WebAssembly, ну, то есть написать на каком угодном языке, скомпилировать в WebAssembly, использовать внутри базы данных.
+937.24 938.24 "Игорь Лабутин" Почему нет?
+938.24 944.48 "Игорь Лабутин" Ну, или необязательно там хранимые процедуры, можно же там user-defined functions писать, которые уже в запросах потом использовать.
+944.48 953.40 "Анатолий Кулаков" Вообще удобный стандарт для всяких плагинов получается, что если ваше приложение раньше думало, на каком языке предоставить плагины, то вот универсальный ответ на WebAssembly.
+953.40 955.24 "Анатолий Кулаков" То есть, по сути, для любого языка.
+955.24 956.24 "Игорь Лабутин" Да.
+956.24 970.08 "Игорь Лабутин" И планы на 26-й год, то есть, как мы сказали, что дотнет будет, скорее всего, особо пока не сильно рваться вперед, и дотнету нужно перейти на плюс-минус один рантайм, чтобы не делать дважды одну и ту же работу.
+970.08 977.36 "Игорь Лабутин" А вообще, в целом, с точки зрения WebAssembly, общие планы примерно такие.
+977.36 985.20 "Игорь Лабутин" Значит, скорее всего, постараться стандартизировать тот самый content security policy, все, что связано с ним для WebAssembly.
+985.20 991.04 "Игорь Лабутин" Вроде как в Safari там ожидается поддержка memory64, simdof, вот это все.
+991.04 998.68 "Игорь Лабутин" Начинается работа на JavaScript, Promise Integration.
+998.68 1022.80 "Игорь Лабутин" Планируется большая работа по JavaScript модулям, точнее по интеграции с механизмом вот этих вот модулей, потому что сейчас нужно вручную, если вы хотите использовать WebAssembly с JavaScript, вам нужно сначала его отдельно загрузить, в коде написать, условно, C#, если бы вы писали это на C#, какой-нибудь активатор create instance, то есть явно заинстанцировать модуль и только потом работать.
+1022.80 1051.28 "Игорь Лабутин" Сейчас первая фаза, так называемый source phase import, это stage 3, так они любят эти stage и phase, так чтобы было более прозрачная загрузка модулей, а уже Chrome и Firefox над этим работают, в 26 году надеются все это потестировать, а итоговая цель сделать так, чтобы вы могли написать импорт WebAssembly модуля так же, как вы пишете это для JS и все бы работало само, грубо говоря, но к этому пока далеко.
+1051.28 1094.04 "Игорь Лабутин" Так что для .NET, возвращаясь опять же к .NET теме, десятка довольно много принесла с точки зрения перформанса и тулинга, у нас отличный дебаггинг, у нас отличный как бы компилятор, все это можно прекрасно работать и в браузере, и не в браузере, ждем больших изменений в 12 .NET, сейчас пока фокусируемся на поддержке многопоточности, ну и надеемся, что не только там один-два разработчика в Майкрософте будут над этим работать, а все-таки основная платформа команда довольно сильно поможет и много чего продвинет вперед.
+1094.04 1111.68 "Игорь Лабутин" Ну вот примерно такой у нас сейчас стоит WebAssembly, если вы что-то знаете, как-то более детально в этом всем понимаете и есть какие-то комментарии, обязательно напишите, тоже будет интересно посмотреть взгляд со стороны тех, кто это практикует, как вообще живет.
+1111.68 1132.04 "Анатолий Кулаков" Хорошая технология, хороший путь, не знаю, насколько он оправдан тем хайпом, который был у нас, когда мы запускали Blazer и вообще все силы пускали только в Blazer, но приятно, что технология не отстает, то есть .NET не отстает от WebAssembly, и как минимум мы на этот брауз не опоздали, а в принципе находимся в первых рядах, это хорошо.
+1132.04 1139.56 "Анатолий Кулаков" Так, погнали, поговорим с тобой, знаешь, про что интересное, про веб-фреймворки, в общем, какие веб-фреймворки?
+1139.56 1140.56 "Игорь Лабутин" О, ASP?
+1140.56 1141.56 "Игорь Лабутин" ASP?
+1141.56 1142.56 "Игорь Лабутин" ASP?
+1142.56 1143.56 "Игорь Лабутин" Еще раз ASP?
+1143.56 1149.56 "Анатолий Кулаков" Вот, я только хотел спросить, какие ты веб-фреймворки знаешь еще, кроме ASP, а ты прямо об этом спешил?
+1149.56 1154.68 "Игорь Лабутин" Ну, мои черноги памяти вырывают где-то из недр слова Nancy.
+1154.68 1157.72 "Игорь Лабутин" Ну, кто там еще был?
+1157.72 1158.72 "Игорь Лабутин" Ну и хватит, да?
+1158.72 1160.36 "Игорь Лабутин" Да что-то да, я больше и не помню.
+1160.36 1186.66 "Анатолий Кулаков" Ну вот, если ты вспомнишь, например, какие-то другие языки, какие-нибудь Python, не дай боже, Java или прочие глупости, то там в принципе распространена такая практика как различные веб-фреймворки, и там можно как бы заменять, менять, использовать под какие-то конкретные нужды, но в Дотнете, в принципе, если Микрософт написал какую-то штуку, то обычно она хорошая и обычно она работает.
+1186.66 1188.32 "Анатолий Кулаков" Как у нас с ASP.NET-ом-то и сложилось?
+1188.32 1195.12 "Анатолий Кулаков" Если у тебя есть ASP.NET, не очень понятно, зачем нужно что-то другое, поэтому никто, в принципе, другого ничего не использует.
+1195.12 1199.96 "Анатолий Кулаков" А на самом деле есть альтернативные веб-фреймворки, и в принципе их много.
+1199.96 1210.92 "Анатолий Кулаков" Вот автор собрал самые популярные из них, автор статьи, и решил нам их показать, что альтернатива-то существует, она есть и, может быть, она вам нужна, только вы об этом не знаете.
+1210.92 1217.36 "Анатолий Кулаков" Вот давайте посмотрим, а что же такого для веб-фреймворка можно еще использовать, кроме ASP.NET Core.
+1217.36 1222.00 "Анатолий Кулаков" Ну, прежде всего, остановимся немножко на характеристиках самого ASP.NET Core.
+1222.00 1223.00 "Анатолий Кулаков" Что это такое?
+1223.00 1226.76 "Анатолий Кулаков" Это веб-фреймворк, который базируется на библиотеке lib.uv.
+1226.76 1240.80 "Анатолий Кулаков" Его движок называется Kestrel, в него есть два основных подхода для написания API, это так называемый Controller-Based API и Minimal API.
+1240.80 1259.44 "Анатолий Кулаков" Он поддерживает различные стили этих API, у него есть очень богатый набор различных middleware, с помощью которых можно делать абсолютно все, наверное, что только может прийти в вашу голову, сжатие, кэширование, все возможные методы аутентификации и прочее, прочее.
+1259.44 1268.20 "Анатолий Кулаков" У него есть нативная поддержка HTTP/2 и HTTP/3, и в принципе это самый функциональный веб-сервер, естественно, который есть у нас на данный момент.
+1268.20 1275.60 "Анатолий Кулаков" Если вспомнить, сколько в него сил вкладывается, сколько коммитов приходит на каждый релиз .NET, как бы неудивительно.
+1275.60 1284.72 "Анатолий Кулаков" В общем, сил Microsoft туда вбахивает много, и в принципе это идеальное соотношение функциональности и перфоманса, которые у нас есть, и удобства в том числе.
+1284.72 1291.12 "Анатолий Кулаков" Ну, то есть вряд ли кто-то в ближайшее время сможет его побить по всем этим признакам.
+1291.12 1294.98 "Анатолий Кулаков" Но вот по каким-то отдельным характеристикам вполне может быть.
+1294.98 1297.20 "Анатолий Кулаков" Давайте посмотрим, что у нас еще есть на рынке.
+1297.20 1315.04 "Анатолий Кулаков" GenHTTP - это сервер, который разрабатывается с 2008 года и в 2019 был фундаментально пересмотрен, поддерживает веб-сокеты, сервер-сент-эвенты, статические файлы, сингл-пейдж-аппликейшены.
+1315.04 1320.44 "Анатолий Кулаков" У него внутри уже встроен реверс-прокси, сервер-сайт-кэшинг и mTLS.
+1320.44 1332.00 "Анатолий Кулаков" Он open-source, естественно, в принципе все у нас в обзоре сегодняшние движки, они будут open-source, но у него есть коммерческая лицензия, на которой он как раз-таки и зарабатывает.
+1332.00 1354.28 "Анатолий Кулаков" Вот GenHTTP нужен разработчикам, если вы хотите больше гибкости, потому что как раз гибкости в нем предоставляется побольше, чем у SPNET, и, например, если вы хотите встроить в какие-то свои приложения, в свои фреймворки, и при этом вам нужен более гибкий и более мелкий фреймворк, чем SPNET.
+1354.28 1358.40 "Анатолий Кулаков" Не такой прожорливый и не такой большой по размерам.
+1358.40 1361.80 "Анатолий Кулаков" Следующий фреймворк в нашем списке – это SISC.
+1361.80 1381.40 "Анатолий Кулаков" SISC разрабатывается с 2022 года, в принципе довольно молод, он требует .NET 8 или старше, и его основная направленность – это декларативный язык описания и минимальное количество зависимостей.
+1381.40 1392.36 "Анатолий Кулаков" У него очень хорошая документация, понятная, полная, но поддерживает он из протоколов только HTTP 1.1, при этом включая веб-сокеты и сервер-сенты-ивенты.
+1392.36 1411.28 "Анатолий Кулаков" SISC хорош, если вы хотите очень минималистичный, то есть такой маленький движок, очень простой, очень простой, очень прямой, очень понятный, а также с ориентацией на декларативное, на программирование с помощью декларации, на декларативной модели, и с минимальным количеством зависимостей.
+1411.28 1414.12 "Анатолий Кулаков" Вот SISC – это как раз ваш выбор.
+1414.12 1423.48 "Анатолий Кулаков" Simple W, Simple W разработка его была начата в 2023 году, кажется недавно вообще.
+1423.48 1431.84 "Анатолий Кулаков" Я думал, что это какие-то движки, которые начинались еще до того, как ISP.NET начал быть таким популярным и просто по инерции живут.
+1431.84 1432.84 "Анатолий Кулаков" Оказывается, нет.
+1432.84 1445.84 "Анатолий Кулаков" Большинство этих движков или начинаются вот в наши времена, или модернизируются в наши времена, но то есть они довольно активные и зачем-то люди их делают, зачем-то люди их стартуют, а значит это кому-то нужно.
+1445.84 1468.04 "Анатолий Кулаков" Он также, как и ISP.NET, предоставляет Controller Style API, то есть с помощью контроллеров там можно все писать в привычном, волдовом стиле, поддерживает веб-сокеты, сервис-энд-евенты, HTTP 1.1 только и все, и по TechCompiler, бенчмаркам он обгоняет Minimal API, который поставляется с ISP.NET Core.
+1468.04 1486.84 "Анатолий Кулаков" Так что, в принципе, если вам нужен контроллер-бейст API, то есть с помощью контроллеров вы любите писать ваши эндпойнты и при этом нужен большой перфоманс, то тоже хороший вариант для того, чтобы рассмотреть.
+1486.84 1499.36 "Анатолий Кулаков" Немножко необычный следующий пункт в нашем списке – это Unhunged, наверное, да, какой-то Unhunged, хорошее название.
+1499.36 1515.28 "Анатолий Кулаков" Смысл в этом необычном сервере заключается в том, что он очень экспериментальный, кроме HTTP 1.1 ничего не поддерживает, и основная его задача – это показать то, а насколько вообще может выйти быстр.net для протокола HTTP 1.1.
+1515.28 1527.40 "Анатолий Кулаков" В бенчмарках TechEmpowers этот сервер занимает четвертое место, т.е. он достиг 98,4% от победителя.
+1527.40 1532.52 "Анатолий Кулаков" Как раз, получается, да, четвертое место по фреймворк-бенчмаркам.
+1532.52 1540.90 "Анатолий Кулаков" Это довольно много, естественно, он обгоняет сейчас ISP.NET и показывает чудеса перформанса.
+1540.90 1570.16 "Анатолий Кулаков" Этот сервер абсолютно не для продакшена, т.е. втащить его в продакшен ни в коем случае не надо, но он как раз показывает чудеса перформанса, и он интересен разработчикам как вариант того, как можно выжать, улучшить лимиты перформанса для HTTP серверов, т.е. в него активно заглядывают и разработчики ISP.NET, и какие-то там экспериментальные штуки с ним творят, для того, чтобы перенести потом это все в свои сервера.
+1570.16 1575.68 "Анатолий Кулаков" Какие-то подходы новые, все обкатывается как раз на этом сервере.
+1575.68 1576.68 "Анатолий Кулаков" Watson.
+1576.68 1583.92 "Анатолий Кулаков" Это специальный веб-фреймворк с низкоуровневым доступом к HTTP-примитивам.
+1583.92 1620.08 "Анатолий Кулаков" Еще он интересен тем, что поддерживает большое количество фреймворков, начиная от большого .NET-A461 через NETSTANDARD-21 и заканчивая последними .NET-10, т.е. это хороший выбор, если вдруг вам нужно внедриться в какие-нибудь Legacy-проекты, которые работают еще на .NET-4 или на стандартах, а также хорош для каких-нибудь экзотических всяких использований, например, встраивания или использования в Unity-играх, тоже в принципе нормуль.
+1621.08 1637.32 "Анатолий Кулаков" Следующий кандидат в наших пунктах - это Wired.io, он был начат в 2024-м, наверное, это самый молодой кандидат из нашего списка, т.е. буквально ему годик-два годика, совсем юн.
+1637.32 1651.04 "Анатолий Кулаков" Но при этом довольно много всего умеет, из коробки прямо у него идет Dependency Injection и логинг, а также полный контроль над обработкой HTTP-запросов на довольно-таки низком уровне.
+1651.04 1664.44 "Анатолий Кулаков" В нем можно сделать практически все, допустим, вы можете подменить стандартный HTTP-парсер на свой, если вам зачем-то это нужно, или вы можете напрямую писать в HTTP-респонс.
+1664.44 1669.12 "Анатолий Кулаков" В общем, много вот таких низкоуровневых трюков можно делать.
+1669.12 1684.32 "Анатолий Кулаков" При этом у него довольно хорошая документация, и те endpoint, которые на нем делаются, они быстрее минимум API стандартного, ASP.NET, т.е. довольно хороший кандидат.
+1684.32 1710.80 "Анатолий Кулаков" Подходит для всяких сложных сценариев, где вам нужно очень тонко и очень низкоуровнево что-то настраивать, при этом довольно производителен и также очень-очень хорошо контролирует абсолютно все на уровне HTTP-респонсов, т.е. можно творить с входящими и сходящими стримами абсолютно все, что придет к вам в голову, т.е. довольно гибкий и кастомный.
+1710.80 1714.56 "Анатолий Кулаков" Вот основные такие сервера, которые в принципе сейчас разрабатываются.
+1714.56 1729.00 "Анатолий Кулаков" Все они активно разрабатываются, активно контрибьютится и пытаются что-то из себя выжать, составить какую-то конкуренцию, естественно, не во всех нишах ASP.NET, но в каких-то определенных задачах, в принципе, наверное, могут с ним состязаться.
+1729.00 1736.46 "Анатолий Кулаков" Из неактивных стоит упомянуть это Embedded I/O, Netcore сервер и Nancy.
+1736.46 1747.86 "Анатолий Кулаков" Nancy мы в нашем подкасте не раз упоминали, особенно когда .NET Core только начинался, и Nancy был как раз глотком свежего воздуха для ASP.NET разработчиков.
+1747.86 1756.18 "Анатолий Кулаков" Как раз, наверное, это единственный момент, который можно вспомнить, когда кто-то составлял действительно достойную конкуренцию ASP.NET.
+1756.18 1769.58 "Анатолий Кулаков" Не то, чтобы Nancy занял какую-то значимую долю рынка, но те подходы, которые он пропагандировал, та скорость, с которой он это делал, та гибкость и элегантность, она многого стоила.
+1769.58 1781.40 "Анатолий Кулаков" В принципе, большинство идей Nancy уже перекочевало давно в стандарт на ASP.NET, в частности, Minimal API вдохновлялся немалым количеством тех подходов, которые были в Nancy.
+1781.40 1786.62 "Анатолий Кулаков" Nancy мы помним, Nancy мы любим, но проект уже давно заархивировал и не развивается.
+1786.62 1794.60 "Анатолий Кулаков" Ну что ж, в конце хочется подвести итоги, а зачем же вам вообще может понадобиться смотреть на какие-то альтернативы ASP.NET?
+1794.60 1808.38 "Анатолий Кулаков" Ну, во-первых, это какие-то свежие идеи, которые приходят в мир, которые перекачивают из других языков, которые просто выдумываются, новые подходы, новые идеи, новые способы задания endpoints, новые способы настроек и конфигураций.
+1808.38 1815.26 "Анатолий Кулаков" В общем, новизна — это хорошо, поэтому нельзя замыкаться на каком-то большом, одном, старом, негибком фреймворке.
+1815.26 1817.30 "Анатолий Кулаков" В принципе, ASP.NET и не замыкается.
+1817.30 1822.50 "Анатолий Кулаков" Он регулярно смотрит вокруг и тырит все хорошие идеи, которые вокруг всплывают.
+1822.50 1824.74 "Анатолий Кулаков" Во-вторых, это performance.
+1824.74 1829.62 "Анатолий Кулаков" В принципе, ASP.NET очень производительный сервер, но общего назначения.
+1829.62 1842.42 "Анатолий Кулаков" В некоторых узких местах, в некоторых каких-нибудь ваших кейсах вполне может быть, что performance сторонних веб-серверов будет гораздо лучше, чем у большого ASP.NET.
+1842.42 1850.22 "Анатолий Кулаков" Поэтому, если вы гонитесь за performance, вполне стоит посмотреть и на какие-то остальные минималистичные альтернативы.
+1850.22 1851.86 "Анатолий Кулаков" Опять же, минимализм.
+1851.86 1866.34 "Анатолий Кулаков" Если вам не нужен какой-то огромный большой фреймворк, если вы хотите встроиться, например, в какие-нибудь десктопные приложения, в какие-нибудь игры на Unity или еще куда-то, то есть вам нужен маленький встраиваемый сервис.
+1866.34 1869.22 "Анатолий Кулаков" Вот тоже ASP.NET не самый лучший вариант.
+1869.22 1873.98 "Анатолий Кулаков" Вполне можно найти что-то гораздо меньше, гораздо компактнее и легче в настройке.
+1873.98 1887.74 "Анатолий Кулаков" Или, наоборот, если вам нужно низкоуровневое управление различными потоками, протоколами, битиками, байтиками для того, чтобы, опять же, творить какие-то свои протоколы или выжать максимум из перформанса.
+1887.74 1900.02 "Анатолий Кулаков" ASP.NET не сильно дает доступ на низком уровне к различным сокетам, стримам и вообще обходам стандартных механизмов, которые уже у него есть, уже у него встроены.
+1900.02 1912.70 "Анатолий Кулаков" В общем, другие серверы вполне раскрывают для вас все необходимые уровни, поэтому можете их настраивать, можете с ними общаться на том уровне, на котором вам удобно, на том уровне, который вам нужен.
+1912.70 1918.42 "Анатолий Кулаков" Ну и, наверное, не самое последнее место - это обучение.
+1918.42 1921.38 "Анатолий Кулаков" Кто из нас не мечтал написать свой собственный веб-сервер?
+1921.38 1963.42 "Анатолий Кулаков" Ну, наверное, послеоперационная система и базы данных - это один из самых популярных запросов, поэтому если вы хотите узнать, как сервер, веб-сервер работает, как работает HTTP-протокол на низком уровне, да не только HTTP, там все эти сервер-сенд-эвенты, и МТЛС, и прочее интересное, там огромное количество новых технологий у нас используется для обмена веби-данными, поэтому обучение - это тоже прекрасный способ посмотреть на альтернативы, потому что обучаться на самом ISP-нете довольно сложно, он огромный, он просто огромный, поэтому хочется что-то более мелкое, более простое, более понятное, с хорошей может быть даже документацией.
+1963.42 1967.10 "Анатолий Кулаков" Вот альтернативы вам предоставляют эту возможность.
+1967.10 1977.50 "Анатолий Кулаков" Поэтому другие веб-фреймворки в дот-нете есть, в принципе, они пользуются своей популярностью и весьма востребованы в некоторых отраслях.
+1977.50 1999.54 "Игорь Лабутин" Ну при этом, наверное, действительно, в реальной жизни вы вряд ли часто ими пользуетесь, но тем не менее, если вы действительно работаете в какой-то очень специальной отрасли, у вас там, не знаю, embedded-устройство или еще что-нибудь, то, наверное, вы лучше знаете, что ISP-нета возможно туда не влезает, нужно брать что-то более низкоуровневое.
+1999.54 2012.06 "Игорь Лабутин" Но давайте пойдем дальше, и мы поговорим про нашу любимую тему, нугет-пакетики, мы тоже, мне кажется, довольно часто про всякие нугеты, нугет-орги и прочие штуки говорим.
+2012.06 2013.06 "Игорь Лабутин" Ну это важно, да.
+2013.06 2032.82 "Игорь Лабутин" Ну это важно, это то, куда мы пакуем их, то, как мы публикуем наш код, и здесь мы поговорим про такую штуку, которая называется Software Bill of Materials, он же СБОМ, а имя по-русски, как это назвать-то, Bill of Materials, перечень, перечень исходников, ну не исходников, а перечень зависимости, наверное, я бы так сказал.
+2032.82 2039.90 "Анатолий Кулаков" Наверное, мне кажется, должен быть какой-то уже устоявшийся русский термин, потому что в нугете появилось.
+2039.90 2040.90 "Анатолий Кулаков" Наверное.
+2040.90 2044.18 "Игорь Лабутин" Мне даже интересно, я не посмотрел.
+2044.18 2057.94 "Игорь Лабутин" Сейчас быстро погуглим, и быстро погуглим, это называется спецификация программного обеспечения или перечень программных компонентов, или ведомость материалов при производстве.
+2057.94 2061.50 "Анатолий Кулаков" Ну вот это же похоже на что-то серьёзное.
+2061.50 2062.50 "Анатолий Кулаков" Да.
+2062.50 2066.46 "Игорь Лабутин" Ну так вот, давайте разбираться, что это такое, и при чём здесь .NET.
+2066.46 2069.34 "Игорь Лабутин" Статья, между прочим, от Андрю Лоука, так что .NET здесь явно будет.
+2069.34 2070.34 "Игорь Лабутин" Куда же без него?
+2070.34 2073.34 "Игорь Лабутин" Ну и нугет, я же сказал ранее, что будет нугет.
+2073.34 2074.34 "Игорь Лабутин" Итак, что же это такое?
+2074.34 2094.86 "Игорь Лабутин" Ну, во-первых, да, это действительно некоторый эквивалент в софте для того, что мы называем ведомость материалов при каком-то реальном живом производстве, и туда входят в этот перечень все пакеты, зависимости, компоненты, которые нужны для того, чтобы произвести тот самый софтверный артефакт, то есть итоговый, там, DLL, такой нугет-пакет, либо что-либо ещё, который вы собираете.
+2094.86 2099.70 "Игорь Лабутин" Что эта штука позволяет, ну какие задачи она позволяет решить?
+2099.70 2100.70 "Игорь Лабутин" Позволяет решить следующие задачки.
+2100.70 2117.90 "Игорь Лабутин" Во-первых, понять, насколько ваш компонент или зависимости вашего компонента потенциально уязвимы, то есть мы же, зная точные версии, от чего мы зависим, можем по какой-нибудь базе данных уязвимости всё это посмотреть и выяснить, ага, мы зависим от каких-то уязвимых библиотек, надо что-то обновлять.
+2117.90 2137.54 "Игорь Лабутин" Второй момент, который можно сделать, это проверить лицензионную частоту, выяснить, нет ли какой-нибудь там GPL-ной зависимости в наших зависимостях, которая потребует формально открыть нашу библиотеку, компонент тоже согласно GPL, или ещё что-нибудь в таком духе.
+2137.54 2148.58 "Игорь Лабутин" Ну и любые риски, собственно, цепочки поставок тоже можно с помощью этого инструмента не то чтобы предотвращать, но по крайней мере возможно находить или как-то определять.
+2148.58 2156.10 "Игорь Лабутин" Есть два популярных стандарта, это не просто так, это есть прям стандарты цифровые того, как это дело хранить.
+2156.10 2168.38 "Игорь Лабутин" Один называется SPDX, а второй CYCLONDX, все они это ISO, ECMO-стандарты, по сути записывают это всё, я так понимаю, в GSON-чике.
+2168.38 2182.26 "Игорь Лабутин" Что вообще можно сделать, как вообще эту штуку получить, то есть для того, чтобы вот этот софтвер биллов материалов построить, желательно бы, естественно, это делать не вручную, вы не будете писать это всё в списочек вручную, хотя и можно, но надо это делать автоматизированно.
+2182.26 2188.66 "Игорь Лабутин" Во-первых, если вы пользуетесь гитхабом, у вас проект лежит на гитхабе, у вас есть, скорее всего, встроенный экспорт этой штуки.
+2188.66 2220.62 "Игорь Лабутин" Вы переходите в раздел Insights, там можно перейти в раздел Dependency Graph, и там есть кнопка Export с BOM, вам генерируется SPDX-овый GSON-чик автоматически, и он включает вообще все зависимости, какие-то тестовые проекты, примеры, гитхаб экшены, то есть если у вас, например, есть проект, вы собираете NuGet-пакет гитхаб экшеном, то гитхаб экшен же тоже зависит от каких-то шагов, и все эти элементарные шаги, элементарные действия тоже входят в вашей зависимости, они все туда будут вписаны.
+2220.62 2239.66 "Игорь Лабутин" Расчёт получается довольно подробный, хороший, но единственное, что вы не можете ничего в нём кастомизировать, то есть, например, если вы знаете, что вам по какой-то причине не нужны, например, билд-шаги, вы не можете их исключить в момент генерации, наверное, вы можете потом что-то подправить, но именно в момент генерации вы ничего не можете сделать.
+2239.66 2257.94 "Игорь Лабутин" Второй инструмент — это майкрософтский тул, он уже года 3-4 назад заопенсурсился, доступен как обычный dotnet global tool, создает SPDX версии 2.2, и позволяет много-много чего конфигурить, что вы хотите, включать в этот самый отчет.
+2257.94 2274.78 "Игорь Лабутин" Для того, чтобы его поставить, ну как обычный dotnet tool install microsoft.sbom.dotnettool, и у вас будет, соответственно, командлайновая тулза, которая как раз-таки хочет параметры типа package name, package version и так далее, чтобы из этого всего построить SBOM-отчет.
+2274.78 2309.62 "Игорь Лабутин" И при этом то, что получается, она генерирует ещё в том числе checksumed файлов, то есть вы не то, что там будет просто написано в библиотеке какая-то версия такой-то, а прямо с checksumed, то есть даже если кто-то опубликует какой-то фейковый пакет с тем же именем и с той же версией, ну так получится, почему-то на каком-нибудь кастомном get-сервере, который вы почему-то случайно начнёте качать этот файлик, то checksumed будет сверено, и можно по крайней мере попробовать отловить тот факт, что зависимость вообще говоря не соответствует тому, которое указано в этом самом bill of materials.
+2309.62 2349.42 "Игорь Лабутин" У него есть некоторые ограничения, он не понимает то, что называется development dependencies, то есть те зависимости, которые нужны только для девелопмента, и он больше подходит по своему дизайну именно для приложений, нежели чем для нукет-пакетов или каких-то компонентов, то есть он предназначен больше прям подписать, грубо говоря, список зависимостей приложения, и таким образом вы можете быть уверены, что вот эта версия приложения была собрана с вот этими конкретными зависимостями, сможете если что точно пересобрать с теми же зависимостями или убедиться, что при пересборке зависимости не поменялись.
+2349.42 2408.70 "Игорь Лабутин" Дальше есть инструмент под названием SIFT, это в основном доступен, ну или рекомендуется его использовать через GitHub Action под названием Anchor, с BOM Action, довольно простой, указываете путь, говорите куда изгенерить, он парсит файлик deps.json, это файлик, который автоматически генерируется при идутной билде, оттуда он берет собственно все зависимости, получает очень подробный в результате SPDX формат, в смысле в SPDX формате, включает огромное количество всяких зависимостей, кто там от кого зависит и так далее, определяет зависимости уровня времени разработки, грубо говоря, максимально простой с точки зрения использования, сейчас супер простой, но генерирует супер подробную штуку, это может быть тоже не очень здорово, иногда много подробностей уже, чем какой-то более простой output.
+2408.70 2457.58 "Игорь Лабутин" Ну и есть еще штука под названием CycloneDXModuleFor.net, напомню, что у нас два формата SPDX и CycloneDX, вот если вам нужен CycloneDX по какой-то причине, то вот этот единственный tool, он тоже доступен как .net global tool, именно кстати его больше всего воспринял как такой нормальный удобный tool ND сам по себе, но мы его как обычно инсталлим, задаем какие-то важные параметры, типа там, что мы хотим JSON, мы хотим рекурсивно, мы хотим там тип output какой-то, гораздо более толковый вывод с точки зрения, он человекочитаемый и более компактный, чем SPDX, ну и соответственно дерево зависимости, оно гораздо более удобно устроено, его можно просто чуть ли не глазками прочитать.
+2457.58 2473.82 "Игорь Лабутин" Ну вот отлично, мы сгенерили сбом, тем или иным способом мы получили файлик, в котором написано от чего мы зависим, какие зависимости есть в нашем там туле, приложении, библиотеке, нугете, чему угодно.
+2473.82 2478.62 "Игорь Лабутин" Дальше мы можем создать так называемый сбом аттестейшн.
+2478.62 2479.62 "Игорь Лабутин" Зачем?
+2480.22 2498.34 "Игорь Лабутин" Эта штука по сути доказывает, подтверждает, что сбом не был изменен, то есть если это JSON файлик, то понятно, что вы можете в этом JSON файлике поменять что угодно, и это будет нездорово, поэтому нужно его как бы по сути подписать.
+2498.34 2532.18 "Игорь Лабутин" Для этого используется, ну как правило, если мы про GitHub говорим, то GitHub action, который, соответственно, работает и с SPDX, и с CycloneDX форматом, принимает в себя некоторые, соответственно, пути, что нужно подписать, и генерирует подпись, которую там правильным образом как-то с помощью GitHub подписывает, в результате у вас получается подписанный сбом файлик, который вы уже сможете потом проверить.
+2532.18 2540.74 "Игорь Лабутин" Проверка называется процедура аттестейшн, то есть мало того, что вы подписались, тебе нужно проверять.
+2540.74 2582.02 "Игорь Лабутин" Для этого используется, кстати, можно GitHub command-line interface, то есть в команде gh, если вы пользуетесь гитхабовским command-line интерфейсом, есть прям команда gh attestation verify, куда передается, соответственно, ваш этот SPDX или CycloneDX подписанный сбом, и он проверяет, что да, он не поменялся, он действительно такой, как был, подписан правильно, показывает там всякие, кем он был подписан, когда, о чем, всякие такие штуки, workflow, то есть в каком workflow это было подписано, в какой репозитории это собиралось, ну и кем это было подписано.
+2582.02 2612.26 "Игорь Лабутин" В общем, процедура в целом понятна, если вы хотите быть уверенным, что ваше приложение, модуль и так далее, даже не то, чтобы вы хотите быть уверенным, а может быть вы хотите кому-то доказать, что именно это приложение, модуль и так далее, было собрано именно с этими зависимостями, вы генерите этот Software Bill of Materials, вы его, создаете аттестацию для него, то есть, по сути, подписываете, и потом кто угодно может в принципе сказать gh attestation verify, и, соответственно, проверить, что этот Software Bill of Materials верный.
+2612.26 2625.86 "Игорь Лабутин" Возвращаемся в мир дотнета, у нас есть нугет, и с нугетом все, конечно, хорошо, здорово и прекрасно, мы сможем посчитать, не знаю, чексумы и все остальное, и все такое прочее, есть одна проблема.
+2625.86 2674.22 "Игорь Лабутин" Если вы берете нугет-пакет, допустим, вы его собираете, вы считаете его чексуму, и upload'ите этот nuget-пакет на nuget.org, то происходит некоторая проблема, потому что nuget.org при upload'е nuget-пакета его меняет, тем самым меняя чексуму, меняет он его потому, что он туда подсовывает или подменяет файлик под названием .signature.p7s, то есть некоторая внутренняя подпись, которую nuget.org добавляет, и как только вы это сделали, хэш поменялся, все аттестации съехали, потому что подписи будут невалидные, по сути, все вот эти аттестации становятся практически бесполезными, поэтому с nuget.org такая проблема.
+2674.22 2676.66 "Игорь Лабутин" Значит, что с этим можно сделать?
+2676.66 2684.58 "Игорь Лабутин" С этим можно сделать следующее, можно попытаться удалять этот signature.p7s перед тем, как проверять.
+2684.58 2709.82 "Игорь Лабутин" Ну, в целом, можно удалить, такое работает, если вы upload'ите неподписанный nuget, как я сказал, то есть nuget.org либо добавляет эту подпись, либо ее обновляет, и соответственно, если вы upload'или неподписанный nuget, то, естественно, если удалить этот валик, у вас скорее всего обратно хэш-сумма восстановится, и все будет нормально.
+2709.82 2733.38 "Игорь Лабутин" Но если вы upload'или подписанный автором пакет, то есть вы подписываете свой nuget, потом upload'ите nuget.org, nuget.org там подменит подпись, и все, тогда, конечно, никак, и поэтому с помощью вот этого сбом аттестейшна проверифицировать nuget пакеты, которые прилетели с nuget.org, ну, по большому счету сейчас невозможно, вот.
+2733.38 2736.66 "Игорь Лабутин" Что в итоге сейчас получается?
+2736.66 2741.58 "Игорь Лабутин" У nuget, да, вот, собственно, вся эта подпись, зачем это все делать?
+2741.58 2785.18 "Игорь Лабутин" Делать это как раз ровно для той же самой процедуры, то есть nuget.org сделал свою собственную систему того, как проверить, что пакет принадлежит тому, кто его реально опубликовал, да, без вот этих сбомов и так далее, а своей собственной подписью, и это, с одной стороны, хорошо, потому что их система никак не подвязана конкретно к github, ну, как бы, что такого, мало ли, как вы генерируете нугеты, но из-за этого гитхабовские вот эти аттестейшны вообще практически бесполезны в нугет-экосистеме, ну, то есть, по сути, в дутнете, сгенерировать-то вы все еще сможете легко, свободно, а вот проверифицировать есть некоторые проблемы, поэтому пока эта часть у нас подвешена, вот.
+2785.18 2855.86 "Игорь Лабутин" И все вот это вот, оно, это проблема уровня всей экосистемы, потому что основной, по сути, хранилище пакетов, которые используются всеми в дутнете, не поддерживает нормально полноценную гитхабовскую систему вот этих вот подписей, сбомов и так далее, и вроде бы и хорошо, ну, в смысле, как нехорошо, вроде бы и здорово, что nuget.org сам по себе поддерживает некоторую возможность провалидировать, что пакет действительно тот, который нужен, что он подписан, там правильные галочки, у нас же там, помнишь, мы рассказывали про всякие prefix reservation, или как-то так, что с Microsoft могут начинаться только правильные, значит, пакеты, которые сам Microsoft подписал, все здорово, но это все работает хорошо до тех пор, пока вам нужно удостовериться, что только nuget пакеты пришли из правильного источника и не были каким-то образом использованы, а если вам нужно полностью подтвердить ваш flow, включая всякие github-экшены, workflow там, прочие зависимости какие-то сторонние, которые вы по той или иной причине поставили, у вас там какие-то нативные скрипты или питомские скрипты в процессе билда исполняются, их тоже нужно включать зубом, то, конечно, тогда nuget-овская вот эта вот отдельная реализация немножко мешает.
+2855.86 2884.50 "Игорь Лабутин" Такая вот какая-то история, то есть на данный момент NT пришел к тому, что если ему что-то надо, он пытается сделать, использовать cyclone.dx, но больше пока с точки зрения просто изгнедить, посмотреть все зависимости, проверить вот те самые лицензионные частоты и так далее, нежели чем использовать это для подписи, для дальнейшей верификации того, что то, что вы получаете откуда-то загружая, собрано именно с нужными зависимостями и с возможностью проверить подписи.
+2884.50 2887.22 "Игорь Лабутин" В nuget-мире пока это не получается.
+2887.22 2908.66 "Игорь Лабутин" Вот такая вот у нас история, я бы сказал, что я, честно говоря, по-моему, ни разу не собирал этот самый зубом, пока не автоматизированный toolами, наверное, для каких-то, наверное, для единичных проектов у меня была какая-то такая попытка вручную описать, какие зависимости у нас были.
+2908.66 2947.46 "Игорь Лабутин" Больше как раз таки для лицензионной частоты, но либо использовали всякие статические анализаторы для проверки лицензий, по версиям просто, ну по версиям названия библиотек, которые, видимо, ходят в какие-то публичные базы и знают, какие лицензии в каких библиотеках есть, но больше, в общем-то, мой опыт этим ограничивается, так что мне кажется, что такая довольно редкая штука для того, чтобы много о ней что-то слышать, и может быть даже для того, чтобы Nugetork как-то пошевелился, чтобы как-то, может быть, заинтегрироваться со всеми этими более широко распространенными в целом в экосистеме стандартизированными форматами типа SPDX и прочего.
+2947.46 2952.90 "Игорь Лабутин" Ну посмотрим, посмотрим, куда это всё подвинется, насколько всё это будет востребовано.
+2952.90 2971.06 "Анатолий Кулаков" Я бы с тобой согласился, хотя, опять же, если мы берем корпоративный рынок и юристам довольно важно, какая лицензия используется у нас в программе и не затащили ли мы случайно то, что затаскивать не надо, поэтому, наверное, в компаниях всё-таки юристы бы настояли на том, чтобы такой SBOM был у каждого продукта.
+2971.06 2984.14 "Анатолий Кулаков" Но есть более, наверное, рынок более важный – это и рынок секьюрити, потому что SBOM же помогает не только лицензию устанавливать, но и версии, а версии бывают баги.
+2984.14 2994.54 "Анатолий Кулаков" А вот следить за багами – дело, наверное, всех, не только каких-то больших корпораций, но и open-source проектов и каких-нибудь тем более уже корпоративных проектов.
+2994.54 3004.54 "Анатолий Кулаков" Поэтому с точки зрения секьюрити, мне кажется, вот SBOM – это довольно важная штука, и как-то жалко, что слишком мало ей выделяется времени, слишком мало как раз выделяется интеграцией со стороны Nuget.org.
+3004.54 3015.94 "Игорь Лабутин" Ну Nuget.org свою реализацию сделала, и, в общем, им хорошо, не знаю, есть ли какие-то попытки, не знаю, поползновения в сторону интеграции между ними.
+3015.94 3023.70 "Игорь Лабутин" Я, честно говоря, никогда не слышал, чтобы Nuget.org как-то вместе звучала в одной фразе с SPDX, вот так скажем.
+3023.70 3033.58 "Игорь Лабутин" SPDX я слышал, Nuget.org я, естественно, слышал, но не особо внимательно, так сказать, в это смотрел.
+3033.58 3041.22 "Анатолий Кулаков" Ну вот кажется, нам нужно пройти, прийти в индустрию к той ситуации, когда у нас вот этот SBOM будет стандартным артефактом любого билда.
+3041.22 3042.22 "Анатолий Кулаков" Наверное, да.
+3042.22 3055.38 "Анатолий Кулаков" У нас есть там DLL-ки, PDB-шки, XML-документация, вот должен лежать ещё SBOM, чтобы там любой юрист, любой security tool мог пойти и проверить сборку, в общем, на всякие уязвимости.
+3055.38 3058.02 "Анатолий Кулаков" И тогда будет, в принципе, хороший новый мир.
+3058.02 3059.02 UNKNOWN Да.
+3059.02 3064.02 "Игорь Лабутин" Есть ли у нас… давай пойдём дальше, есть ли у нас ещё что-нибудь на сегодня.
+3064.02 3071.46 "Анатолий Кулаков" Да, давай, у меня есть такая более техническая тема, хочется уже всё-таки опуститься к коду и поговорить про него.
+3071.46 3086.06 "Анатолий Кулаков" Поэтому у Геральда Боре вышла прекрасная сотеечка, которая называется «А каким образом нам извлечь имя файла из нашего метода в рантайме с помощью PDB-шек?».
+3086.06 3092.42 "Анатолий Кулаков" Очень необычный способ, стандартное желание, но не стандартный способ.
+3092.42 3096.50 "Анатолий Кулаков" В принципе, я никогда им не пользовался, именно поэтому статья вызвала у меня интерес.
+3096.50 3103.90 "Анатолий Кулаков" Я думаю, что мало кто из наших слушателей тоже доходил до него, но решение лежит у нас под рукой.
+3103.90 3110.82 "Анатолий Кулаков" Поэтому кажется, что мы как минимум должны о нём знать, должны понимать, что это возможно и как это возможно сделать.
+3110.82 3114.50 "Анатолий Кулаков" А теперь об этом я немножко о другом поподробнее.
+3114.50 3117.10 "Анатолий Кулаков" Во-первых, что мы хотим?
+3117.10 3123.94 "Анатолий Кулаков" Мы часто хотим узнать, например, а где тот или иной метод объявлен в исходном коде?
+3123.94 3131.58 "Анатолий Кулаков" В каком файле, в какой строке, какое имя у этого метода, в каком столбце, допустим.
+3131.58 3133.70 "Анатолий Кулаков" В общем, всё это нам хочется узнать.
+3133.70 3143.74 "Анатолий Кулаков" И нам это может пригодиться, например, во время дебаггинга, во время логирования или во время тестирования.
+3143.74 3148.02 "Анатолий Кулаков" Особенно, когда мы пишем инструменты, автоматизированные под эти процессы.
+3148.02 3152.70 "Анатолий Кулаков" В общем, тогда у нас встает чёткий вопрос, а где это вообще в коде находится.
+3152.70 3165.54 "Анатолий Кулаков" Если мы берём стандартные подходы, то по дефолту из коробки есть Caller Information Attributes, которые позволяют нам, в принципе, легко всю эту информацию добыть.
+3165.54 3175.78 "Анатолий Кулаков" Они работают в Compile Time и требуют для того, чтобы вы изменили метод, если ваш метод должен предоставлять подобную информацию.
+3175.78 3194.10 "Анатолий Кулаков" Но что, если нам нужно добыть подобную информацию для любого метода, не обязательно того, к которому у нас есть исходные коды, и нам эту информацию нужно добыть в Runtime, а не в Compile Time, как раз как и поступают допустим дебаггеры.
+3194.10 3198.58 "Анатолий Кулаков" Вот здесь уже начинается сложность у стандартного подхода.
+3198.58 3200.70 "Анатолий Кулаков" Давайте рассмотрим его подробнее.
+3200.70 3209.38 "Анатолий Кулаков" Итак, Caller Information Attribute - это самый простой способ получить то, что я хотел, то, что мы описали выше.
+3209.38 3212.22 "Анатолий Кулаков" Это различная информация о вызывающей точке.
+3212.22 3226.86 "Анатолий Кулаков" Например, мы можем узнать, как называется метод, который вызывает наш метод, допустим, из какого файла, то есть полный путь к файлу, и в какой номер строчки, в какой строке.
+3226.86 3233.14 "Анатолий Кулаков" Все эти переменные должны быть объявлены в нашем методе.
+3233.14 3240.94 "Анатолий Кулаков" Допустим, стандартный метод логирования, который любит принимать подобные параметры, и у каждого параметра должен быть свой атрибут.
+3240.94 3250.38 "Анатолий Кулаков" По этому атрибуту компилятор понимает, что во время компиляции необходимо данный аргумент вашего метода заполнить тем или иным значением.
+3250.38 3254.62 "Анатолий Кулаков" Поэтому во время Compile Time они заполняются.
+3254.62 3261.38 "Анатолий Кулаков" Преимущество этого метода, безусловно, в том, что он мега простой, а также в том, что вся работа происходит в Compile Time.
+3261.38 3267.02 "Анатолий Кулаков" Поэтому в Runtime вы абсолютно не теряете никаких перформансов на Reflection или еще какие-то глупости.
+3267.02 3271.02 "Анатолий Кулаков" В общем, все это компилятор заботливо прописывает для вас.
+3271.02 3275.26 "Анатолий Кулаков" Может быть, даже можно это сравнить с первым прототипом кода генерации.
+3275.26 3286.22 "Анатолий Кулаков" Да, мы сейчас любим все коды генератора писать, которые на Compile Time, на Build Time возлагают различные действия, которые Reflection раньше делал в Runtime.
+3286.22 3298.70 "Анатолий Кулаков" Ну так вот, вот эти Informational атрибуты - это были как раз первые шаги к тому, чтобы сделать Source Code генерации в шарпах.
+3298.70 3305.10 "Анатолий Кулаков" Атрибуты прекрасные, работают великолепно, но у них есть ограничения.
+3305.10 3313.34 "Анатолий Кулаков" Во-первых, они показывают только строчку, которая вызвала этот метод.
+3313.34 3320.74 "Анатолий Кулаков" С помощью них невозможно определить, допустим, а где сам метод начался или где этот метод закончился, который вызывает наш метод.
+3320.74 3324.26 "Анатолий Кулаков" Нет, только та строчка, которая наш метод вызвала непосредственно.
+3324.26 3327.28 "Анатолий Кулаков" Также они требуют изменения сигнатуры.
+3327.28 3353.46 "Анатолий Кулаков" Хорошо, когда мы можем поменять сигнатуру, допустим, это наш код, или нам не страшно почему-то поменять сигнатуру, может, это какой-то breaking change бинарный из-за этого получится, в общем, нас все это не пугает, но не всегда мы можем менять сигнатуру, тем более, если мы говорим про какую-то цепочку, допустим, нам необходимо узнать имя этого метода, не непосредственно того, кто нас вызвал, а вот прям 10 вызовов наверх.
+3353.46 3360.90 "Анатолий Кулаков" Нам придется или все 10 методов менять и прокидывать этот параметр, или иначе это работать не будет.
+3360.90 3373.66 "Анатолий Кулаков" Также мы не можем извлечь подобную информацию из вообще произвольного метода, который у нас есть, только тот, кто специально подготовлен и специально размечен атрибутами.
+3373.66 3383.38 "Анатолий Кулаков" Ну и самое главное ограничение, это, конечно, мы не можем извлечь эту информацию в рантайме, то есть все атрибуты материализуются именно в compile-time.
+3383.38 3389.02 "Анатолий Кулаков" И вот здесь на помощь к нам приходит альтернативный способ, а называется он pdb-файлы.
+3389.02 3410.02 "Анатолий Кулаков" А pdb-файлы, хочется сказать, что каждый знает, что это такое и как они используются, но я вот задумался, что реально они применяются только отладчиками, и наверняка существуют разработчики, которые почему-то или никогда не запускали отладчик, или никогда не задумывались о как отладчик работает вообще, и может быть даже не сталкивались никогда с pdb-файлами.
+3410.02 3430.70 "Анатолий Кулаков" Но наверняка, если вы компилировали ваш проект, то наверняка вы рядом со своими DLL-ками могли увидеть файлы с расширением pdb, которые называются так же как DLL-ка, только у них расширение другое - pdb, и любопытный ум наверняка заставлял вас погуглить, а что же такое за артефакты, почему они порождаются в моей директории, хотя я об этом не просил.
+3430.70 3451.30 "Анатолий Кулаков" pdb - это Program Database File, это специальный файлик, в котором хранится отладочная информация, потому что когда компилятор работает, он преобразует ваш исходный код именно в оптимизированный IL-код, и оптимизированный он в том смысле, что из него удаляется вся ненужная информация.
+3451.30 3457.42 "Анатолий Кулаков" А что такое с точки зрения рантайма, с точки зрения дотнета и рабочего кода ненужная информация?
+3457.42 3471.94 "Анатолий Кулаков" Ну как раз то, в каком файле изначально лежали ваши классы, в какой строчке изначально был задекларирован ваш метод и прочие вот эти глупости, которые вам нужны только для того, чтобы в IDE каким-то образом редактировать текстовые файлы.
+3471.94 3479.38 "Анатолий Кулаков" В рантайме все эти текстовые файлы не нужны, поэтому в исходном IL-коде этой информации не существует.
+3479.38 3491.58 "Анатолий Кулаков" Но эта информация крайне важна для дебаггера, потому что дебаггеру как раз таки важно, в какой строчке вы упали, какая переменная, в какое значение имела в этот момент и так далее и тому подобное.
+3491.58 3497.02 "Анатолий Кулаков" И вот специально для отладки существует программ database файл.
+3497.02 3508.98 "Анатолий Кулаков" Вот эти PDB-шечки, в которых сохранена полная ассоциация вашего IL-кода, даже не ассоциация, а маппинг вашего IL-кода обратно в source коды, то есть можно практически провернуть фарш назад.
+3508.98 3512.94 "Анатолий Кулаков" Что же в этих PDB-файлах есть?
+3512.94 3518.74 "Анатолий Кулаков" Во-первых, это полные пути к файлам, которые у вас там на диске лежат.
+3518.74 3533.18 "Анатолий Кулаков" Дальше это номера строк всех инструкций, ну IL-инструкций, опять же которые у нас есть в IL-коде, их можно развернуть и узнать из какой строки в исходном коде породилась целеная инструкция.
+3533.18 3542.18 "Анатолий Кулаков" Названия локальных переменных, которые опять же в рантайме никакого смысла не имеют, но вот для отладки крайне важны, а также имена методов и их сигнатуры.
+3542.18 3549.06 "Анатолий Кулаков" В Дотнете есть два типа PDB-файлов, это Windows PDB и Portable PDB.
+3549.06 3559.90 "Анатолий Кулаков" Windows PDB, как понятно из названия, поддерживается только в операционной системе Windows и это традиционный путь формирования PDB-шек, который был еще в большом Дотнет-фреймворке.
+3559.90 3570.26 "Анатолий Кулаков" Естественно, как только пришел Дотнет Корр, то Windows PDB стало немножко не хватать, потому что отлаживаться хотелось как бы и на Линуксах тоже.
+3570.26 3580.18 "Анатолий Кулаков" И вот на смену ему пришел Portable PDB, это кроссплатформенный формат, который по смыслу тот же самый, но по формату другой.
+3580.18 3618.46 "Анатолий Кулаков" Работает он везде, Windows, Linux, macOS, и при этом у команды Microsoft было время немножко передумать этот формат, так как в Windows PDB-шки появились довольно давно, у них уже накопилось там какое-то легаси наследие, то когда передумывался формат под кроссплатформенный, там учли все те ошибки, которые раньше были в Windows PDB и он стал намного меньше, намного эффективнее, понятнее и проще, потому что это различные инструменты, теперь могли читать его гораздо проще, чем это было с Windows PDB.
+3618.46 3625.10 "Анатолий Кулаков" Естественно, Portable PDB это рекомендуемый формат для современных Дотнет-приложений и в принципе именно он включен по умолчанию.
+3625.10 3632.78 "Анатолий Кулаков" В то же самое время вы можете сконфигурировать каким образом PDB-шки будут распространяться с вашим приложением.
+3632.78 3639.86 "Анатолий Кулаков" Есть два способа распространения PDB-шек, мы уже выяснили, что у нас есть Portable PDB, теперь как их можно распространять.
+3639.86 3645.74 "Анатолий Кулаков" Во-первых, их можно распространять с помощью отдельного PDB-файла и это поведение по умолчанию.
+3645.74 3652.06 "Анатолий Кулаков" Как я уже говорил, многие из вас рядом с DLL видели файлик PDB, это есть как раз отдельный файл.
+3652.06 3667.50 "Анатолий Кулаков" Достигается это, причем это поведение используется по умолчанию, так же можно достичь, если включить в проект на файле элемент DebugType Portable и тогда как раз PDB-шки будут сохраняться в отдельном файле рядом с DLL.
+3667.50 3685.70 "Анатолий Кулаков" Второй способ, который включается элементом DebugType Embedded называется Embedded PDB и в этом случае PDB-шки встраиваются непосредственно в вашу сборку, то есть не появляется отдельного файла, а вся необходимая информация просто дописывается к вашей DLL.
+3685.70 3695.90 "Анатолий Кулаков" Это делает диплоймент гораздо легче, то есть распространение этих PDB-шек гораздо легче, но при этом естественно увеличивает размер вашей DLL.
+3695.90 3697.82 "Анатолий Кулаков" Какая проблема с диплойментом?
+3697.82 3718.94 "Анатолий Кулаков" Обычно, когда вы запихиваете в ваш Nuget пакет DLL, то вы не хотите там видеть чего-то другого, вы не хотите видеть там лишней информации, потому что для работы вам нужны DLL-ки, а всякие PDB-шки или может быть XML-документация или еще что-то - это лишняя нагрузка, лишний размер, лишние проблемы.
+3718.94 3722.58 "Анатолий Кулаков" И многие разработчики добавляют PDB-шки к DLL-кам.
+3722.58 3746.98 "Анатолий Кулаков" Поэтому когда вы ставите какой-то пакет из Nuget, то и ошибка случается именно внутри какой-то той библиотеки, которая пришла с этим пакетом, то практически нереально было этот пакет раздебажить, то есть нельзя было посмотреть, в каком исходном коде, как выглядел тот исходный код, в котором случилась ошибка у вас в рантайме, что там были за методы, какие у них были сигнатуры, всей этой информации не было.
+3746.98 3756.06 "Анатолий Кулаков" Как раз потому, что DLL-ки и PDB-шки являлись физически разными файлами и не всегда их можно было где-то достать, где-то скачать.
+3756.06 3765.02 "Анатолий Кулаков" Начали появляться всякие PDB-сервера, это что-то похожее на Nuget, но там уже хранились не пакеты, а хранились только PDB-шки и прочие-прочие костыли.
+3765.02 3778.42 "Анатолий Кулаков" В общем, для того, чтобы вообще эту проблему нивелировать, устранить ее физически, как раз был принят такой режим у Микрософта, как Embedded, который просто позволяет вам встроить эту информацию внутрь DLL-ки.
+3778.42 3801.22 "Анатолий Кулаков" Если раньше с Windows PDB это была довольно сомнительная идея, потому что они реально были больше, то есть PDB-шки там были огромные и встраивание в DLL-ку приводило к значительному росту этих DLL-ик, то portable PDB в принципе довольно компактный и сильного размера вы не увидите.
+3801.22 3804.62 "Анатолий Кулаков" Ну, опять же, если у вас DLL-ки огромные, то конечно разница будет.
+3804.62 3823.26 "Анатолий Кулаков" Но в общем случае, опять же, по сравнению с теми преимуществами, которые она дает, то есть вы по сути можете отлаживать абсолютно любую DLL-ку, которую поставили из Nuget, абсолютно любой пакет, без всяких заморочей, совместимости, протоколов, настроек и прочее-прочее.
+3823.26 3829.34 "Анатолий Кулаков" В общем, это дорогого стоит, особенно если у вас там большая огромная компания, куча пакетов, куча сервисов.
+3829.34 3835.14 "Анатолий Кулаков" Да, добавка несколько килобайт к вашей DLL-ке большой истории никакой не сыграет.
+3835.14 3839.26 "Анатолий Кулаков" В общем, очень хороший, интересный дебаг-тайп.
+3839.26 3845.74 "Анатолий Кулаков" Рассмотрите его использование в ваших проектах, может быть вас очень сильно упростится отладка от этого.
+3845.74 3854.62 "Анатолий Кулаков" Теперь погнали дальше, разобрались, что существуют два способа распространения PDB-шек, как же нам теперь все-таки в рентайме всю эту информацию прочитать.
+3854.62 3861.42 "Анатолий Кулаков" Читается очень просто, для этого существует отдельный пакет, ну естественно, что же еще могло быть.
+3861.42 3863.94 "Анатолий Кулаков" System Reflection Metadata приходит к нам на помощь.
+3863.94 3868.58 "Анатолий Кулаков" System Reflection Portable Executable API.
+3868.58 3882.62 "Анатолий Кулаков" Прежде всего, в вашем коде вам необходимо найти PDB-шки, для этого используется обычный метод инфа, то есть у метода инфа есть Declaration Type, там есть Assemblies, Assemblies Location, который там нам рассказывает, где эта вообще сборка лежит.
+3882.62 3888.46 "Анатолий Кулаков" У этой сборки мы можем вызвать PE-ридер и с помощью PE-ридера уже поискать.
+3888.46 3898.70 "Анатолий Кулаков" PDB-шка там встроенная, если она встроенная, то лучше использовать именно ее, или там PDB-шка в виде отдельного файла лежит.
+3898.70 3907.22 "Анатолий Кулаков" Для этого есть тоже отдельный метод TryOpenAssociatedPortablePDB, который нам позволяет ассоциированную рядышком с DLL-кой PDB-шку тоже поискать.
+3907.22 3913.22 "Анатолий Кулаков" После того, как мы PDB-шку нашли, мы можем уже извлечь какую-то дебаг-информацию из нее.
+3913.22 3923.62 "Анатолий Кулаков" Для этого у DBReaderProvider есть метод getMethodDataReader и getDebugInformation.
+3923.62 3931.02 "Анатолий Кулаков" Этой дебаг-информации достаточно для того, чтобы абсолютно любой ILL-код смапить, как я уже говорил, с исходным source-файлом.
+3931.02 3940.34 "Анатолий Кулаков" Для этого достаточно вызвать метод getSequencePoints, он как раз в терминах выдает список, секвенс всех инструкций.
+3940.34 3964.90 "Анатолий Кулаков" И обычно, если вы берете, например, первую инструкцию, то это как раз открывающая скобка у вашего метода, или первая запускаемая линия строка, первая запускабельная строчка у вашего метода, поэтому вы легко можете определить, например, с какой инструкции метод начинается, и проанализировав другие инструкции, можете полностью понять, где он заканчивается, какие вызовы внутри метода будут и так далее.
+3964.90 3980.70 "Анатолий Кулаков" В общем, благодаря вот этим несложным действиям мы можем узнать имя метода, полный путь к файлу, который есть на вашем диске, номер строки и номер колонки, где находится та инструкция, тот символ, который мы сейчас как бы выили пытаемся происследовать.
+3980.70 3987.06 "Анатолий Кулаков" И все это из метод.info с помощью метода reflection прекрасно достается.
+3987.06 3998.82 "Анатолий Кулаков" И можно его использовать для каких-то ваших нужд, для какого-то вашего инструментария, если вы пишете там свой дебаггер, свой тестовый фреймворк или для какого-то интеллектуального логирования.
+3998.82 4000.94 "Анатолий Кулаков" В общем, все это доступно.
+4000.94 4001.94 "Анатолий Кулаков" И это хорошо.
+4001.94 4019.90 "Анатолий Кулаков" Можно было бы двинуться дальше, и PDB-шки еще умеют такую интересную штуку, что они внутри себя могут хранить не только путь к локальному файлу, потому что на самом деле это довольно бесполезная информация.
+4019.90 4026.42 "Анатолий Кулаков" У каждого уважающего себя интерпрайс-пайплайна есть билд-сервер.
+4026.42 4031.34 "Анатолий Кулаков" У билд-сервера, естественно, все пакеты должен собирать этот билд-сервер.
+4031.34 4035.14 "Анатолий Кулаков" И у билд-сервера все пакеты собираются на его локальном диске.
+4035.14 4043.54 "Анатолий Кулаков" И когда вы прочитаете PDB-шку этого билд-сервера, вы просто увидите, что там на диске С какая-нибудь есть папочка build и там лежит какой-то файлик.
+4043.54 4058.54 "Анатолий Кулаков" Довольно бесполезная информация, потому что непонятно, на каком диске С, почему он там лежит, как это ассоциировать с теми файликами, которые, допустим, лежат в нашем корпоративном гид-репозитории.
+4058.54 4063.98 "Анатолий Кулаков" В общем, вот эта информация довольно бесполезная становится.
+4063.98 4081.66 "Анатолий Кулаков" Поэтому у билд-степа есть специальный шаг, который заменяет вот это значение в Portable Database, значение пути файла, который лежит на вашем локальном диске, тем значением, которое соответствует вашему корпоративному гид-репозиторию.
+4081.66 4097.70 "Анатолий Кулаков" То есть у вас уже PDB-шка показывает, что файл лежит не на диске С в папочке build, а дает прямо аж типичный путь, куда вам там на GitHub надо пройти, в этом GitHub есть такое-то репозиторий, в таком-то репозитории в такой-то папочке лежит вот этот файл.
+4097.70 4107.14 "Анатолий Кулаков" И в этот момент ваша IDE может этот файл пойти и скачать прямо из GitLab или из GitHub.
+4107.14 4110.02 "Анатолий Кулаков" Для того, чтобы его начать дебажить.
+4110.02 4125.58 "Анатолий Кулаков" Здесь есть еще одна интересная тонкость, можно таким образом указать не только файл, но и указать версию коммита или бранча, то есть вы можете полностью контролировать полную историю.
+4125.58 4147.78 "Анатолий Кулаков" Допустим у вас есть два пакета, версии 1 и версии 2 и вы можете поставить, допустим, пакет версии 1, который вышел год назад и при этом все его исходники будут по-прежнему дебажиться, будут по-прежнему работать, потому что в этот пакет вместе с файлом был включен коммит, из которого этот файл собрался, из которого этот пакет был собран.
+4147.78 4160.86 "Анатолий Кулаков" Таким образом ваша IDE способна скачать, допустим, коммит годовалой давности и предоставить вам тот файл, который был год назад, из которого собирался именно вот этот тот самый пакет, который просроченный и все такое.
+4160.86 4180.78 "Анатолий Кулаков" В общем, это очень мощный механизм, в нем для отладки можно настраивать очень крутые вещи, которые позволяют вам отлаживать там из разных версий, из разных эпох, из различных проектов, из различных репозиторий, все это абсолютно прозрачно и IDE умеет это полностью затаскивать сама.
+4180.78 4194.62 "Анатолий Кулаков" К сожалению, Эндрю Лок, нет, Баррэ у нас, это Геральд Баррэ про это не написал, но может быть у него будет какая-нибудь отдельная статья как PDB-шки про патчить для работы с удаленными репозиториями.
+4194.62 4198.30 "Анатолий Кулаков" Он пока остановился на том, а как в рентайме с ними работать.
+4198.30 4201.80 "Анатолий Кулаков" Ну и в принципе это тоже хорошая, понятная, законченная тема.
+4201.80 4214.34 "Анатолий Кулаков" Итак, давайте подытожим, если вам нужно просто-напросто в compile-time собирать информацию о методе файли и строчки, то для этого есть колер информейшн атрибуты.
+4214.34 4216.38 "Анатолий Кулаков" Прекрасная штука, которая хорошо работает.
+4216.38 4231.62 "Анатолий Кулаков" Если же вам нужна эта информация в рентайме и вы при этом не хотите изменять сигнатуры тех методов, из которых вы хотите получать информацию, то есть portable PDB, которые всю эту информацию вам могут предоставить.
+4231.62 4245.94 "Анатолий Кулаков" Здесь еще одна тонкость, которой стоит учесть, что в продакшене иногда, или может быть даже правильнее сказать почти всегда, выключают PDB-шки, потому что в продакшене они очень часто не нужны.
+4245.94 4264.26 "Анатолий Кулаков" Есть исключения, допустим, в то время, когда у вас бросаются эксепшены, то эксепшены тоже часто используют PDB-шки и выводят полезную информацию о стейке, о номере строки, имя файла, в общем, эксепшены и всякий диагностик тулзы.
+4264.26 4292.42 "Анатолий Кулаков" Эту информацию тоже используют, но многие эту информацию исключают из продакшен-кода для того, чтобы DLL-ки были меньше, для того, чтобы перфоманс был лучше и для того, чтобы улучшить security тем моментом, что не будет какой-то лишней информации, из которой злоумышленник может сделать выводы о ваших проектах, о структуре вашего репозитория и о правильных названиях и правильных именах.
+4292.42 4301.02 "Анатолий Кулаков" В общем, перфоманс и security часто бывают теми причинами, из-за которых PDB-шки в продакшен не складывают.
+4301.02 4309.78 "Анатолий Кулаков" Поэтому, если ваше приложение рассчитывает на наличие PDB-шек, то нужно позаботиться о том, чтобы в продакшене они были.
+4309.78 4312.42 "Анатолий Кулаков" Ну и, естественно, при этом учесть все security перфомансовиски.
+4312.42 4315.46 "Анатолий Кулаков" В общем, тоже такой немаловажный шаг.
+4315.46 4319.86 "Анатолий Кулаков" Ну, хорошая техника и интересный способ работы.
+4319.86 4323.22 "Анатолий Кулаков" И, как я уже сказал, PDB-шки у нас у всех всегда под рукой.
+4323.22 4327.90 "Анатолий Кулаков" Может быть, у вас и будут какие-то интересные сценарии, где вам эта информация еще понадобится.
+4327.90 4347.54 "Игорь Лабутин" Мне кажется, было довольно большое количество у меня приседаний со всякими PDB-шками давным-давно, когда еще не было всех этих portable PDB, вот этих всяких source links и прочих полезных штук, которые позволяют довольно легко находить, где же исходник лежит, который был исходно собран.
+4347.54 4349.70 "Игорь Лабутин" Особенно это было еще в C++ проблемно.
+4349.70 4354.14 "Игорь Лабутин" Там как-то совсем было сложно, в Zotnet стало попроще, а сейчас совсем просто.
+4354.14 4356.78 "Игорь Лабутин" То есть сейчас я уже давно не вижу никаких особых проблем.
+4356.78 4362.66 "Игорь Лабутин" И действительно, современным разработчикам, наверное, не так часто именно сталкиваются или задумываются о том, что вообще есть какие-то PDB.
+4362.66 4370.84 "Игорь Лабутин" Просто само работает, само как-то откуда-то подгружает исходные коды из GitHub, даже с самого Zotnet, так что все стало совсем хорошо и прозрачно.
+4370.84 4372.62 "Игорь Лабутин" Tooling в этом смысле хорошо вырос.
+4372.62 4383.62 "Анатолий Кулаков" Да, я еще где-то Zotnet 3, наверное, в последний раз помню, у нас прямо доклады были о том, как патчить руками PDB-шки, чтобы они source link понимали и все такое.
+4383.62 4386.14 "Анатолий Кулаков" Сейчас Tooling делает все за нас, и это прекрасно.
+4386.14 4390.54 "Анатолий Кулаков" Хорошо, что вы все не знаете той боли, которая была раньше.
+4390.54 4391.54 "Игорь Лабутин" Да.
+4391.54 4397.70 "Игорь Лабутин" Ну чего, давай мы потихонечку будем закругляться, есть у нас еще кратко о разном, попробуем быстро пробежаться.
+4397.70 4407.90 "Игорь Лабутин" Во-первых, вышел, ну, относительно недавно новый рейтинг TIOB языков программирования, C# там подрос на целых 2 с копеечками процентов.
+4407.90 4417.70 "Игорь Лабутин" Но основная новость, из-за которого этот самый рейтинг стали обсуждать в интернете несколько недель назад, это про то, что Гошечка упала с седьмого на шестнадцатую позицию.
+4417.70 4420.46 "Игорь Лабутин" Типа все, о, Го теряет популярность, вот это все.
+4420.46 4432.66 "Игорь Лабутин" Но на самом деле, как и любой рейтинг языков программирования, каждый из них имеет свои недостатки, обычные эти недостатки связаны с тем, как этот рейтинг собирается, конкретно TIOB собирается из популярности запросов в гугле.
+4432.66 4447.78 "Игорь Лабутин" И, вероятно, такое падение популярности Гошки связано с, возможно, с тем, что просто Гошники пошли в LLM-ке выуглить и искать ответы, и в итоге в гугле частота запросов на тему Го сильно упала.
+4447.78 4455.70 "Игорь Лабутин" Возможно, никто не знает, но шарписты все еще пока гуглят и используют LLM.
+4455.70 4466.84 "Игорь Лабутин" Выводы примерно такие, это обзор этой штуки есть у Жени Пешкова небольшой, там же есть ссылки на разные другие рейтинги языков программирования, можно посмотреть в его канале по ссылочке.
+4466.84 4475.70 "Игорь Лабутин" Дальше, если вы живете в AWS, то можете радоваться, в AWS лямпоты завезли дот над 10 рантайм, в Яндексе, к сожалению, по-моему, до сих пор восьмерка, в фанкшнс.
+4475.70 4481.26 "Игорь Лабутин" Вот недавно что-то туда деплоил и там пока только восьмерка.
+4481.26 4484.66 "Игорь Лабутин" Дальше, появился интересный тул.
+4484.66 4495.86 "Игорь Лабутин" Если вы пользуетесь продуктами JetBrains, то вы знаете, конечно же, про JetBrains Toolbox, штука, которая позволяет поставить, пообновлять и прочие разные версии IDE-шек разных.
+4495.86 4499.26 "Игорь Лабутин" Для Visual Studio такого никогда не было, но теперь появился.
+4499.26 4514.86 "Игорь Лабутин" Это некоторый сторонний тул, он на GitHub лежит, называется Visual Studio Toolbox, написан на 13 C# и 10 дотнете, с помощью WinUI 3 и MVVN Community Toolkit можно посмотреть, как пишутся более-менее современные дотнет-приложения с UIK.
+4514.86 4523.90 "Игорь Лабутин" Он полностью open-source и позволяет, собственно, управлять теми версиями Visual Studio, которые у вас поставлены, обновлять их, смотреть, куда они поставились, удалять и так далее.
+4523.90 4528.90 "Игорь Лабутин" Может быть полезно, если вы держите несколько разных версий на одном машинке.
+4528.90 4532.38 "Анатолий Кулаков" А зачем нужно держать несколько студий на одной машинке?
+4532.38 4545.38 "Игорь Лабутин" Ну не знаю, вот у меня одно время стояло 19-е, 22-е Professional, 22-е Community, ну по-моему всё.
+4545.38 4547.38 "Анатолий Кулаков" Ты забыл удалить их просто или что?
+4547.38 4552.90 "Игорь Лабутин" Нет, ну 19-шка была нужна, не помню зачем, ну как-то сложилось, нужна была, в общем.
+4552.90 4558.70 "Игорь Лабутин" 22-е Professional была моя основная рабочая, а в 22-е Community она была настроена чисто на плюсы.
+4558.70 4569.34 "Анатолий Кулаков" Да, я вот тоже помню, что в последний раз держал какие-то старые студии для того, чтобы плюсы там хорошо компирировались, и только под неё были какие-то библиотеки.
+4569.34 4584.78 "Игорь Лабутин" Я просто почему-то поставил в 22-е отдельную комьюнити под плюсы, потому что я помнил из какого-то своего старого опыта на прошлом ноуте, я когда основную 22-ю свою начал туда плюсовые всякие компоненты добавлять, что-то у меня в зубной не сломалось, я помню.
+4584.78 4589.62 "Игорь Лабутин" Ну может быть это сломалось не потому, что плюсовые компоненты, а потому что я тронул инсталлер и что-то не сломалось.
+4589.62 4595.74 "Игорь Лабутин" Вот, но я решил, что когда мне в следующий раз потребовались снова плюсы, я решил, что пусть это будет в отдельном инстансе.
+4595.74 4615.06 "Игорь Лабутин" Понятно, что там дофига шарят всякие компоненты в любом случае, и мало ли, что там за дело, но в общем, если вы, а если вы ещё на каком-то превью канале сидите и смотрите на превьюшные версии, то почему нет, вот вам тулбокс, соответственно, будет вам всё это в едином окошке обновлять, инсталлить, ну не знаю, может кому-то удобно.
+4615.06 4678.34 "Игорь Лабутин" Так, и опять же из таких микротулов в каком-то смысле, мы знаем, мы много раз уже упоминали, что в дотнете есть понятие dotnet global tool, но если вы фанат пауэршелла и вы хотите всё вызывать из пауэршелла, то есть проектик, который делает, грубо говоря, дотнетные команды доступны в виде пауэршельных cmdlets, то есть командлетов, у вас будет командлеты типа new.netproject, new.netsolution, add.netpackages и так далее, которые можно вызывать нативно из пауэршелла, пайпами их объединять, то есть вы сможете написать там типа $s присвоить new.netsolution, потом $s pipe new.netproject, pipe add.netpackages, pipe add.netproject reference и так далее. Короче, будете жить прямо в нативном пауэршелле. Понятно, что это всё ещё MVP, но если вы фанат пауэршелла, то можете посмотреть, может
+4678.34 4777.52 "Анатолий Кулаков" заинтересует. Конечно, конечно, Ратим, конечно, фанаты, надо смотреть. У меня тоже есть парочка статей, первая статья, которую хотелось бы упомянуть, это статья на хабре, навыки, которые вы потеряли, которые вы теряете пока и берет на себя рутинные задачи. В общем, тоже интересная точка зрения, она многим приходила в голову, что пока мы скидываем все свои рутинные задачи на ишечку, мы в этот момент что-то теряем. И в принципе не наша индустрия первая с такой проблемой столкнулась, у музыкантов есть термин отпускные руки, это когда музыкант после отпуска начинает играть, но начинает играть медленно, то есть он не забывает как играть, а он забывает как играть хорошо. Такие же проблемы есть, например, у авиации, много есть и авиационных исследований, которые показывают деградацию навыков, вызванную автоматизацией, и она случается из-за того, что у авиапилотов начинается зависимость от автопилота, у авиапилотов зависимость от автопилота. В общем, и тоже деградация навыков происходит. И вот эти самые утомительные моменты нашей разработки, когда мы пишем какой-то рутинный код, когда мы пишем тесты, от чего мы как раз хотели всегда избавиться, в общем, они на самом деле, получается, что не только составляют нашу ненужную, неинтересную рутину, они являются вот этой точкой обучения и тренировки. И вот эту как раз точку обучения и точку тренировки мы вот и скипнули, мы ее на ИИшку переложили.
+4777.52 4878.00 "Анатолий Кулаков" Поэтому происходит атрофия. Самое плохое моменто в этой штуке это то, что атрофия невидима для человека, который ее использует. Поэтому навыки уходят потихонечку, постепенно, и этого никто не замечает. И ваши показатели скорости может быть даже и растут, но ваши реальные возможности снижаются. Поэтому ИИ может ускорить снижение квалификаций экспертов и затруднить приобретение новых навыков. Что же делать? Что делать, как раз вы можете почитать и в статье. Как с этим эффектом бороться, как при этом не отказываясь от и не становиться более глупым, как говорится. Там есть интересные ссылки, интересные исследования, цифры. И также есть мнение о том, что в принципе может все это плачь по перфокартам и программисты должны становиться тупее, выходить на новый уровень и заниматься другими вещами, а не вот этой всякой дурацкой рутиной и сожалеть и плакать о ней совсем не стоит. В общем, такое мнение тоже есть, но как бы интересно посмотреть и почитать разные стороны. И данная статья отлично написана, хорошо читается и приводит вполне интересные аргументы. Поэтому, если вы используете Ишку или, по крайней мере, задумываетесь об этом, хотя бы посмотрите, что вас может ожидать и чтобы вы были к этому готовы. Следующая новость - это в том, что XAML-студия теперь в open-source. XAML-студия - это студия, которая помогала разработчикам писать XAML-разметку.
+4878.00 4919.88 "Анатолий Кулаков" Она была сделана для WinUI. Восемь лет назад где-то она стартанула. Там есть Live Editor, дебаггер байнингов, Data Context Editor, IntelliSense. В общем, хорошая такая отдельная студия, естественно, с превью, которая очень легкая, очень компактная, красивая. В общем, хорошо, что за open-sourceless она продолжает свое развитие, никуда не делась. В принципе, авторы говорили, что они изначально ее писали для того, чтобы за open-source, но дошли к этой точке почему-то только через восемь лет. В общем, поэтому если вдоволь друг пишете, используйте XAML в своей UI-разработке, то, наверное, тоже должны радоваться такой новости.
+4919.88 4945.80 "Игорь Лабутин" Интересно, что у нас потихонечку, мне кажется, то там, то здесь пробиваются какие-то новости про мир UI в дотнете. Может быть, все-таки, у нас будет какая-то большая движуха, особенно, смотри выше, про коллаборацию на платформах Microsoft, MyUI, вот это все. Может быть, все-таки, что-то разовьется в более интересное. Ну, посмотрим, вот еще один тул, open-sourceless, тоже приятно. Поглядим.
+4945.80 4986.48 "Игорь Лабутин" Так, на сегодня будем заканчивать. Мы обсудили сегодня состояние веб-ассамблеи за двадцать пятый, двадцать шестой года. Ну, план, точнее, понятно, двадцать шестой год. Поговорили о том, что не spnadcore не единым, живь в дотнете есть другие фреймворки, если вам вдруг, внезапно, почему-то расхотелось использовать spnadcore. Поговорили о том, что такое софтвер белого материала, как его создавать и почему Snuget'ом это пока, ну, не до конца дружит. Узнали немножко про PDB'шки, зачем они могут быть нужны, полезны и вообще что это такое. Ну, и поговорили про какие-то небольшие краткие темы. На этом на сегодня, я думаю, все.
+4986.48 5001.28 "Анатолий Кулаков" Все, всем до новых встреч. Заходите и комментируйте наши подкасты на ютубчике. Ставьте там лайки, звездочки в тех платформах, где вы нас слушаете, а также рассказывайте друзьям и до новых встреч, всем пока.
+5001.28 5001.80 "Игорь Лабутин" Всем пока.