А теперь скажите честно: если бы Microsoft предложила единственный "официальный" язык .NET, например, на базе семейства BASIC, то все ли программисты были бы рады такому выбору? Или если бы "официальный" язык .NET был основан на синтаксисе Fortran, то сколько людей в мире вообще проигнорировало бы платформу .NET? Поскольку среда выполнения .NET демонстрирует меньшую зависимость от языка, используемого для построения управляемого программного кода, программисты .NET могут, не меняя своих синтаксических предпочтений, обмениваться скомпилированными компоновочными блоками со своими коллегами, другими отделами и внешними организациями (не обращая внимания на то, какой язык .NET используется там).
Еще одно полезное преимущество интеграции различных языков .NET в одном унифицированном программном решении вытекает из того простого факта, что каждый язык программирования имеет свои сильные (а также слабые) стороны. Например, некоторые языки программирования имеют превосходную встроенную поддержку сложных математических вычислений. В других лучше реализованы финансовые или логические вычисления, взаимодействие с центральными компьютерами и т.д. Когда преимущества конкретного языка программирования объединяются с преимуществами платформы .NET, выигрывают все.
Конечно, вы можете разрабатывать программное обеспечение, не выходя за рамки своего любимого языка .NET. Но, изучив синтаксис одного языка .NET, вам будет очень легко освоить любой другой. Это тоже очень выгодно, особенно консультантам. Если вашей специализацией является C#, но вы оказались на узле клиента, который "привязан" к Visual Basic .NET, то сможете почти сразу разобрать соответствующий программный код (поверьте!), воспользовавшись указанным преимуществом .NET. На этом и остановимся.
Компоновочные блоки .NET
Независимо от того, какой язык .NET вы выберете для программирования, вы должны понимать, что хотя бинарные .NET-единицы имеют такие же расширения файлов, как COM-серверы и неуправляемые программы Win32 (*.dll или *.exe), их внутреннее устройство совершенно иное. Например, бинарные .NET-единицы *.dll не экспортируют методы для упрощения коммуникации со средой выполнения COM (поскольку .NET – это не COM). Бинарные .NET-единицы не описываются с помощью библиотек COM-типов и не регистрируются в реестре системы. Наверное, самым важным является то, что бинарные .NET-единицы содержат не специфические для платформы инструкции, а независимые от платформы IL-инструкции (Intermediate Language – промежуточный язык) и метаданные типов. На рис. 1.2 это показано схематически.
Рис. 1.2. Все .NET-компиляторы генерируют IL-инструкции и метаданные
Замечание. Относительно сокращения "IL" здесь уместно сказать несколько дополнительных слов. В ходе разработки .NET официальным названием для IL было Microsoft (intermediate Language (MSIL). Однако в вышедшей версии .NET это название было изменено на OIL (Common Intermediate Language – общий промежуточный язык). Поэтому вам следует знать, что в публикациях, посвященных .NET, сокращения IL, MSIL и CIL обозначают одно и то же. В соответствии с терминологией, принятой сегодня, в тексте этой книги используется сокращение CIL.
После создания *.dll или *.exe с помощью подходящего .NET-компилятора, соответствующий модуль упаковывается в
Как уже было сказано, компоновочный блок содержит программный код CIL, который концептуально напоминает байт-код Java в том смысле, что он не компилируется в специфические для соответствующей платформы инструкции, пока это не станет абсолютно необходимо. Обычно "абсолютная необходимость" означает момент, когда на какой-то блок CIL-инструкций (например, реализацию метода) выполняется ссылка для его использования в среде выполнения .NET.
В добавление к CIL-инструкциям, компоновочные блоки также содержат