Async\Await методы и PostSharp

Сложность 300-400

Описание проблемы

Уже много чего написал насчет PostSharp, конкретных решений, кастом компонентов, общие принципы работы. Однако с выходом .Net 4.5 появилась новая фича со специальными словами async\await которые позволяют более просто и компактно описывать асинхронное поведение методов. Новый функционал хорош, но добавляет головной боли при использовании PostSharp, с методами помеченными async, использование классических аспектов не пройдет. Методы с маркером async разворачиваются в машину состояний, что не очень хорошо с точки зрения применения аспектов. Т.е. возьмем стандартную реализацию аспекта трассировщика с помощью  PostSharp:

И применим его к тестовому примеру с вызовом синхронных и асинхронных методов с исключениями и без:

Результат выполнения программы представлен ниже, и для большей наглядности я разукрасил выводы для каждого метода.

Подробнее

Notification Bar Overview Video

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

Notification Bar Overview

Async/Await для .Net 4.0 Video

Сложность 200-400

Буквально на днях в блоге разработчиков Base Class Library промелькнуло известие о том, что теперь можно использовать async/await и для кода написанного на .Net Framework 4. А это значит можно использовать удобный подход для асинхронной работы, даже если пользователи вашей программы до сих пор сидят на «старой, доброй XP» по тем или иным причинам. Естественно такая новость не могла пройти мимо меня, чтобы я не попробовал как оно на самом деле в использовании. Забегая вперед, и что вполне ожидаемо, работает все точно так же как и в 4.5 за исключением некоторых нюансов в процессе разработки.

Процесс работы с новыми возможностями показан на видео подкатом.

 

Hard’n’Heavy!

Async/Await для .Net 4.0

Сложность 200-400

Буквально на днях в блоге разработчиков Base Class Library промелькнуло известие о том, что теперь можно использовать async/await и для кода написанного на .Net Framework 4. А это значит можно использовать удобный подход для асинхронной работы, даже если пользователи вашей программы до сих пор сидят на «старой, доброй XP» по тем или иным причинам. Естественно такая новость не могла пройти мимо меня, чтобы я не попробовал как оно на самом деле в использовании. Забегая вперед, и что вполне ожидаемо, работает все точно так же как и в 4.5 за исключением некоторых нюансов в процессе разработки. Но обо всем по порядку.

Команда разработчиков анонсировала пакет дополнений, который позволяет использовать await в Visual Studio 2012 (в предыдущих версиях работать не будет). Выпущенный пакет может быть применен к следующим платформам (указанной версии или выше):

  • .NET Framework 4.0 (with KB2468871)
  • Silverlight 4
  • Windows Phone 7.5
  • И портируемые библиотеки опирающиеся на указанные платформы.

Т.е. это не встроенная фича .net 4.5?

И да и нет. Очень заманчиво думать, что новые ключевые слова await/async в C# являются чистым новым функционалом языка. В некоторой степени это так: компилятору необходимо проделать достаточно много сложной работы с вашим кодом, чтобы он мог ожидать операции.

Принимая вышесказанное во внимание, разработчики ожидают возможность использования await как только они переходят на новую студию – независимо от платформы языка. Если вы задумывались о том, как реализовано большинство фич языка, то вы можете догадаться, что многие вещи не просто данность и особенность языка. Множество конструкций языка опираются на вполне конкретные API, к примеру, методы расширения опираются на ExtensionAttribute, а foreach зависит от интерфейса IEnumerable. В случае с await потребуется давно любимый класс Task и некоторая хитрая обвязка, которая делает возможным использование await.

Подробнее

Make me async

Сложность 200

Почти месяц назад я написал статью «Эволюция сервисных методов». В ней я пришел к реализации библиотеки MakeMeAsync, которая позволяет декорировать вызовы методов, делая их асинхронными. При этом код остаётся максимально читабельным и чистым, на мой взгляд.

Вот уже месяц как библиотека используется в реальном боевом проекте и показывает себя с лучшей стороны. Сначала удалось сократить размер самих сервисов, так как большая часть кода была инфраструктурной, затем, когда код стал ясным, я легко увидел, что сервисы не в полной мере выполняют свои задачи, а скорее делегируют их на слой ниже. Это меня огорчило, так как реализация является неправильным подходом; но порадовало, так как я смог это увидеть, и мне было психологически легче перенести код в нужное место, так как сервис выглядел компактным и понятным.

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

Итак, я думаю, что для начала стоит обновить информацию о том, как используется библиотека MakeMeAsync.

Подробнее

Обработка исключений при работе с классом Task

Сложность по шкале Microsoft 200

В последних своих постах я активно использую класс Task для асинхронного выполнения задач. С учетом того, что основной вкусностью новой версии С# будет метод директива async, которая как раз и предназначена более всего для работы с классом Task, то будет уместно рассказать о том, как ловить и обрабатывать исключения, которые могут возникнуть при работе вашего метода в асинхронном режиме.

Далее будет рассмотрена работа с исключениями не только в теле метода, который был явным образом указан в качестве жертвы асинхронной работы, но и как получать исключения из вложенных асинхронных методов. Можете думать об этом как о сне во сне, и вспоминать фильм «Начало».

Все последующие примеры не открывают Америки и все прекрасно описано в книги  J.Albahari “C# in the Nutshell 4.0”, но пока не увидишь, как не надо делать, сложно бывает запомнить как надо.

Подробнее