.NET *

О проблеме внесения изменений в БД в ходе разработки приложения писали на Хабре много раз.
Версионная миграция БД — удобный подход к решению проблемы.

Уже долгое время я участвую в разработке ECM7.Migrator — инструмента для автоматизации изменений БД. О том, как его использовать и почему это удобно, мы писали здесь.

8 месяцев назад мы выпустили версию 2.0, а на этой неделе вышла версия 2.6. По сравнению с версией 2.0 многое изменилось.

• Полностью переписаны классы всех провайдеров: API стал проще и удобнее, все методы работают адекватно (а для проверки адекватности было написано большое количество модульных тестов);
  
• Поддержка SQL Azure и Firebird;
• Методы Up и Down переименованы в Apply и Revert, реализовывать Revert не обязательно;
• Обработка разделителей запросов (например, «GO» для MSSQL);
• Возможность работы со схемами БД (отличающимися от схемы по умолчанию);
• … и много других мелких доработок.

Попробуйте наш новый мигратор и, возможно, он понравится вам так же, как нравится нам!
Взять новую версию можно в google code и в галерее пакетов nuget.

Некоторое время назад в компании была развернута терминальная ферма.
Первым делом в неё были выселены пользователи некой желтой программы.
После чего отдел поддержки желтой программы спросил меня, можно ли отсылать сообщения пользователям фермы всем сразу. XaocCPS посоветовал мне играться в сторону WPF. Нужный скрипт был написан, но его работой я неудовлетворился:
1. Надо ставить внешний компонент PowerShellPack.
2. Компонент ставиться на сервера фермы (х64) отказался.
3. Распространять такое решение из за пункта 1 всем желающим не очень удобно.

Xaegr подсказал что я могу избавиться от прослойки WPF.
Писать можно, можно даже писать красиво. Скрипт выполняется везде где есть .Net Framework — XP, Win7 и скорее всего пойдет даже на х64 серверах фермы.
Как писать — под катом.

UPD по просьбам скрипт выложен на SkyDrive, ссылка в конце

Roslyn Services API позволяют легко реализовывать расширения, которые находят и устраняют проблемы в коде прямо в Visual Studio. Roslyn Services API доступно как часть Roslyn CTP.

В этом посте мы реализуем расширение для Visual Studio, которое детектирует вызовы метода Count() у Enumerable, после чего результат проверяется на равенство больше нуля, например, someSequence.Count() > 0. Проблема, заключающаяся в коде, в том, что Count() должен пройтись по всей последовательности, прежде чем вернуть результат. Более правильным подходом в данном случае является вызов метода Enumerable.Any().

Чтобы исправить это, мы реализуем CodeIssueProvider, детектирующий проблему, и CodeAction, который заменяет условие на вызов Enumerable.Any(), как и требуется. Т.е. наш CodeAction изменит что-то типа someSequence.Count() > 0 на someSequence.Any().

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

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

В Windows Forms эта задача решалась довольно легко, а когда в распоряжении был тот же TextBox от DevExpress со встроенной возможностью ограничения ввода с помощью регулярных выражений, то все было вообще просто. Примеров решения этой же задачи в WPF довольно много, большинство из которых сводится к одному из двух вариантов: использование наследника класса TextBox или добавление attached property с нужными ограничениями.

C#.NET предлагает множество способов сравнить объекты, как экземпляры классов, так и структур. Способов так много, что без упорядочения этих способов и понимания их грамотного использования и имплементации (при наличии возможности переопределения), в голове, неминуемо, образуется каша.

Контекст

С данным вопросом встретился при работе над одним из проектов, в котором очень много настроек. В виду того что добавление новых настроек происходило по ходу разработки то выявилась необходимость сделать класс к которому можно обратится из любого модуля программы. Для этого конечно был использован статический класс, а назвали мы его AppSettings. Конечно можно было бы использовать Properties.Settings… Не буду вдаваться в детали, но этот вариант не подходил.

Суть проблемы

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

public static class TestStatic
{
	// Fields...
	private static int _Counter;
	public static int Counter
	{
		get { return _Counter; }
		set
		{
		        _Counter = value;
		}
	}       
}

В общем если класс не был бы статическим, можно было бы использовать System.Xml.Serialization.XmlSerializer. Это не наш случай — класс у нас статический и в этом случае, по тому, что XmlSerializer.Serialize метод требует экземпляр класса, а не тип класса, то компилятор выдаст 'Test1.TestStatic' is a 'type' but is used like a 'variable'.

При обсуждении той или иной интересной возможности языка C# рано или поздно заходит речь об известных представителей .NET community и одним из первых в этом списке идет Джон Скит (Jon Skeet), гуру stackoverflow.com и автор одной из самых интересных книг по языку C# — “C# in Depth”.

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

Пол года проработав в компании, которая занимается программированием на MQL под Meta Trader столкнулся с таким заказом: клиенту нужно что бы программа была написана на C# или VB.Net.

Задача была в том, что бы написать программу на C# и dll на том же языке, которая связывает приложение с торговым советником на MQL. С одной стороны мне это на руку, так как C# изучаю больше года, с другой — стало непонятно, а как же это делается и вообще возможно ли это?

26 января состоялся бесплатный вебинар на тему нововведений веб-платформе Microsoft и среде разработки Visual Studio 11 для веб-разработчиков. Спасибо всем участникам вебинара (вас было более 170 человек), в том числе за интересные вопросы после сессии.

Я рад сообщить, что для загрузки доступно видео вебинара, которое вы можете легко скачать по следующей ссылке “Нововведения в Visual Studio 2011 для веб-разработчиков”(ссылка обновлена). Видео доступно как для онлайн-просмотра, так и для загрузки (~40 Mb, wmv).

Кроме того, вы можете загрузить файл презентации (pptx) по следующей ссылке с сайта docs.com.

Привет, Хабрахабр!

Введение

В данной статье, я, как и обещал, продолжу описание разработки компилятора для языка Cool, начатое в этой статье.

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

В каждом приложении есть иконки для кнопок, статусов, тулбаров, меню и многого другого. Конечно, в идеале, в команде должен быть выделенный человек, специализирующийся на иконках и знающий все ньюансы создания оных.
Но жизнь далека от идеала, и таких людей в командах обычно нет (честно говоря хороших «иконщиков» в принципе найти очень сложно).
Поэтому хотелось бы поделиться с общественностью опытом работы с иконками в WPF приложениях и, может быть, почерпнуть для себя что-нибуть новое из комментариев.

SqlBulkCopy — это эффективное решение для массовой загрузки данных в таблицы Microsoft SQL Server. Источник данных может быть любой, будь то xml-файл, csv-файл или другая СУБД, например MySQL. Достаточно получить из источника данные в виде объекта DataTable или реализовать интерфейс IDataReader поверх методов доступа к данным.

Вам не придется создавать файлы на диске для дальнейшей их загрузки с помощью утилиты BCP, вам не придется писать код для генерации множественных INSERT запросов. При загрузке данных SqlBulkCopy работает на более низком уровне, позволяя вставлять миллионы записей за максимально короткий срок.

Реализация итераторов в C# (часть 1).

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

Любой разработчик знает, что URL в маршрутизации MVC играет ключевую роль. Как известно, существует стандартная маршрутизация:

