Люди из Mono Project начали делать реализацию технологии Microsoft Silverlight для UNIX-based систем. Проект называется Moonlight.
Для тех, кто не знает, Microsoft Silverlight — это новая технология, которая позволяет использовать большие возможности .NET CLR и XAML с частью WPF в веб браузерах. Технология изначально проектировалась как кроссплатформенная (на данный момент Microsoft поддерживает браузеры IE, Firefox, Opera и Safari на платформах Windows и MacOS). Сейчас черед за UNIX. Если ребята из Mono справятся с задачей (а я уверен, что справятся, так как у них уже есть готовая реализация .NET CLR), то мы будем иметь практически полностью переносимый Silverlight.
В заключение хочу добавить, что частое сопоставление Silverlight с Flash на мой взгляд не очень верно. Да, Silverlight можно использовать для тех же целей что и Flash, но это совсем другого поля ягода. Я сказал бы, что Silverlight больше похож на современный легковесный аналог Java-апплетов с поддержкой прогрессивных технологий создания UI (WPF-like). Думаю, общая тенденция, которую создает Silverlight — это мягкое «утолщение» веб-клиента и уход от уродливых на мой взгляд технологий JavaScript/AJAX/Flash.
В заключение интересующимся предлагаю взглянуть на плакат иллюстрирующий технологию Silverlight.

В этом топике я расскажу про C++/CLI — промежуточный язык для склеивания кода на C/C++ и .NET

Это довольно распространённая задача, ведь на C/C++ написаны тонны проверенного временем высокопроизводительного кода, который невозможно переписать на управляемые языки.

Наша задача — обеспечить .NET-интерфейс к этим библиотекам. Но как это сделать, если они написаны на C/C++?

Microsoft предлагает два варианта решения проблемы.
 

Managed код и .NET Framework – совершенно замечательная вещь с точки зрения программиста, которому надо кровь из носу выдавать максимально стабильно работающие программы. Использование .NET позволяет очень сильно сократить затраты на разработку, тестирование и сопровождение программных продуктов, особенно по сравнению с C++ или Delphi.

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

Однако нет такой проблемы, которую нельзя решить (пусть даже с помощью топора и лома). Сегодня у нас краткий обзор возможностей организации взаимодействия между managed и unmanaged кодом. Многие C# и особенно VB.NET программисты боятся этого, но на самом деле в этом нет ничего страшного. Начнем мы с самых примитивных методов, которые будут интересны разве что новичкам (поэтому матерые волки .NET могут с чистой совестью первую часть статьи пропустить), и закончим описанием того, что делать, если хочется написать программу на .NET, но сделать это невозможно (а такое тоже бывает). Естественно, к каждому случаю будут приведены конкретные примеры, быть может, хабрачеловеки расскажут мне о моей собственной велосипедности. Параллельно я скажу пару слов о подводных камнях при работе с VSTO и Windows Shell.

Specter – инфраструктура для составления объектно-поведенческих спецификаций для .NET. Он предоставляет возможности для обеспечения разработки, руководствуясь поведением системы (BDD), требуя от разработчиков написания исполняемой спецификации для объектов перед написанием самих объектов. Технически это ни чем не отличается от разработки по средствам тестирования (TDD), хотя различия в форме написания снимают психологический барьер для написания “тестов” для кода, которого ещё не существует. Есть множество проектов для различных платформ, реализующих данную идею (К примеру RSpec для Ruby, NSpec для .NET. Подробнее о средах здесь).
Specter использует возможности мета-программирования языка Boo (CLR .NET) для написания неплохо читаемых спецификаций.

Получая новую информацию о дот нет не перестаю натыкаться на интересные вещи :)
И вот вам несколько интересных вопросиков:
1) Когда при создании экземпляра типа не будет вызываться конструктор?
2) Как интерпретирует компилятор c# модификатор static перед классом (в IL коде)?
3) Какой модификатор доступа к полям и методам не реализует c# но реализует IL код.
4) А знаете ли вы как в C# объявить Union (сымитировать)? Т.е. сделать так, чтобы несколько полей начинались по одному смещению в памяти.
5) Задумывались ли вы почему для значимых типов (struct) нельзя определить конструктор без параметров (в C#)? А можно ли это обойти? :)
6) Если мы поставили клиенту код где в типе были определены поля, клиент написал на основе нашего кода свой код, затем мы поставили клиенту новую версию нашего кода где поля заменены на свойства, то что может сломаться в коде у клиента?
7) Все обработчики событий должны возвращать void… Следует ли майкрософт своему требованию в библиотеке FCL? :))

Это вопросы отвечая на которые можно лучше понять как работает CLR…
Если вам понравится, то сделаю вторую партию, посложнее :)
Просба — не говорить что вопросы слишком простые :) Я уверен что есть много таких людей которые хотя бы на один не ответят сразу :)

p.s. Если вопросы вызовут интерес — правильные ответы опубликую после некоторого обсуждения :)
ОТВЕТЫ

p.p.s. А за что минусуете? Пишите хоть…

ОТВЕТЫ

В своём посте ПОСТ я задал несколько вопросов по .NET и clr и пообещал на них ответить. Отвечаю:

Первую часть вопросов можно найти тут.
Продолжаем:

Что это?

Это некоторая форма компьютерных языков, разрабатываемых для специфичной предметной области. Это то, что позволяет вам (разработчикам ПО) лучше взаимодействовать с носителями “доменных знаний”. А так же позволяет более лаконично оформлять бизнес-логику. Это то, что представляет собой, к примеру, SQL, Linq, многое из синтаксиса Ruby On Rails.

В тему применимости CLR и C++ в больших проектах, работающих с большими объемами данных.

Начиная c MS SQL Server 2005 в распоряжение разработчиков баз данных была добавлена очень мощная технология SQL CLR.

Эта технология позволяет расширять функциональность SQL сервера с помощью .NET языков, например C# или VB.NET.

Используя SQL CLR можно создавать написанные на высокопроизводительных языках свои хранимые процедуры, триггеры, пользовательские типы и функции, а также агрегаты. Это позволяет серьезно повысить производительность и расширить функциональность сервера до немыслимых границ.

Рассмотрим простой пример: напишем пользовательскую функцию разрезания строки по разделителю используя SQL синтаксис и SQL CLR на базе C# и сравним результаты.

Начиная изучать язык C# и .NEt Framework я ни как не мог понять, как же работает CLR. Я либо находил огромные статьи, которые не осилить за 1 вечер либо слишком краткое, скорее даже запутывающее описание процесса (как в книге Г. Шилдта).
Некоторое время назад я решил, что было бы неплохо собирать знания, полученные из книг, «фичи» и часто используемые приемы в одном месте. А то новая информация быстро оседает в голове, но также быстро забывается и спустя несколько недель приходится вновь рыться в сотнях и тысячах строк текста, чтобы найти ответ на вопрос. Читая очередную книгу по программированию, я делал краткие пометки самого важного, что мне показалось. Иногда описывал некоторый процесс понятным мне языком с придуманным примером и т.д. Я не претендую на абсолютную правильность излагаемого материала. Это всего лишь мое понимание процесса, с моими примерами и информацией, которую я посчитал ключевой для понимания Проработав некоторый материал, я решил сохранить это для всех тех, кому это может быть полезно. А кто уже знаком — тот просто освежит это в памяти.

Основная цель strong name или подписи сборки это ее уникальность в GAC(Global assembly cache). На основании сборки во время подписи вычисляется криптографический открытый ключ, закрытый хранится в секрете у производителя сборки, хеш-функция от которого и составляет public token, что, по сути, есть strong name для сборки. Public token сохраняется в метаданных сборки и в паре с именем сборки, версией, и культурой, и служит для уникальной ее идентификации.

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

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

Последнее время на популярно-технических форумах я часто встречаю ожесточённые споры приверженцев и противников .NET. Эти споры, как правило, начинаются из-за недоразумения, и заканчиваются жестким троллингом, беседами “за жизнь” и сравнением радиусов и удельных плотностей материала различных сферических коней. Обе стороны силятся доказать и аргументировать, но ни одна не хочет посмотреть на предмет спора другими глазами. Хабрахабр не исключение, увы.

Накалу страстей такой беседы позавидовали бы религиозные фанатики. Единственное, что спасает противников от крестовых походов друг на друга, вооружившись вилами и LangSpec’ами — то, что они разделены интернетом.

Так жить нельзя, господа. Мне захотелось исправить эту ситуацию, и выступить с одной из сторон. Этим постом я попробую нанести сообществу непоправимую пользу и разобраться с мифами, на обсуждение которых, а не на взаимное членовредительство, к сожалению, и уходят силы спорщиков. А так как я в своё время перелез с C++ на C# и всё вокруг него, то я буду развенчивать негативные мифы, прибавлять позитива и всячески приукрашивать действительность — а как без этого. И — заметьте — это обойдется совершенно бесплатно для M$. Ну а сделать я это хочу в формате Q&A.

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

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

Введение

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

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

Некоторые из читателей, которые когда-либо сталкивались с проблемой, описанной в названии статьи, наверняка оставались на работе до поздна и проводили много часов в отладчике. Для других это может быть не более чем игрой слов и жаргонными словечками. Однако, давайте отойдем от жаргона в сторону и раскроем понятия:

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

Ну и небольшой пример, чтобы показать, о чем идет речь:

using System; 
	
class Test 
{     
    static void Main() 
    { 
        Console.WriteLine(First.Beta); 
    } 
} 
	
class First 
{ 
    public static readonly int Alpha = 5; 
    public static readonly int Beta = Second.Gamma; 
} 
	
class Second 
{ 
    public static readonly int Gamma = First.Alpha; 
}

Результатом выполнения этого кода будет 0

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

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

Одним из наиболее заметных дополнений в C# 4 является dynamic. Об этом рассказано много и не раз. Но всегда выпускается из виду DLR (Dynamic Language Runtime). В данной статье мы рассмотрим внутреннее устройство DLR, работу самого компилятора, а также дадим определение понятиям статически-, динамически- типизированный язык со слабой и сильной типизациями. И, конечно же, не останется без внимания техника PIC (Polymorphic Inline Cache), используемая, например, в Google V8 engine.

Java vs. C#… Что может быть лучше вечного спора? Нет, данная статья не посвящена очередному бенчмарку, и даже не является holy war, не стоит даже вопрос: «кто круче».

Для каждой задачи существует свой инструмент. Сравнивать C# и Ruby, например, не имеет смысла, т.к. их целевое предназначение совершенно разное, да и природа также. Однако именно C# и Java являются наиболее близкими по своей философии.

Очень часто коллеги, пишущие на Java, даже не подозревают о многих (!!!) вещах, которые предоставляет (или, наоборот не предоставляет) C#.

Если Вам интересно посмотреть на C# и Java без субъективизма, а также узнать внутреннее устройство той или иной возможности, тогда вперед.

Это узкоспециализированная короткая заметка про то, как я запинывал write once, run everywhere тесты для библиотеки, портированной с C# на Java, при помощи Python.

Смысл в следующем: есть большая, толстая и красивая библиотека, которая была по коммерческим соображениям портирована с C# на Java. API осталось почти одинаковым, naming conventions естественно сменились при переходе на другой язык. Нам нужно было написать толстую пачку тестов, проверяющих, что клон библиотеки работает идентично оригиналу (тесты на регрессии, иными словами). Для этого сравнивались результаты работы кода библиотек (некие бинарники и xml-метаданные). Тесты были нетривиальные, их было много, и что самое неприятное — они постоянно дописывались с одного конца командой из четырех человек. Некоторое время я старательно портировал их на Java, затем плюнул и предложил команде писать тесты на языке, который сразу можно было бы выполнять на CLR (со старой библиотекой) и на JVM (с клоном). Оказалось, они и сами уже некоторое время думали про Python,