Количество экземпляров CLR и GC, работающих на машине?

Я создаю 2 приложения .NET и запускаю их на машине - сколько CLR и gc будет там?

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

tasklist /m mscor*

Является ли это несколько CLR на самом деле или один CLR в качестве COM-сервера для всех процессов .NET?

Ответ 1

Каждый процесс будет иметь свою собственную копию CLR в качестве процесса хостинга. Однако, поскольку CLR - это всего лишь пара DLL, Windows сможет совместно использовать DLL между процессами. Для получения дополнительной информации см. http://msdn.microsoft.com/en-us/magazine/cc301727.aspx

Ответ 2

Управляемый exe имеет дополнительный заголовок CLR дополнение к Portable Executable (формат PE). Теперь ОС может определить, является ли запущенный exe "управляемым" exe, и, следовательно, загружает CLR за сцену и дает ему контроль.

mscoree.dll - это плагин dll (последняя версия этого файла всегда присутствует в папке Windows/System32 и, следовательно, знает, как загружать текущие и более старые версии CLR.)
mscorwks.dll - это фактическая реализация CLR. Вы найдете несколько версий этой DLL, если у вас установлено несколько версий установленной инфраструктуры. Правильная версия этой DLL загружается dll dll.

Из вышесказанного следует, что каждый управляемый исполняемый процесс имеет свою собственную копию CLR (2 Dlls). ManagedExecutable1 может использовать CLR v1, где, поскольку ManagedExecutable2 может использовать CLR v2. На данный момент они не разделены.
Сборщик мусора является частью CLR и, следовательно, также отличается между процессами для управляемых исполняемых файлов.

Ответ 3

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

В процессе есть только одна куча, а также один GC, который приостанавливает все управляемые потоки во время сбора. Таким образом, вы можете выполнить итерацию процессов и проверить, загружен ли mscorlib, если вы можете предположить, что на нем запущена .NET CLR и GC. Я уверен, что должны быть лучшие способы определить, есть ли у хоста CLR, проверьте также API CLR.

Попробуйте Джеффри Рихтера книгу CLR через С#, чтобы иметь более глубокое понимание.

Код ниже выполняет итерации процессов .NET

// Import these namespaces
using System.Diagnostics;
using System.ComponentModel;

// Here is the code
Process[] prcs = Process.GetProcesses();
foreach (Process prc in prcs)
{
    try
    {
        foreach (ProcessModule pm in prc.Modules)
        {
            if (pm.ModuleName.Contains("mscorlib"))
            {
                Console.WriteLine(prc.ProcessName);
            }
        }
    }
    catch (Win32Exception exWin)
    {
        // Cannot detemine process modules ... some will deny access
    }
}

Ответ 4

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

И в .NET-мире процесс тесно связан с appdomain. Вот почему я думаю, что это является хорошей отправной точкой.