Net framework что входит

Обновлено: 05.07.2024

С точки зрения разработчика ОС Windows - это в первую очередь набор базовых функций Win API, реализованных в виде DLL. До 1993 г. в Windows основной моделью создания многокомпонентных приложений было именно использование вспомогательных модулей поддержки в виде DLL (в свое время пришедших на смену классическому варианту, предполагающему создание единого исполняемого модуля путем включения в него процедур из двоичных LIB-библиотек). В 1993 г. Microsoft предложила новую модель многокомпонентных приложений - COM (Common Object Model). По большому счету, главная идея здесь состоит в применении в дополнение к исполняемому коду метаданных, обеспечивающих автоматический контроль за передачей параметров (а также унификация форматов параметров).

Конечно, можно говорить о достоинствах COM по сравнению с традиционными DLL (хотя достоинства всегда сопровождаются и недостатками, в данном случае в виде снижения производительности), но я категорически не согласен с высказываниями некоторых авторов, смысл которых сводится к следующему: "После выхода COM разработчики поняли, что им больше не надо писать весь код приложений с нуля". Если вдуматься, использование готовых компонентов - ключевая технология программирования на протяжении всей истории этого вида деятельности.

Структура и логика работы

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

Common Language Runtime

Однако, в отличие от Java, CLR будет выполнять код не в режиме классического интерпретатора, а путем предварительной компиляции в машинный код отдельных фрагментов программы или целого приложения (рис. 2). Первый вариант - основной, при этом применяется так называемый Just-In-Time компилятор, который выполняет преобразование MSIL в машинный код по мере обращения к соответствующим процедурам (т. е. неиспользуемые фрагменты программы вовсе не компилируются). Данный подход также хорошо известен; он, в частности, уже более шести лет используется в платформе "1С:Предприятие".

Как известно, режим интерпретации имеет два главных преимущества по сравнению с использованием машинного кода: повышение безопасности программ (точнее, защищенности системы в целом от действия конкретных программ) и упрощение адаптации программ к конкретной аппаратной платформе. С учетом этого рассмотрим структуру CLR-модулей.

CLR-модули состоят из исполняемого кода и метаданных. Метаданные (например, различные декларации полей, методов, свойств и событий) широко применяются и в COM-технологии, что и составляет ее основное отличие от обычных двоичных DLL. В CLR состав метаданных значительно расширен, что позволяет более эффективно контролировать версии, проверять надежность источников поступления программ и т. п.

Исполняемый код в основном представлен в виде "управляемого кода" (возможны и фрагменты "неуправляемого кода", но они будут отныне большой редкостью). Это означает, что CLR не просто преобразует MSIL в машинные инструкции, а выполняет эти действия с учетом определенных внешних установок. Например, Модуль1 может задать свой собственный набор прав, предоставляемый вызываемому им Модулю2, запретив, в частности, любые операции изменения файлов.

Эта возможность широко используется в многопользовательской Интернет-игре для программистов "Террариум", анонсированной на форуме PDC 2001. В ней каждый может написать программные модули, реализующие выбранные стратегии, которые другие участники загружают на свои компьютеры. Безопасность тут обеспечивается именно благодаря четкому контролю за допустимыми действиями "инородных тел". В общем, в CLR мы видим реализацию идей Интернет-браузеров, которые представляют промежуточную среду выполнения программ, но только со значительно более высоким уровнем управляемости прав.

Во-первых, реализована иерархическая система имен объектов типа, получившая название "пространство имен". Теперь вместо плоского идентификатора "ИмяПриложения.ИмяКласса" можно использовать "ИмяПриложения.Имя1.Имя2. ИмяКласса".

Во-вторых, изменен порядок регистрации объектов, что непосредственно связано с появлением еще одного нового термина - сборка (Assembly).

Пример взаимодействия компонентов

В целом эта манипуляция ничем не отличается от создания COM-объекта в VB 6.0, за исключением лишь синтаксиса операции возврата значения функции (раньше мы бы просто написали NowTime = Now).

Посмотрим теперь на структуру проекта в окне Solution Explorer (рис. 3). Отметим, что физически наш проект называется ClassLibrary3, а логическое имя библиотеки - MyClassLibrary (смысл этих компонентов прояснится в дальнейшем). Помимо модуля класса, здесь в явном виде описаны три ссылки на базовые классы, подключенные к проекту по умолчанию. Впрочем, на самом деле подключенных классов гораздо больше (например, в их число входят все классы библиотеки Microsoft.Visual Basic). Здесь же виден новый модуль с описанием данной сборки AssemblyInfo.vb, содержимое которого можно не только посмотреть, но и отредактировать (рис. 4). Кроме того, видно, что к проекту были автоматически подключены еще два базовых класса (см. ключевое слово Imports) и что данную библиотеку можно зарегистрировать и в качестве COM-объекта - тут прописан ее GUID.

Рис. 3. Структура проекта ClassLibrary.

Рис. 4. Описание сборки проекта.

Теперь создадим DLL и посмотрим каталог ClassLibrary3, куда записаны файлы проекта (рис. 5). Результирующий файл ClassLibrary3.dll находится в подкаталоге BIN, а в OBJ - еще несколько копий этой же DLL, полученных в результате отладки.

Рис. 5. Состав файлов проекта.

Для отладки сервера создадим клиентскую программу в виде Console Application, в которой с помощью сформированного ранее компонента попробуем получить текущее время. Для этого откроем окно Add Reference и с помощью кнопки Browse подключим к проекту библиотеку ClassLibrary3.dll (рис. 6). Введем такой код:

Запустим его на выполнение и убедимся, что все работает, как задумано. По крайней мере, внешне все не отличается от того, как мы раньше работали с COM-объектами (только все теперь делается заметно медленнее). Но отметим один любопытный момент. Опять откроем проект ClassLibrary3 и заменим в нем старый код на такой вариант:

Откомпилируем его, полностью заменив старую DLL. Но если мы сейчас зайдем в каталог ConsoleApplication2\Bin, где хранится созданный ранее исполняемый файл клиентского проекта, и запустим его на выполнение, то он будет работать без проблем в старом варианте. Почему? Да потому, что в этом же каталоге вы обнаружите предыдущий вариант ClassLibrary3.dll, которая была автоматически переписана при подключении соответствующей ссылки.

Становится понятен смысл операторных скобок Namespace, использованных в коде класса, - с их помощью описывается иерархическая система имен объектов. Подправим этот код, чтобы можно было применять более компактное обращение к именам объектов:

Теперь "сухой остаток": что же нового мы увидели на этом простом примере по сравнению с традиционным использованием COM-объектов?

Во-первых, проблема согласования версий применяемых компонентов решается тривиальным копированием нужных файлов в каталог клиентского приложения (в том числе с помощью создания специальной копии COM-библиотек). Во-вторых, с помощью операторных скобок Namespace мы можем создавать иерархическую систему имен объектов в отличие от двухзвенной DllName.ClassName, принятой в COM, которая теперь является частным случаем.

Покажем детальнее, как создать такую систему имен, на примере проекта типа Class Library и имени ClassLibraryN:

Соответственно, в клиентском приложении используемые нами классы будут описаны следующим образом:

Обратите внимание, что тут мы специально использовали одинаковое имя Class1 для разных объектов (находящихся в зоне действия разных пространств имен).

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

Хорошо забытое старое

Действительно, за разговорами о DLL, объектных библиотеках и сборках и прочем мы как-то подзабыли, что проблема повторного использования программных компонентов и их унификация возникла не 10 лет назад. Именно для решения этой задачи еще лет 40 назад была реализована идея разделения процедур компиляции (трансляция исходных модулей в объектные) и компоновки (объединения объектных модулей в один загрузочный), которая подразумевала, в частности, что для создания одной программы можно применять разные языки программирования, в том числе с использованием единых библиотек подпрограмм.

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

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

Другие статьи из раздела

Демонстрация Chloride Trinergy

Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.

Завершена реорганизация двух дочерних предприятий NEC Corporation в России

NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …

С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.

компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …

RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

30 ноября 2021 г. | Он-лайн формат
Dell Technologies Forum 2021

Обеспечение согласованной объектно-ориентированной среды программирования для локального сохранения и выполнения объектного кода, для локального выполнения кода, распределенного в Интернете, либо для удаленного выполнения.

Предоставление среды выполнения кода, в которой:

сведена к минимуму вероятность конфликтов в процессе развертывания программного обеспечения и управления его версиями;

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

исключаются проблемы с производительностью сред выполнения скриптов или интерпретируемого кода;

обеспечиваются единые принципы разработки для разных типов приложений, таких как приложения Windows и веб-приложения;

Обозреватель Internet Explorer может служить примером неуправляемого приложения, размещающего среду выполнения (в виде расширений типов MIME). Размещение среды выполнения в обозревателе Internet Explorer позволяет внедрять управляемые компоненты или элементы управления Windows Forms в HTML-документы. Такое размещение среды позволяет выполнять управляемый мобильный код и пользоваться его существенными преимуществами, в частности выполнением в условиях неполного доверия и изолированным хранением файлов.

На следующем рисунке демонстрируется взаимосвязь среды CLR и библиотеки классов с пользовательскими приложениями и всей системой. На рисунке также показано, как управляемый код работает в пределах более широкой архитектуры.

Возможности среды CLR

Среда CLR управляет памятью, выполнением потоков, выполнением кода, проверкой безопасности кода, компиляцией и другими системными службами. Эти средства являются внутренними для управляемого кода, который выполняется в среде CLR.

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

Среда выполнения также обеспечивает надежность кода, реализуя инфраструктуру строгой типизации и проверки кода, которую называют системой общих типов (CTS). Система общих типов обеспечивает самоописание всего управляемого кода. Различные языковые компиляторы корпорации Microsoft и независимых изготовителей создают управляемый код, удовлетворяющий системе общих типов . Это означает, что управляемый код может принимать другие управляемые типы и экземпляры, при этом обеспечивая правильность типов и строгую типизацию.

Кроме того, управляемая среда выполнения исключает многие часто возникающие проблемы с программным обеспечением. Например, среда выполнения автоматически управляет размещением объектов и ссылками на объекты, освобождая их, когда они больше не используются. Автоматическое управление памятью исключает две наиболее часто возникающие ошибки приложений: утечки памяти и недействительные ссылки на память.

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

Среда выполнения разработана для повышения производительности. Хотя общеязыковая среда выполнения предоставляет многие стандартные службы времени выполнения, управляемый код никогда не интерпретируется. Средство компиляции по требованию (JIT) позволяет выполнять весь управляемый код на машинном языке компьютера, где он запускается. Между тем диспетчер памяти устраняет возможность фрагментации памяти и увеличивает объем адресуемой памяти для дополнительного повышения производительности.

Наконец, среда выполнения может размещаться в высокопроизводительных серверных приложениях, таких как Microsoft SQL Server и службы IIS (Internet Information Services). Такая инфраструктура позволяет использовать управляемый код для написания собственной логики программ, пользуясь при этом высочайшей производительностью лучших производственных серверов, которые поддерживают размещение среды выполнения.

Приложения с графическим интерфейсом Windows (Windows Forms). См. статью Windows Forms.

Приложения Windows Presentation Foundation (WPF). См. статью Windows Presentation Foundation.

Сервисноориентированные приложения, использующие Windows Communication Foundation (WCF). См. статью Разработка сервисноориентированных приложений с помощью WCF.

Приложения, поддерживающие бизнес-процессы Windows Workflow Foundation (WF). См. Windows Workflow Foundation.

Почему так происходит? Что это такое и зачем нужен NET Framework ?

Наверное, вы знаете, что основное занятие программистов — написание кода. При этом они используют различные языки программирования, позволяющие сказать компьютеру, что он должен делать:

Microsoft NET Framework - что это такое?

Но есть одна проблема — языки программирования довольно примитивны. С их помощью можно легко выполнять простые действия вроде сложения и умножения. А всё остальное требует долгой и усердной работы. Хотите вывести текст или изображения на экран? Тогда придётся написать много кода, используя самые простые элементы языка.

Microsoft NET Framework - что это такое? - 2

Как установить Microsoft NET Framework

На момент написания статьи самая свежая версия — Microsoft NET Framework 4,7 . Именно её мы и будем устанавливать:

Как установить Microsoft NET Framework

Microsoft Net Framework можно установить и через Центр обновления Windows . Но многие отключают обновление Windows , поэтому данный метод будет предпочтительнее.

Перед установкой — Microsoft Net Framework можно установить на Windows 10 , Windows 8.1 и Windows 7 SP1 как на 32-битные, так и на 64-битные системы. Чтобы установка прошла без ошибок, Microsoft рекомендует иметь на жестком диске минимум 2.5 ГБ свободного пространства.

Microsoft предлагает два вида установщиков: веб-установщик и автономный установщик. Веб-установщик весит меньше 2 МБ, и скачивает все необходимые компоненты во время инсталляции. Поэтому вам потребуется стабильное соединение с интернетом.

Автономный установщик весит около 60 МБ, и не требует доступа к интернету во время инсталляции.

Оба установщика содержат одинаковые версии NET Framework , но мы предпочитаем использовать автономный установщик. Он надёжнее, и всегда будет под рукой, если потребуется переустановить NET Framework . После скачивания процесс установки не должен вызвать затруднений — просто следуйте инструкциям, появляющимся на экране. И тогда вы быстрее поймете, зачем нужен NET Framework 4 .

Как установить Microsoft NET Framework - 2

Обратите внимание, что версия 4.7 — это выполняемое обновление версий 4 , 4.5 , 4.5.1 , 4.5.2 , 4.6 , 4.6.1 и 4.6.2 . Поэтому не удаляйте предыдущие версии после установки. NET Framework 3.5 SP1 и более старые версии устанавливаются отдельно.

По умолчанию NET Framework инсталлирует английскую версию независимо от того, какой вы используете установщик. Для локализации нужно скачать соответствующий языковой пакет. На данный момент языковые пакеты для версии 4.7 доступны только в виде автономных установщиков.

Ещё кое-что о Microsoft Net Framework

Еще одна причина, зачем нужен NET Framework . Несколько лет назад Microsoft открыла исходный код NET Framework , позволив всем желающим вносить свой вклад в разработку платформы. В результате Microsoft стала самой активной организацией на GitHub .

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

Пожалуйста, оставьте ваши отзывы по текущей теме материала. За комментарии, дизлайки, подписки, лайки, отклики огромное вам спасибо!

С точки зрения разработчика ОС Windows - это в первую очередь набор базовых функций Win API, реализованных в виде DLL. До 1993 г. в Windows основной моделью создания многокомпонентных приложений было именно использование вспомогательных модулей поддержки в виде DLL (в свое время пришедших на смену классическому варианту, предполагающему создание единого исполняемого модуля путем включения в него процедур из двоичных LIB-библиотек). В 1993 г. Microsoft предложила новую модель многокомпонентных приложений - COM (Common Object Model). По большому счету, главная идея здесь состоит в применении в дополнение к исполняемому коду метаданных, обеспечивающих автоматический контроль за передачей параметров (а также унификация форматов параметров).

Конечно, можно говорить о достоинствах COM по сравнению с традиционными DLL (хотя достоинства всегда сопровождаются и недостатками, в данном случае в виде снижения производительности), но я категорически не согласен с высказываниями некоторых авторов, смысл которых сводится к следующему: "После выхода COM разработчики поняли, что им больше не надо писать весь код приложений с нуля". Если вдуматься, использование готовых компонентов - ключевая технология программирования на протяжении всей истории этого вида деятельности.

Структура и логика работы

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

Common Language Runtime

Однако, в отличие от Java, CLR будет выполнять код не в режиме классического интерпретатора, а путем предварительной компиляции в машинный код отдельных фрагментов программы или целого приложения (рис. 2). Первый вариант - основной, при этом применяется так называемый Just-In-Time компилятор, который выполняет преобразование MSIL в машинный код по мере обращения к соответствующим процедурам (т. е. неиспользуемые фрагменты программы вовсе не компилируются). Данный подход также хорошо известен; он, в частности, уже более шести лет используется в платформе "1С:Предприятие".

Как известно, режим интерпретации имеет два главных преимущества по сравнению с использованием машинного кода: повышение безопасности программ (точнее, защищенности системы в целом от действия конкретных программ) и упрощение адаптации программ к конкретной аппаратной платформе. С учетом этого рассмотрим структуру CLR-модулей.

CLR-модули состоят из исполняемого кода и метаданных. Метаданные (например, различные декларации полей, методов, свойств и событий) широко применяются и в COM-технологии, что и составляет ее основное отличие от обычных двоичных DLL. В CLR состав метаданных значительно расширен, что позволяет более эффективно контролировать версии, проверять надежность источников поступления программ и т. п.

Исполняемый код в основном представлен в виде "управляемого кода" (возможны и фрагменты "неуправляемого кода", но они будут отныне большой редкостью). Это означает, что CLR не просто преобразует MSIL в машинные инструкции, а выполняет эти действия с учетом определенных внешних установок. Например, Модуль1 может задать свой собственный набор прав, предоставляемый вызываемому им Модулю2, запретив, в частности, любые операции изменения файлов.

Эта возможность широко используется в многопользовательской Интернет-игре для программистов "Террариум", анонсированной на форуме PDC 2001. В ней каждый может написать программные модули, реализующие выбранные стратегии, которые другие участники загружают на свои компьютеры. Безопасность тут обеспечивается именно благодаря четкому контролю за допустимыми действиями "инородных тел". В общем, в CLR мы видим реализацию идей Интернет-браузеров, которые представляют промежуточную среду выполнения программ, но только со значительно более высоким уровнем управляемости прав.

Во-первых, реализована иерархическая система имен объектов типа, получившая название "пространство имен". Теперь вместо плоского идентификатора "ИмяПриложения.ИмяКласса" можно использовать "ИмяПриложения.Имя1.Имя2. ИмяКласса".

Во-вторых, изменен порядок регистрации объектов, что непосредственно связано с появлением еще одного нового термина - сборка (Assembly).

Пример взаимодействия компонентов

В целом эта манипуляция ничем не отличается от создания COM-объекта в VB 6.0, за исключением лишь синтаксиса операции возврата значения функции (раньше мы бы просто написали NowTime = Now).

Посмотрим теперь на структуру проекта в окне Solution Explorer (рис. 3). Отметим, что физически наш проект называется ClassLibrary3, а логическое имя библиотеки - MyClassLibrary (смысл этих компонентов прояснится в дальнейшем). Помимо модуля класса, здесь в явном виде описаны три ссылки на базовые классы, подключенные к проекту по умолчанию. Впрочем, на самом деле подключенных классов гораздо больше (например, в их число входят все классы библиотеки Microsoft.Visual Basic). Здесь же виден новый модуль с описанием данной сборки AssemblyInfo.vb, содержимое которого можно не только посмотреть, но и отредактировать (рис. 4). Кроме того, видно, что к проекту были автоматически подключены еще два базовых класса (см. ключевое слово Imports) и что данную библиотеку можно зарегистрировать и в качестве COM-объекта - тут прописан ее GUID.

Рис. 3. Структура проекта ClassLibrary.

Рис. 4. Описание сборки проекта.

Теперь создадим DLL и посмотрим каталог ClassLibrary3, куда записаны файлы проекта (рис. 5). Результирующий файл ClassLibrary3.dll находится в подкаталоге BIN, а в OBJ - еще несколько копий этой же DLL, полученных в результате отладки.

Рис. 5. Состав файлов проекта.

Для отладки сервера создадим клиентскую программу в виде Console Application, в которой с помощью сформированного ранее компонента попробуем получить текущее время. Для этого откроем окно Add Reference и с помощью кнопки Browse подключим к проекту библиотеку ClassLibrary3.dll (рис. 6). Введем такой код:

Запустим его на выполнение и убедимся, что все работает, как задумано. По крайней мере, внешне все не отличается от того, как мы раньше работали с COM-объектами (только все теперь делается заметно медленнее). Но отметим один любопытный момент. Опять откроем проект ClassLibrary3 и заменим в нем старый код на такой вариант:

Откомпилируем его, полностью заменив старую DLL. Но если мы сейчас зайдем в каталог ConsoleApplication2\Bin, где хранится созданный ранее исполняемый файл клиентского проекта, и запустим его на выполнение, то он будет работать без проблем в старом варианте. Почему? Да потому, что в этом же каталоге вы обнаружите предыдущий вариант ClassLibrary3.dll, которая была автоматически переписана при подключении соответствующей ссылки.

Становится понятен смысл операторных скобок Namespace, использованных в коде класса, - с их помощью описывается иерархическая система имен объектов. Подправим этот код, чтобы можно было применять более компактное обращение к именам объектов:

Теперь "сухой остаток": что же нового мы увидели на этом простом примере по сравнению с традиционным использованием COM-объектов?

Во-первых, проблема согласования версий применяемых компонентов решается тривиальным копированием нужных файлов в каталог клиентского приложения (в том числе с помощью создания специальной копии COM-библиотек). Во-вторых, с помощью операторных скобок Namespace мы можем создавать иерархическую систему имен объектов в отличие от двухзвенной DllName.ClassName, принятой в COM, которая теперь является частным случаем.

Покажем детальнее, как создать такую систему имен, на примере проекта типа Class Library и имени ClassLibraryN:

Соответственно, в клиентском приложении используемые нами классы будут описаны следующим образом:

Обратите внимание, что тут мы специально использовали одинаковое имя Class1 для разных объектов (находящихся в зоне действия разных пространств имен).

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

Хорошо забытое старое

Действительно, за разговорами о DLL, объектных библиотеках и сборках и прочем мы как-то подзабыли, что проблема повторного использования программных компонентов и их унификация возникла не 10 лет назад. Именно для решения этой задачи еще лет 40 назад была реализована идея разделения процедур компиляции (трансляция исходных модулей в объектные) и компоновки (объединения объектных модулей в один загрузочный), которая подразумевала, в частности, что для создания одной программы можно применять разные языки программирования, в том числе с использованием единых библиотек подпрограмм.

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

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

Другие статьи из раздела

Демонстрация Chloride Trinergy

Chloride
Демонстрация Chloride Trinergy
Впервые в России компания Chloride Rus провела демонстрацию системы бесперебойного электропитания Chloride Trinergy®, а также ИБП Chloride 80-NET™, NXC и NX для своих партнеров и заказчиков.

Завершена реорганизация двух дочерних предприятий NEC Corporation в России

NEC Нева Коммуникационные Системы
Завершена реорганизация двух дочерних предприятий NEC Corporation в России
С 1 декабря 2010 года Генеральным директором ЗАО «NEC Нева Коммуникационные Системы» назначен Раймонд Армес, занимавший ранее пост Президента Shyam …

С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.

компания «Гротек»
С 17 по 19 ноября 2010 в Москве, в КВЦ «Сокольники», состоялась VII Международная выставка InfoSecurity Russia. StorageExpo. Documation’2010.
Новейшие решения защиты информации, хранения данных и документооборота и защиты персональных данных представили 104 организации. 4 019 руководителей …

RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша

Adaptec by PMC
RAID-контроллеры Adaptec Series 5Z с безбатарейной защитой кэша
Опытные сетевые администраторы знают, что задействование в работе кэш-памяти RAID-контроллера дает серьезные преимущества в производительности …

Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy

Chloride
Трехфазный ИБП Chloride от 200 до 1200 кВт: Trinergy
Trinergy — новое решение на рынке ИБП, впервые с динамическим режимом работы, масштабируемостью до 9.6 МВт и КПД до 99%. Уникальное сочетание …

30 ноября 2021 г. | Он-лайн формат
Dell Technologies Forum 2021

Читайте также: