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

 }
}

Чтобы увидеть пример возможного вывода программы, давайте проверим затрушенные модули для. процесса, выполняемого в рамках рассматриваемого здесь консольного приложения ProcessManipulator. Для этого запустите приложение, выясните значениеPID, соответствующее ProcessManipulator.exe, и передайте это значение методу EnumModsForPid (не забудьте соответствующим образом обновить метод Main. Вы, наверное, удивитесь, увидев весь список модулей *.dll, которые используются для такого простого консольного приложения (atl.dll, mfc42u.dll, oleaut32.dll и т.д.). На рис. 13.5 показан результат запуска.

Рис. 13.5. Перечень загруженных модулей в рамках выполняющегося процесса

Начало и остановка процессов с помощью программных средств

В завершение этого раздела мы рассмотрим методы Start и Kill типа System.Diagnostics.Process. По именам этих методов вы можете догадаться, что они обеспечивают, соответственно, программный запуск и программное завершение процесса. Рассмотрите, например, вспомогательный статический метод StartAndKillProcess.

public static void StartAndKillProcess {
 // Запуск Internet Explorer.
 Process ieProc = Process.Start("IExplore.exe", "www.intertechtraining.com");
 Console.Write("-› Нажмите ‹Enter›, чтобы завершить {0}…", ieProc.ProcessName);
 Console.ReadLine;
 // Завершение процесса iexplorer.exe.
 try {
 ieProc.Kill;
 } catch {} // Если пользователь уже завершил процесс.…
}

Статический метод Process.Start является перегруженным. Как минимум, вы должны указать имя процесса, который следует запустить (например, Microsoft Internet Explorer). В этом примере используется вариация метода Start, позволяющего указать любые дополнительные аргументы, передаваемые точке входа программы (т.е. методу Main).

Метод Start, кроме того, позволяет передать тип System.Diagnostics. ProcessStartInfo, чтобы указать дополнительную информацию о том, как должен стартовать данный процесс. Вот формальное определение ProcessStartInfo (подробности можно найти в документации .NET Framework 2.0 SDK).

public sealed class System.Diagnostics. ProcessStartInfo : object {
 public ProcessStartInfo;
 public ProcessStartInfo(string fileName);
 public ProcessStartInfo(string fileName, string arguments);
 public string Arguments { get; set; }
 public bool CreateNoWindow { get; set; }
 public StringDictionary EnvironmentVariables { get; }
 public bool ErrorDialog { get; set; }
 public IntPtr ErrorDialogParentHandle { get; set; }
 public string FileName { get; set; }
 public bool RedirectStandardError { get; set; }
 public bool RedirectStandardInput { get; set; }
 public bool RedirectStandardOutput { get; set; }
 public bool UseShellExecute { get; set; }
 public string Verb { get; set; }
 public string[] Verbs { get; }
 public ProcessWindowStyle WindowStyle { get; set; }
 public string WorkingDirectory { get; set; }
 public virtual bool Equals(object obj);
 public virtual int GetHashCode;
 public Type GetType;
 public virtual string ToString;
}

Независимо от того, какую версию метода Process.Start вы вызовете, будет возвращена ссылка на новый активизированный процесс. Чтобы завершить выполнение процесса, просто вызовите метод Kill уровня экземпляра.

Исходный код. Проект ProcessManipulator размещен в подкаталоге, соответствующем главе 13.

Домены приложений .NET

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

• Домены приложения являются ключевым аспектом независимой от ОС природы платформы .NET, поскольку такое логическое деление абстрагируется от того, как именно ОС представляет загруженный выполняемый объект.

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

• Домены приложения обеспечивают лучший уровень изоляции для загруженного приложения. Если один домен приложения в рамках процесса "терпит неудачу", остальные домены приложений могут продолжать функционировать.

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

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

После этого CLR создает дополнительные домены приложения по мере необходимости, Если потребуется (хотя это и маловероятно), вы можете программно создавать домены приложения в среде выполнения в рамках выполняемого процесса, используя статические методы класса System.AppDomain. Этот класс оказывается также полезным для осуществления низкоуровневого контроля доменов приложения. Основные члены этого класса описаны в табл. 13.4.