Эндрю Троелсен - ЯЗЫК ПРОГРАММИРОВАНИЯ С# 2005 И ПЛАТФОРМА .NET 2.0. 3-е издание

Рис. 13.11. Файл mscoree.dll находится в каталоге system32

После загрузки mscoree.dll по реестру системы Win32 (да, по реестру этой системы) выясняется номер последней из установленных версий и путь установки .NET Framework (используется ветвь HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework, рис. 13.12).

Рис. 13.12. Выяснение версии и пути установки платформы .NET

После определения версии и пути установки платформы .NET в память загружается нужная версия mscorwks.dll/mscorsvr.dll. На моей машине корневым путем установки платформы .NET является C:\WINDOWS\Microsoft.NET\Frаmеwork. В указанном каталоге есть специальные подкаталоги для .NET версии 1.0.1.1 и (на время создания книги) текущей версии 2.0 (см. рис. 13.13, ваши номера версий могут быть другими).

Когда mscoree.dll определяет (с помощью реестра системы), какую версию mscorwks.dll/mscorsrv.dll загрузить, читается также раздел Policy (Политика) ветви HKEY_LOCAL_MACHINE\Software\Microsoft\.NETFramework реестра. В этот раздел записывается информация обновлений CLR, которые могут выполняться с безопасностью. Например, если запускается компоновочный блок, который был построен с использованием . NET версии 1.0.3.705, mscoree.dll узнает из файла политики, что вполне безопасно загрузить версию 1.1.4322.

Рис. 13.13. Файл mscorwks.dll версии 2.0

Все это происходит незаметно в фоновом режиме и только тогда, когда известно, что обновление обеспечивает правильное выполнение. В редких случаях возникает необходимость заставить mscoree.dll загрузить конкретную версию CLR, и тогда вы можете использовать для этого файл *.config клиента.

‹?xml version="l.0" encoding="utf-8"?›

‹configuration›

‹startup›

‹requiredRuntime version ="1.0 .3705"/›

‹/startup›

‹/configuration›

Здесь элемент ‹requiredRuntime› указывает, что для загрузки данного компоновочного блока следует использовать только версию 1.0.3705. Поэтому, если на целевой машине нет полной инсталляции .NET версии 1.0.3705, конечный пользователь увидит окно с информацией об ошибке среды выполнения, показанное на рис. 13.14.

Рис. 13.14. Элемент ‹requiredRuntime› порождает сообщение об ошибке среды выполнения, если указанная версия CLR не установлена [2] Сообщение гласит: "Чтобы выполнить это приложение, установите одну из следующих версий .NET Framework: v1.0.3705. Обратитесь к разработчику приложения для получения инструкций по поводу установки нужной версии .NET Framework."

Только что описанный процесс обозначил основные шаги, предпринимаемые операционной системой Windows для хостинга CLR по умолчанию, когда запускается выполняемый компоновочный блок. Но Microsoft предлагает множество приложений, которые могут действовать в обход используемого по умолчанию поведения, используя программную загрузку CLR. Например. Microsoft Internet Explorer может загружать своими встроенными средствами пользовательские элементы управления Windows Forms (управляемый эквивалент теперь уже устаревших элементов управления ActiveX). Последняя версия Microsoft SQL Server (с кодовым названием Yukon и официальным названием SQL Server 2005) также способна осуществлять непосредственный хостинг CLR.

Наконец. Microsoft определила набор интерфейсов, позволяющих разработчикам строить их собственные пользовательские хосты CLR. Это можно сделать , используя соответствующий программный код C/C++ или библиотеку COM-типа (mscorеe.tlb). Хотя сам процесс построения пользовательского хоста CLR исключительно прост (особенно при использовании библиотеки COM-типа), эта тема выходит за рамки нашего обсуждения. Если вам нужна дополнительная информация по данному вопросу, в Сети вы можете найти множество статей на эту тему (просто выполните поиск по ключу "CLR hosts").

Целью этой главы было выяснение того, как обрабатывается выполняемый образ .NET. Вы имели возможность убедиться в том, что уже привычное понятие процесса Win32 было внутренне изменено с тем, чтобы адаптировать его к требованиям CLR. Отдельный процесс (которым можно программно управлять с помощью типа System.Diagnostiсs.Process) теперь компонуется из множества доменов приложения, имеющих изолированные и независимые границы в рамках этого процесса. Один процесс может содержать множество доменов приложения, каждый из которых может обрабатывать и выполнять любое число связанных компоновочных блоков.

Кроме того, каждый домен приложения может содержать любое число контекстов. Используя этот дополнительный уровень изоляции типов, среда CLR может гарантировать, что объекты со специальными требованиями будут обработаны корректно. Глава завершается рассмотрением деталей того, как сама CLR обрабатывается операционной системой Win32.

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

Наше обсуждение снова начнется с рассмотрении типа делегата .NET, чтобы прийти к пониманию его внутренней поддержки асинхронных вызовов методов. Вы увидите, что такой подход позволяет автоматически вызвать метод во вторичном потоке выполнения. Затем мы исследуем типы пространства имен System.Тhreading. Будет рассмотрено множество типов (Thread.ThreadStart и т.д.), позволяющих с легкостью создавать дополнительные потоки. Конечно, сложность разработки многопоточных приложений заключается не в создании потоков, а в гарантии того, что ваш программный код будет иметь надежные средства обработки конфликтов при конкурентном доступе к общедоступным ресурсам. Поэтому завершается глава рассмотрением различных примитивов синхронизации, предлагаемых каркасом .NET Framework.

В предыдущей главе обсуждалось понятие потока, который был определен, как путь исполнения в рамках выполняемого приложения. И хотя многие приложения .NET имеют только один поток и, тем не менее, оказываются очень полезными, первичный поток компоновочного блока (порождаемый средой CLR при выполнении Main()) может создавать вторичные потоки для решения дополнительных задач. Реализуя дополнительные потоки, вы можете строить приложения с лучшим откликом на действия пользователя (но не обязательно более быстро выполняющие свои задачи).