routes.MapRoute(
                "Default",
                "{controller}/{action}/{id}",
                new { controller = "Home", action = "Index", id = UrlParameter.Optional );

Она представляет собой правило по которым выбираются маршруты. В простейших случаях, можно поменять местами action и controller, или добавить еще множество параметров, которые будут выглядеть в url следующим образом- param1/param2/param3/. Иногда, например в CMS системах, необходимо сделать так, чтоб часть url приходила как переменная.

routes.MapRoute(
                "Default",
                "{controller}/{action}/{*url}",
               new { controller = "Content", action = "Home", url = UrlParameter.Optional
});

Это правило выделяет Action и Controller, а остальную часть присваивает переменной url.
Регистрируются Routes при старте приложения. А именно в файле Global.asax в методе Application_Start().

Для создания большинства приложений этих знаний хватает. Цель же моей статьи пройти весь жизненный цикл Request и посмотреть, что же происходит, перед тем как приложение разберет url и передаст управление нужному action.

От переводчика:
Не так давно мой менее опытный коллега спросил меня о том, для чего используется yield return в C#. Я не очень часто пишу свои итераторы, поэтому, отвечая ему, я сомневался в своих словах. Справившись в MSDN, я укрепился в сказанном, но у меня возник вопрос: “А во что же всё таки компилируется эта инструкция?” К тому моменту, я уже был знаком с переводимой статьёй, однако всё, что в ней сказано, давно “выветрилось”. Статья старая, но мне думается, что она может быть полезна для определённой группы разработчиков, привыкшей читать русскоязычные статьи и документы.

Ссылка на продолжение: реализация итераторов в C# (часть 2)

Думаю, многим разработчикам на управляемом коде всегда интересовало: сколько же байт занимает экземпляр объекта? А каков лимит размера одного объекта в CLR? Существуют ли различия в выделении памяти между 32-битными и 64-битными системами? Если данные вопросы для Вас не пустой звук, тогда прошу под кат.

Введение

Здравствуй, уважаемый хабраюзер.Я хотел бы тебе представить материал о практическом создании компилятора, который будет транслировать код, написанный на языке Cool, в код виртуальной машины CIL (Common Intermediate Language) под платформу .NET.Данный материал я решил разбить на две части из-за лени все сразу это описывать

В первой части будет описан процесс написания грамматики с учетом приоритетов операторов в среде ANTLR, а также генерации лексера и парсера под язык C#. Также в ней будут рассмотрены подводные камни, которые встретились у меня на пути. Таким образом я постараюсь хоть кому-нибудь сэкономить время (может быть для себя в будущем).

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

Доброе время суток Хаброжители.

Буквально на днях, ко мне и моим коллегам обратились «опытные пользователи» Excel. По специфике работы «опытные пользователи» часто используют офисный пакет для оформления документации. Как ни странно, таблицы Excel так же часто встречаются. Как и на Хабре, не допустимо выпускать документы с орфографическими ошибками. Стандартной возможности excel, по подсветке орфографических ошибок нет. В связи с этим я разработал Add-ins для Excel который бы реализовывал такой функционал.

Это заключительная часть цикла статей, посвященного разработке с помощью Entity Framework и ASP.NET MVC 3. Первые главы вы можете найти по следующим ссылкам:

• Создание модели данных Entity Framework для приложения ASP.NET MVC
• Реализация базовой CRUD-функциональности с Entity Framework в приложении ASP.NET MVC
• Сортировка, фильтрация и разбиение по страницам с Entity Framework в приложении ASP.NET MVC
• Создание сложной модели данных для приложения ASP.NET MVC
• Создание сложной модели данных для приложения ASP.NET MVC, часть 2
• Загрузка данных с Entity Framework в приложении ASP.NET MVC
• Обновление связанных данных с помощью Entity Framework в приложении ASP.NET MVC

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

Увиденный недавно топик, про валидацию css в Visual Studio подстегнул к написанию похожей вещи про валидацию Яваскрипта.
Когда яваскрипт в веб-проекте занимает достаточно большую долю кода, и клиентские скрипты вырастают за рамки «инлайн-скриптов» с одной-двумя строчками вызова jquery-плагинов, вопрос проверки их валидности встает достаточно явно (даже для .net-разработчиков, достаточно далеких от js в принципе :)).

В идеале — хотелось иметь компилятор, который при сборке проекта «компилировал» бы и яваскрипт, с привычным указанием ошибок/предупреждений в окне VS.
Для подобной компиляции уже написан ряд утилит, и я даже сделал небольшой обзор существующих решений.

Если кратко, то проверять яваскрипт можно с помощью jslint, jshint и google closure. Нетрудно догадаться, что у последнего возможности наиболее широкие, и для его интеграции в Visual Studio существует как минимум пара готовых решений.
В этой статье я расскажу об еще одной утилите интеграции google closure в Visual Studio, а именно — jsvalidator, небольшой open-source проект, который и был мной написан после вышеупомянутого анализа.
Ключевое отличие моей реализации — в простоте интеграции и возможности конфигурирования отображения определенных типов предупреждений.