.NET *

Как добиться успеха в системном программировании, что нужно знать и понимать, особенно если ты работаешь уже третий десяток лет? C# и перформанс — cтоит ли переписывать на C# всё что видишь? Какое будущее в смысле низкоуровневых компиляторных технологий нас ждёт?

Сегодня в нашей виртуальной студии на вопросы отвечает Alexandre Mutel.

Alexandre Mutel работает на должности Lead Software Architect в Unity Technologies. Кроме того, он известный в опенсорсе разработчик, контрибутящий в SharpDX, Markdig, Zio и другие проекты, а с 2014 года — MVP в категории «Visual Studio and Development Technologies».

Alexandre работает над разными низкоуровневыми и высокоуровневыми вопросами в областях рендеринга графики в реальном времени, GPGPU, синтеза звука, эффективного использования и архитектуры управляемых языков, кодогенерации и документации.

Как всегда, интервью ведут Евгений Трифонов (phillennium) и Олег Чирухин (olegchir) из JUG.ru Group.

В конце поста есть сюрприз от Дилана Битти (другого известного дотнетчика) — мы и сами не ожидали.

Автор статьи — Мэдс Торгерсен, ведущий архитектор C# в Microsoft

Проект Roslyn

Roslyn — это кодовое название, которое закрепилось за open-source компилятором для C# и Visual Basic.NET. Проект начинался в самой глубокой тьме последнего десятилетия корпоративной жизни Microsoft — и завершился как проект с открытым исходным кодом, кросс-платформенный, публичный универсальный движок для C# (и VB, что я приму как данность в остальной части статьи).

Первые разговоры о проекте, который впоследствии станет известен как Roslyn, уже шли, когда я пришёл на работу в Microsoft в 2005 году — незадолго до выпуска .NET 2.0. Шёл разговор о переписывании C# на C#. Это нормальная практика для языков программирования — доказательство зрелости языка. Но была и более практичная и важная мотивация: мы, создатели C#, сами не программировали на C#, мы программировали на C++! Если же ежедневно программировать на C#, то вы меняете своё мнение: великая сила работы на том инструменте, какой разрабатываете (dogfooding).

В этой статье я расскажу, как реализовать кроссплатформенное приложение на .NET Core и Avalonia. Тема Телеграма очень популярна в последнее время — тем интереснее будет сделать клиентское приложение для него.

Статья затрагивает достаточно базовые концепции разработки на Avalonia. Тем не менее, мы не будем писать "Hello, World". Вместо этого предлагается рассмотреть реальное приложение. Изучим как общую архитектуру приложения, так и отдельные компоненты.

Чтобы не злоупотреблять вниманием читателя, в некоторых случаях придется сознательно опустить некоторые детали, упростив описание и реализацию. Реальный же код всегда можно посмотреть на GitHub.

Текст статьи носит обучающий характер, но сам проект вполне реальный. Целью проекта является создание клиента, рассчитанного на использование в качестве рабочего инструмента. Множество идей позаимствовано из других мессенджеров и переложено на модель Telegram.

Путь к постижению Дзена начинается с разработки приложений, которые могут мониторить сами себя — это позволяет проще и дешевле чинить проблемы на продакшне. В этой статье мы увидим, как современные Windows-приложения могут делать самомониторинг, самодиагностику, и возможно — даже самовосстановление, и всё это — без необходимости иметь внешний агент или тупо перезапускать приложение. Обуздав мощь ETW для точного низкоуровневого мониторинга, счетчики производительности Windows для получения бесплатной по ресурсам статистики и библиотеку CLRMD для анализа собственных потоков, объектов в куче и локов, можно продвинуться по пути достижения самосознания. Всё это будет продемонстрировано на серии демок: автоматический профайлинг CPU, исследование загруженных тредов и стеков, автоматический мониторинг GC (включая выделения объектов), автоматический анализ кучи в целях поиска утечек памяти и многое другое. Дочитав статью до конца, вы получите набор инструментов и техник для реализации самомониторинга в своих собственных приложениях.

Основой статьи является доклад Дины Гольдштейн «Self-aware applications: automatic production monitoring» на DotNext 2017 Moscow. Слайды можно скачать по ссылке.

В прошлом году конференция DotNext проходила в Москве один день, а в этом стала двухдневной. Теперь, когда очередной московский DotNext позади, а зрители прислали свой фидбэк, время оглянуться: как всё прошло, и что вошло в увеличившийся хронометраж? Подробности под катом, а для затравки скажем, что слово «performance» оказалось актуально в обоих значениях: и «производительность», и «художественное выступление».

Представляем интервью с ведущими экспертами в области безопасности: Владимиром Кочетковым (руководителем отдела исследований анализа защищенности приложений в Positive Technologies) и Михаилом Щербаковым (независимым разработчиком и консультантом в области информационной безопасности).

О чем эта статья? Процитирую одну из реплик Михаила:

«Разработка защищенного приложения – это частный случай разработки приложения, не содержащего ошибок вообще. Кроме этого, ваше приложение использует сторонние библиотеки, защищенность которых тоже не гарантируется, далее оно выполняется на ОС и железе. Часто мы даже не можем сказать, на какой именно ОС и на каком железе. И все это со временем изменяется!»

Представляем вам последнюю статью из цикла по разработке на ASP.NET Core. В данной статье вы узнаете как можно написать свое первое приложение ASP.NET Core на Mac.

Недавно я работал над новой C#-диагностикой V3119 для статического анализатора PVS-Studio. Назначение диагностики — выявление потенциально небезопасных конструкций в исходном коде C#, связанных с использованием виртуальных и переопределенных событий. Давайте попробуем разобраться: что же не так с виртуальными событиями в C#, как именно работает диагностика и почему Microsoft не рекомендует использовать виртуальные и переопределенные события?

Что такое C#? Объектно-ориентированный эсперанто со сборщиком мусора, функциональными примочками и бесплатным массажем после обеда. Он позволяет писать Действительно Важные Вещи, скрывая от нас ненужные детали работы с памятью, процессором и прочее низкоуровневое программирование. Естественно, находятся люди с повышенным уровнем любопытства в крови, желающие знать как же .NET работает на самом деле (само собой, они изучают .NET исключительно ради повышения производительности разрабатываемого софта). Сегодня с нами разговаривают:

Совсем недавно мы выпустили новую версию нашего анализатора PVS-Studio с поддержкой проверки C# проектов. Пока на время релиза дальнейшая разработка продукта была приостановлена, я занимался тестированием анализатора. В качестве проектов для своих экспериментов я взял IronPython и IronRuby. А раз эти проекты были проверены, я решил написать небольшую статью-отчёт.

IronPython и IronRuby

IronPython и IronRuby представляют собой реализацию языков программирования Python и Ruby на платформе .NET. Исходный код этих проектов доступен на GitHub по этой ссылке. Также в комплекте идёт исходный код DLR. Начиная с .NET Framework 4.0 DLR является его частью, и IronPython и IronRuby используют её. Тем не менее я всё равно проверил старую версию DLR, раз уж она там оказалась.

Мы успешно создали и продолжаем развивать анализатор PVS-Studio для языка C/C++. Со временем стало понятно, что многие из реализованных диагностик никак не связаны с конкретным языком программирования, и тогда мы решили попробовать применить свой опыт к другому языку программирования, к C#. В данной статье будет рассказано о проверке проекта Code Contracts от Microsoft с помощью нового C# анализатора.

О проекте MS Code Contracts

Code Contracts предоставляют метод, с помощью которого выражаются предположения о коде программы в .NET приложениях. Контракты принимают форму предусловий, постусловий и инвариантов объекта, и выступают в роли проверенной документации ваших внешних и внутренних API. Контракты используются для того, чтобы улучшить процесс тестирования с помощью проверки во время выполнения программы, позволяя проводить статическую верификацию контрактов и генерацию документации.

Это анонс для всех .NET-программистов, которым интересно, что происходит с их платформой.

11 декабря в Москве пройдет .NET-конференция DotNext. Самая главная .NET-конференция на русском языке. И самая большая конфа для дотнетчиков в России. Ну и вообще, вроде как, самая большая .NET-конфа в Европе: да, есть конференции гораздо масштабнее, но чтобы вот так, чтобы именно по дотнету — пожалуй мы крупнейшие, да. В прошлом году в Москве собралось 400 участников (вместе со спикерами и организаторами — 450) и еще примерно столько же смотрели конференцию онлайн. В этом году конференция будет еще больше — мы хотим собрать на площадке 500-600 человек.



ТТДТХ! (Только технические доклады, только хардкор!)

Традиционно на DotNext много внимания будет уделено внутренностям самой платформы. Достаточно посмотреть на первые опубликованные доклады: Карлен szKarlen Симонян расскажет об атомарных операциях и Memory Model, а Андрей DreamWalker Акиньшин сделает доклад о микрооптимизациях.



Не обойдется и без прикладных (и иногда забавных) докладов. Например, Дмитрий mezastel Нестерук из JetBrains расскажет о том, как написать на дотнете своего бота.



Вообще докладов будет около 25 штук, продолжительностью 50-60 минут каждый. Если хотите попробовать себя в роли докладчика — подавайте заявку!

TL;DR: кроссплатформенный клон WPF. От других попыток сделать нечто с XAML-ом выгодно отличается наличием полностью своей системы отрисовки со сменными бакэндами (сейчас поддерживается Direct2D и Cairo). В наличии инспектор, дизайнер (см. видео). Биндинги сделаны на стероидах под названием ReactiveExtensions (старый стиль тоже можно использовать). Умеет работать с Windows/Linux/MacOS, поддержку мобильных платформ планируется добавить в начале следующего года посредством отрисовки через MonoGame.

Неделю назад я рассказал о том, что будет твориться в следующую пятницу на питерской конференции .NEXT до обеда: открытие конференции, keynote от Dino Esposito и 9 докладов. Сегодня я расскажу о том, что нас ждет во второй половине дня.

Уже давно хотел поразбираться с анализаторами на основе Розлина. Тем более, что меня уже был опыт создания плагинов для Resharper-а (R# Contract Editor Extension), поэтому хотелось сравнить разные инфраструктуры и удобство использования. Есть идея переписать этот плагин с помощью анализаторов Roslyn-а, но я решил начать с чего-то попроще.

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

• Повторная генерация исключений с помощью throw ex;
  
• “Проглатывание” всех исключений с помощью пустых блоков catch {} или catch(Exception) {}.
  
• “Проглатывание” исключений в определенных ветках блока catch.
  
• Сохранение в логгах только сообщения ex.Message, теряя при этом потенциально важную информацию о месте возникновения исключения.
  
• Некорректное пробрасывание новых исключений из блока catch.

Вначале был код

И был тот код написан на дотнете (еще версии 1.1) много лет назад. Код был простой и дубовый — где-то в дебрях проекта лежала стопка Interop*.*.DLL для еще более древних TLB. Очевидно, был заведен интерфейс, имплементирующий три с половиной метода, и рожден в муках набор реализаций, к моменту раскопок — их было шестнадцать (!) штук. Factory и прочие синглтоны — в комплекте.

Создавал тот код классический Application, и у всех 16 реализаций в интересующем нас месте код был скопипастан и идентичен — отличались лишь неймспейсы из интеропов.

Примерно вот так:

Type apptype = Type.GetTypeFromProgID("CoolAppID", false);
var app = Activator.CreateInstance(apptype) as Cool.Application;

var lib = app.Open(file, ... /* many flags */) as Cool.Library;
foreach(var asset in lib.Assets) {
    /* some long operations */
}

С тех пор код пережил много всего — переезд на дотнеты 2.0, 3.5, 4.0 и т. д. Стал поддерживать тех интеропов с двух до упомянутых шестнадцати — а код все тот же и все так же не меняется, лишь размножается почкованием иногда. Ни одного разрыва с 2007 года. Пока однажды не запустили этот код на Windows 8.1.

Для тех кто пропустил мои посты:Consulo — это форк IntelliJ IDEA Community Edition, который имеет поддержку .NET(C# на текущий момент, и на этот сектор пока идет большой акцент), Java.

В этой мини-статье я поделюсь с вами с тем, что удалось сделать за последние 2 месяца.

… Эта статья является продолжением первой части о написании расширений к студии с Roslyn.

Тут я буду описывать что делать, если мы хотим сгенерировать/поменять какой-нибудь код. Для генерации кода мы будем статические методы класса SyntaxFactory. Некоторые методы требуют указать ключевое слово/тип выражения/тип токена, для этого есть перечисление — SyntaxKind, который содержит все это вместе.

Хорошо, давайте для примера сгенерируем код, содержащий число 10. Это делается просто.

SyntaxFactory.LiteralExpression(SyntaxKind.NumericLiteralExpression, SyntaxFactory.Literal(10))

Я не шутил, когда говорил, что чтобы создать код проще всего распарсить строку. Благо, SyntaxFactory предоставляет кучу методов для этого (ParseSyntaxTree, ParseToken, ParseName, ParseTypeName, ParseExpression, ParseStatement, ParseCompilationUnit, Parse*List).

Но это не путь настоящего самурая.

Всем привет!

Пришла зима, и вот уже через неделю вслед за ней придёт и конференция .NEXT — без ложной скромности, главное .NET-событие года в России.



Несколько дней назад мы провели голосование на хабре по поводу того, какие из докладов пользуются наибольшей популярностью. Вот наиболее популярные из них:

1. 68% — Тимур timyrik20 Гуев — C# 6.0: Roslyn и другие нововведения
2. 59% — Андрей andreycha Часовских — Async/await: собираем грабли
3. 52% — Михаил Щербаков — Что и как нужно защищать в .NET-приложении
4. 52% — Dino Esposito — ASP.NET vNext: What it means to you and what it means to Microsoft
5. 49% — Роман Белов — Memory & Performance. Tips & Tricks
6. 48% — Дмитрий Иванов — Принципы построения многопоточных десктопных .NET-приложений на примере ReSharper
7. 44% — Кирилл Скрыган — Cложности создания больших приложений и пути их решения на примере ReSharper
8. 44% — Станислав sidristij Сидристый — Как работает CLR и как заставить его работать по-другому
9. 43% — Андрей DreamWalker Акиньшин — Поговорим о различных версиях .NET
10. 42% — Никита kekekeks Цуканов — Использование Linux в качестве платформы для серверных .NET-приложений
11. 41% — Игорь SychevIgor Сычев — Entity Framework 7 + Redis/AzureTableStore

Мы провели ряд тренировок (как по скайпу, так и вживую). Если из голосования видно, что не все заявленные темы являются популярными, то тренировки показали, что не все из докладчиков на популярные темы полностью готовы.

Именно поэтому в финальном расписании некоторые популярные в голосовании доклады попадают во второй и третий залы, а на их место встают другие. Ну и от ограничений никуда не денешься: у нас только 7 слотов в главном зале (не считая кейнота от Дино Эспозито).

В рамках моей «работы» над стандартизацией C# 5 в технической группе ECMA-334 TC49-TG2 мне посчастливилось увидеть несколько интересных способов, которыми Владимир Решетников проверял C# на прочность. В данной статье описана одна из проблем, которые он поднял. Разумеется, она, скорее всего, никак не затронет 99.999% C#-разработчиков… но разобраться все равно любопытно.

Спецификации, используемые в статье:

• Стандарт Unicode 7.0.0 – в особенности, глава 3
• C# 5 (Документ Word)
• ECMA-335 (Спецификация CLI)

Что такое строка?

Как бы вы объявили тип string (или System.String)? Я могу предположить несколько вариантов ответа на данный вопрос, от расплывчатых до довольно конкретных:

• «Какой-нибудь текст в кавычках»
• Последовательность символов
• Последовательность символов Юникода
• Последовательность 16-битных символов
• Последовательность слов UTF-16

Только последнее утверждение полностью верно. Спецификация C# 5 (раздел 1.3) гласит:

Обработка строк и символов в C# использует UTF-16. Тип char представляет слово UTF-16, а тип string – последовательность слов UTF-16.

Пока всё в порядке. Но это C#. А как насчет IL? Что используется там, и имеет ли это значение? Оказывается, что имеет… Строки должны быть объявлены в IL как константы, и природа этого способа представления важна – не только кодировка, но и интерпретация этих закодированных данных. В частности, последовательность слов UTF-16 не всегда может быть представлена в виде последовательности слов UTF-8.