Добрый день, хабровчане! Бесплатный декомпилятор и менеджер сборок от JetBrains ушел в народ – несколько дней назад на нашем сайте стал доступен официальный релиз dotPeek 1.0.

dotPeek, о котором мы писали на Хабре около года назад, когда появились первые публичные сборки продукта, — это инструмент, сочетающий качественную декомпиляцию с развитой навигацией и поиском на манер ReSharper — нашего небезызвестного расширения для Visual Studio. Сегодня мы представляем вашему вниманию авторизованный перевод новости о выходе этого продукта.

Основные возможности dotPeek 1.0 таковы:

• Декомпиляция сборок .NET Framework 1.0-4.5 в эквивалентный код на C#. Поддерживаются библиотеки (.dll), исполняемые файлы (.exe), а также файлы метаданных Windows 8 (.winmd). Кроме того, dotPeek умеет искать сборки в каталогах, которые вы ему указываете, и открывает разного рода архивы: как .zip, так и родственные форматы .vsix и .nupkg.

В разгар битвы между Oracle и Google за право использовать Java/Dalvik в системе Android, компания Xamarin представила альтернативу — более производительную и энергоэффективную версию Android на С#. Тесты производительности говорят сами за себя.



В отличие от Sun и языка Java, компания Microsoft направила C# и .NET VM для стандартизации в ECMA, система защищена от патентных исков строгими требованиями ISO, а также обязательством Microsoft.

В последнее время на Хабре часто начали появляться статьи о ASP.NET MVC. Однако в этой статье я бы хотел сделать несколько заметок по поводу построения приложений на вышеприведенном фреймворке: минимальный набор NuGet-packages (без которых грех начинать работу), логирование, подводные камни при использовании стандартных membership-, profile- провайдеров. И, напоследок, почему Web API из MVC 4 — то, что так долго мы все ждали.

В рантайме Mono есть немало средств для взаимодействия с кодом на не .NET языках, но никогда не было ничего вменяемого для взаимодействия с кодом на C++.

Но это вскоре изменится благодаря работе Алекса Коррадо, Андрэа Гайта и Зольтана Варга.

Вкратце, новая технология позволяет разработчикам C#/.NET:

• Легко и прозрачно использовать классы C++ из C# или любого иного .NET языка
• Создавать экземпляры классов C++ из C#
• Вызывать методы классов C++ из кода на C#
• Вызывать инлайн-методы C++ из кода на C# (при условии, что библиотека скомпилирована с флагом -fkeep-inline-functions или если вы скомпилируете дополнительную библиотеку с их реализациями)
• Наследовать классы C++ из C#
• Переопределять виртуальные методы классов C++ методами на C#
• Использовать экземпляры таких смешанных C++/C# классов как в коде на C#, так и в коде на C++

Добрый день сообщество,

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

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

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

Недавно с рассылкой от компании Redgate (это та компания, которая выпустила всем известные тулы .Net Reflector, SmartAssembly и прочие) получил бесплатную книгу «Under the Hood of .NET Memory Management». Пока что доступна только первая ее часть, но она довольно объемная и раскрывает многие аспекты менеджмента памяти. Самое вкусное обещают во второй части. Приятного скачивания (краткое содержание под катом):

• Ссылка на официальную страницу с подпиской на выход второй части
• Прямая ссылка на pdf:
  Under the Hood of .NET Memory Management (Part 1)

Бонусом по первой ссылке, в том же архиве, идет книга по ANTS Memory Profiler

В недавно вышедшей Visual Studio 11 Beta встроена новая и главная фишка будущего C# 5 — асинхронное программирование с помощью async/await. Про нее уже написано достаточно много статей в том, числе на хабре — например, эта серия статей. Однако, я для себя так и не понял в чем суть нового синтаксиса, пока сам не попробовал его в деле. Данная статья — попытка самому структурировать и до конца разобраться с этим достаточно интересным инструментом и поделиться результатами с сообществом, рассказав про него немного иначе. Итак, поехали…

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().

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

Введение

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

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

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

Привет хабравчанам!

Давненько я не писал на хабр: учеба, сессия надвигается, сами понимаете. Сегодня я попробую рассказать, как в XNA реализовать Deferred Lighting (отложенное освещение) с использованием normal mapping на три источника света, при этом использовать мы будем Reach-профиль и Shader model 2.0.
Напомню, раньше мы уже затрагивали тему шейдеров: тут. Остальное под катом, видео и демо там же.

Вчера разработанное нами приложение Coin Keeper заняло третье место в топе платных приложений русского AppStore.

Интересно то, что мы разрабатывали его не на привычном Objective C, а на C#, используя фреймворки Monotouch и Monodroid.

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

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

Существует несколько готовых решений для .NET, но самое актуальное — это ClickOnce. Эту технологию уже нельзя назвать новой, однако серьёзное развитие, на мой взгляд, она получила не так давно, и не обладает исчерпывающим функционалом.
Если вы не хотите изобретать велосипед, то советую вам пристально изучить возможности ClickOnce, и если вам будет достаточно предлагаемого функционала, то это определенно ваш выбор. Однако ClickOnce не панацея и далеко не всегда ею можно обойтись.

Сейчас же я хочу рассказать о своём видении механизма авто-обновлений. Я не претендую на истинность в последней инстанции, так что конструктивная критика и предложения в комментариях приветствуются.

UPD: Суть реализации заключается в том, чтобы уменьшить количество процессов и служб, которые занимаются обновлением. Если у вас несколько приложений, то все они смогут «получать» обновления от одного единственного Windows-сервиса. Не надо будет для каждого приложения запускать лаунчер, держать соединение с сервером обновлений. Теоретически в системе всеми обновлениями может заниматься один процесс, и возможно этим процессом скоро станет ClickOnce, если разработчики перестанут делать свои «велосипеды». А разработчики перестанут делать свои велосипеды тогда, когда им будет достаточно функционала ClickOnce. Сейчас, к сожалению, это не всегда так.

Итак задача

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

Почему Roslyn?

В прошлом наши компиляторы работали как черные ящики — вы подаёте на вход исходный текст программы, а на выходе получаете сборку. Все знания и информация, которую формирует компилятор выбрасывается и недоступны для чьего-либо использования.

Как пишет Soma в своём блоге, часть Visual Studio language team работает на проектом, который называется Roslyn. Его главная цель — переписать компиляторы C# и VB и создать языкове сервисы в управляемом коде. С чистым, современным и управляемым кодом наша команда сможет быть более продуктивной, внедрять инновации быстрее и выдавать больше возможностей скорее и с лучшим качеством.

Более того, мы открываем компиляторы C# и VB со всей их внутренней информацией, делая доступным для вас анализ кода. Мы предоставляем публичное API и обеспечиваем точки расширения в языковых сервисах C# и VB.

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

Большинство компиляторов на текущий момент являются чёрными ящиками — они превращают исходный код в объектные файлы или сборки. Цель “Roslyn Project” от компании Microsoft — открыть компиляторы Visual Basic и C#, дав разработчикам возможность пользоваться API, предоставляющим SyntaxTree, Emit API, Symbol API, Binding & Flow Analysis API. Над API надстраивается множество полезных сервисов:


Roslyn можно использовать для генерации кода, анализа и оптимизации, а так же поддержки сценариев и интерактивного использования VB и C#. На днях вышел Microsoft “Roslyn” October 2011 CTP, который уже можно скачать и попробовать на деле. Под катом подборка ссылочек по теме.

Достаточно большое название? Да? В этом посте я покажу Вам альтернативный подход в создании простого событийно-ориентированного HTTP-сервера на C#, используя мощь Reactive Extensions.

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

Пришло время рассказать вам о пиксельных шейдерах и о том, как сделать post-proccesing. Это вторая часть статьи о графических методах в XNA, в прошлой статье — мы рассматривали методы Draw и Begin у spriteBatch. Для примера: улучшим нашу систему частиц добавлением пиксельного шейдера, который будет искажать пространство.

И опять, привет хабравчанам!

Буквально несколько дней назад — начал цикл статей, о том, как можно создавать крутые игры с помощью XNA Framework, своей студии у меня нет, поэтому ограничимся только 2D играми.

На этот раз — мы более подробно рассмотрим Draw и напишем свою первую систему частиц.

Привет всем начинающим геймдевелоперам и просто хорошим людям. Сегодня, я хочу познакомить вас с замечательным фреймворком XNA (набор инструментов с управляемой средой времени выполнения dotNet). Программировать мы будем на C#.
Для того, чтобы познакомить вас с XNA ближе, я предлагаю написать простую «музыкальную» 2D игрушку. Остальное под катом.