Фреймворк .NET развивается очень быстро, в языки с каждой версией добавляется множество новых возможностей. Однако интересно, как быстро этими обновлениями удаётся воспользоваться.

Краткая историческая справка (неполная):

.NET 4.5 (Windows Vista SP2+): Metro, async/await, Unicode console, generics in MEF, IDN, EAI, ZIP; WPF: Ribbon control, async validation, VirtualizingPanel pixel scrolling, static properties bindings, live shaping, better weak events support.

.NET 4.0 (Windows XP SP3+): Parallel Extensions, Parallel LINQ, Task Parallel Library, dynamic dispatch and DLR, covariance and contravariance, named parameters, optional parameters, indexed properties, code contracts, BigInteger and Complex classes.

У вас проект на .NET 4.0 и вам надоела «лапша» из колбеков? Вы бы хотели использовать async/await в своем проекте, но тимлид грозит небесной карой за смену платформы? Если установка патча на фреймворк и студию для вас являются допустимым решением, то вам сюда. Если нет, то существует другое решение.


(для гуру: внутри корутины на yield'ах)

Добрый день, уважаемые хабрапользователи. Некоторое время назад мне пришлось работать над несложным windows-приложением, в котором требовалось производить аудио- и видеозапись с различных устройств. В частности, захват аудио нужно было производить с шести каналов карты MAudio, а захват hd видео — с двух карт захвата AverMedia, сигнал на которые приходил с видеокамер по компонентному входу. Также нужно было делать скриншоты с документ-камеры, подключенной по USB-интерфейсу. Приложение было решено писать на C#, а видеозапись производить при помощи библиотеки DirectShow.NET.

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

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

Очень много приходится работать с текстовыми данными, такими как код, статьи, посты и т.д. В то время когда жил под Linux — пользовался менеджерами истории буфера обмена, которые запоминали, то что попадало в виде текста в буфер и по клику в трее я мог вернуть нужное значение в буфер, не возвращаясь к источнику.
Недавно пришлось большую часть времени проводить в Windows, удовлетворяющей альтернативы для такого простого приложения я не нашел. Что-то в найденных вариантах не устраивало: не свободное ПО, много ненужного функционала (который просто мешал) или работали неудобно для меня (например: получить предыдущее значение буфера, приходилось открывать окно программы). Недолго думая решил сделать, так как мне хотелось.

Поскольку, приложение должно работать исключительно в Windows, было принято решение написать ее на C# — к тому же, никогда ранее на нем ничего не писал — появился повод попробовать.

Задача

• Программа должна слушать и запоминать изменения в текстовом буфере обмена.
• Через контекстное меню в трее или через окно программы по клику на выбранном элементе истории, нужное значение должно автоматически попадать назад в буфер.
• История не должна пропадать после перезагрузки системы

Вместе с бета версиями VS 2011 и Windows 8 многие люди будут устанавливать, и разбираться с .NET 4.5. В .NET 4.5 добавлено много новых усовершенствований, которые являются достаточно прозрачными, но важно понять, как с точки зрения CLR она работает на вашей машине.

Когда .NET 4.5 устанавливается она, фактически, заменяет .NET 4.0 на вашей машине. .NET 4.0 перезаписывается новой версией .NET 4.5, что в соответствии со словами Microsoft гарантирует 100%-ую совместимость. 100% совместимость звучит привлекательно, но все мы знаем, что добиться такого результата достаточно сложно. Но есть вещь гораздо более интересная, чем обратная совместимость, которая делает ситуацию с разворачиванием .NET 4.5 неудобной в лучшем и запутанной в худшем случае.

Динамические вызовы: что это и зачем?

Думаю, для каждого разработчика, работающим на статических языках программирования, иногда возникала необходимость прибегнуть к динамическим вызовам — вызвать метод чего-то, о чем пока еще ничего не известно. Или получить какое-то свойство у какого-то объекта, о котором будет известно только в run-time.

Это иногда используется в алгоритмах, основанных на так называемой «утиной типизации» (duck typing):

Если что-то выглядит как утка, плавает как утка и крякает как утка, то это, вероятно, утка и есть.

В данной статье я хотел бы рассмотреть основные доступные в Microsoft .NET 4.0 способы, сравнить их производительность и синтаксис.

Предлагаемые решения в .NET 4

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

Для распараллеливания «идеальных» циклов предоставляются следующие варианты:

• класс System.Threading.Tasks.Parallel с методами For (), ForEach ()
• Parallel LINQ с методом расширения AsParallel ().

Датская компания Composite A/S объявила о переходе своей CMS в OpenSource.
Работает на IIS, .NET 4 и ASP.NET. Как базу данных может использовать как текствый XML так и MS SQL
Кратко об возможностях:

• Ориентирована на использования XSLT для формирования HTML, но также позволят вставлять обычные ASP.NET контролы
• Генерируемые дататипы
• Древовидная структура страниц
• Темплейты с разным количеством контент-блоков

С новейшим выпуском .NET Framework версии 4.0, в библиотеке классов появилась новая коллекция в System.Collections.Generic — SortedSet<T>.

Две главные особенности SortedSet<T>:

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

Чтобы было понятнее, давайте пройдём тесты, которые я сделал.

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

LINQ to objects сейчас прочно вошел в нашу жизнь, победоносными шагами ступая по всему стеку .net приложений. В этой статье я бы хотел привести примеры нескольких не очевидных вещей, с которыми довелось столкнуться, работая с LINQ. Интересно — прошу под кат.

Никто уже не отрицает полезность тестов в любой сколько-нибудь сложной системе. Без тестов очень быстро можно скатиться в хаос и проводить большую часть времени в отладчике, занимаясь поиском и отловом косвенных эффектов от изменений той или иной части приложения. Тесты важны, нужны и так далее по тексту.

По науке, тесты являются документированием системы. Грамотно написанные тесты дают понять, как работает система, как ведет себя, причем читаться все это должно как готовая спецификация на поведение системы. Т.е. в идеале должен получаться связный и понятный текст. Это идеал, к которому постепенно приближаются методы тестирования, начиная от юнит тестирования и наиболее явно проявляясь в поведенческом/приемочном тестировании, когда сами тесты уже пишутся на языке бизнеса (в этом моменте вспоминаем Fitnesse).

При написании тестов не стоит скупиться на строчки кода и классы, важно только их правильно структурировать. Я считаю, что может быть вполне нормальной ситуация, когда у вас тестовый класс состоит только из одного тестового метода – не надо этого стесняться, это гораздо лучше, чем классы на 20 экранов. HD экранов.

В общем, все должно быть направлено на максимальную ясность и четкость тестов, чтобы явно было видно все взаимосвязи. Чтобы можно было восстановить логику программы по одним лишь тестам. В дело читабельности пойдет не только Assert DSL (Domain Specific Language), но и именование файлов, подход Arrange Act Assert. Все это не новые подходы как оказывается, но широкой известности пока не получившие, судя по тому, что я вижу в окружающих меня проектах. Да и сам я натолкнулся на новые темы случайно, изучая исходные коды StructureMap.

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

• Именовать тестовые файлы по основному методу, который тестируется.
• Использовать DSL  для создания объектов, чтобы методы делать максимально лаконичными.
• Стараться писать тесты в стиле «один тестовый метод – один assert».
• Структурировать внутренности теста.
• Создать и использовать Assert DSL.

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

Базовое понимание
 
Помню, еще в университете перед реализацией любого алгоритма мы описывали его в виде блок схемы, и только после этого переходили непосредственно к кодированию. Workflow, как одна из парадигм программирования, на ряду с процедурным и объектно ориентированным подходами, как раз и позволяет нам визуально реализовать любой процесс, используя набор предопределенных функциональных блоков (Activity), при этом, избавляя от его последующего кодирования.

Библиотека WF, являясь одной из реализаций парадигмы Workflow, предоставляет следующие основные возможности:

— богатый набор функциональных блоков;
— расширение набора стандартных функциональных блоков пользовательскими;
— сохранение и возобновление экземпляров Workflow в процессе их исполнения;
— использование Workflow дизайнера в вашем приложении;
— интеграция с WCF;
— пошаговая диагностика непосредственно в Workflow дизайнере;
— и многое другое.

Критерии применения

Как известно, каждой технологии своя область применения. Для определения необходимости использования WF при реализации конкретного алгоритма/процесса я применяю 3 критерия:

1. Реализация алгоритма/процесса постоянно меняется.

В нашей компании мы разработали подсистему Workflow, которая является ядром всех продуктов. Имея, к примеру, десятки клиентов наших продуктов, у которых десятки процессов, получаем сотни разных изменяющихся процессов.

2. Процесс/алгоритм имеет длительный срок выполнения.

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

3. Нужно предоставить возможность изменения алгоритма/процесса конечному пользователю без вмешательства программиста.

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

Добавлены следующие новые фичи:

* Новое меню «Add View» в Visual Studio
* Папка \Scripts и поддержка jQuery
* Встроенная поддержка Model Binder для комплексных типов
* Перестроена инфраструктура Model Binder
* Улучшены методы UpdateModel и TryUpdateModel
* Улучшено тестирование сценариев UpdateModel и TryUpdateModel
* Типизирован атрибут AcceptVerbs. Добавили перечисление HttpVerbs.
* Улучшены сообщения об ошибках по умолчанию при валидации
* Модифицированы некоторые хелпер методы. Изменено создание формы. Методы стали extension-методами класса HtmlHelper.
* Поддержка проектов с Silverlight 2
* Доступна сборка ASP.NET MVC Futures для этой беты
* Поддержка размещения сборок в GAC

Скачать бету. Более подробно, как всегда у ScottGu.

Многие, кто сейчас работают с Entity Framework, жалуются на отсутствие внешних ключей в концептуальной моделе, то есть в тех классах, которые генерирует Entity Framework. В результате, простая задача по добавлению или обновлению записи часто выглядит не очень изящно. То есть либо приходится подгружать связанную запись, что приводит к выполнению лишнего запроса к базе данных, либо создавать новый объект класса EntityKey, что требует написания лишнего кода и после простого и простого в использовании LINQ to SQL выглядит по-меньшей мере странно.

Software Transactional Memory (STM) — это альтернатива блокировкам и другим традиционным механизмам синхронизации асинхронных операций и потоков при доступе к общему участку памяти. Механизм STM похож на работу транзакций в современных СУБД и, хотя его использование в общем случае медленнее использования механизма блокировок, STM предлагает разработчику более простой способ управления параллельными вычислениями.

Использование STM в .NET крайне просто:

Atomic.Do(()=> {
<statememts>
});

где statements — это выражение которое должно выполняться в транзакции.

Существует масса библиотек реализующих STM для множества языков. STM для .NET ранее существовала в виде отдельного проекта группы Microsoft Research, кроме того для C# существовует еще 4 библиотеки STM. И вот теперь, этот механизм стал частью фреймворка.

* скачать .NET 4.0 с STM msdn.microsoft.com/en-us/devlabs/ee334183.aspx
* wiki-статья про STM en.wikipedia.org/wiki/Software_transactional_memory (eng)
* статья Beautiful Сoncurency (Haskell) research.microsoft.com/en-us/um/people/simonpj/papers/stm/beautiful.pdf (pdf), спасибо shai_xylyd

via www.infoq.com/news/2009/07/Software-Transactional-Memory

После выхода Visual Studio 2010 beta 1 — первым делом нужно разобраться, что же дает нового нам C# 4.0 (так как это мой основной язык программирования — для меня это является важным). Первым делом должен вам порекомендовать примеры C# 4.0, которые можно скачать отсюда (там же есть документ New Features in C# 4.0, которая послужила основой для этого топика). Документацию по .Net Framework 4.0 beta 1 можно посмотреть в MSDN. Дальше будут следовать мой небольшой опыт знакомства с новой версией .NET.
 

Представляю вам два новых атрибута, которые улучшат продуктивность, за счет уменьшения объема кода:

• [Optional]
• [DefaultParameterValue]

Вариантность всегда была для меня слишком сложной темой, чтобы разобраться в ней. Недавно я делал доклад о новых особенностях C# 4.0 и вариантность была одной из охваченных мной тем. Я хотел бы начать с распространенного сценария, который мне всегда было трудно понять. Возьмем вот такой фрагмент кода:

1. IList<object> stuff = new List<string>();

* This source code was highlighted with Source Code Highlighter.

Это не будет компилироваться ни в одной из существующих версий .NET Framework. Я всегда пытался понять, почему бы этому не работать. Тип System.String, безусловно, удовлетворяет все требования System.Object. Так почему же это не работает? Обобщение List – это ссылочный тип, что означает что каждый раз когда кто-то сошлется на объект этого типа в коде, он получит указатель на некоторое место в куче. И неважно сколько раз вы используете List, вы всегда получаете ту же самую ссылку т.к. это ссылочный тип. Так вот, давайте разовьем наш предыдущий пример: