Что управляет версией .NET CLR, которая загружается CorBindToRuntimeEx?

Question

Я использую следующий неуправляемый код C ++ для создания экземпляра CLR из надстройки Excel 2003 (прокладка COM для надстройки .NET):

    hr = CorBindToRuntimeEx(
        0, // version, use default
        0, // flavor, use default
        0, // domain-neutral"ness" and gc settings 
        CLSID_CorRuntimeHost, 
        IID_ICorRuntimeHost, 
        (PVOID*) &m_pHost);

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

Вчера я впервые запустил Process Explorer, и это было довольно показательно, показывая следующее на одной из проблемных машин:

process     pid   type   Handle or DLL
-------     ---   ----   -------------
procexp.exe 5056  DLL    c:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\mscorworks.dll
EXCEL.EXE   7180  DLL    c:\WINDOWS\Microsoft.NET\Framework\v1.1.4322\mscorworks.dll

, то есть Excel загрузил неправильную версию среды выполнения дажехотя более новый доступен.Теперь мне нужно выяснить, почему.

Несколько возможностей, которые приходят на ум:

1. Есть что-то странное с приоритетом создания CLR на конкретной машине, хотядокументы MS (http://msdn.microsoft.com/en-us/library/ms231419.aspx) указывают на то, что вы всегда получите самую новую версию, если не запросите конкретную версию.
2. Еще одна надстройка в Excel уже (намеренно) создала .NET 1 CLR и Excelне может разместить более одного.

Я сильно подозреваю, что второе из них, но не знаю, как это доказать / исправить.

Кто-нибудь видел подобное поведение? Есть предложения?о том, что происходит?

Несколько других замечаний:

• Все рабочие станции работают под управлением Windows XP SP3
• Excel 2003 SP3 - единственная версия Excel в нашеморганизация

Я не могу изменить ни одно из этих значений, поэтому более новая версия Excel не подходит.

Answer 1

Можете ли вы использовать GetCORVersion , чтобы проверить, загружен ли уже CLR?И если GetCORVersion возвращает v1.x в качестве загруженной версии CLR, прервите загрузку CLR и представьте пользователю сообщение об ошибке.

Является ли миграция вашей надстройки в .net v4 вариантом?v4 поддерживает внутрипроцессное параллельное размещение CLR ((v1.x ИЛИ V2) И V4 и новее).Посмотрите на CLRCreateInstance .

Ссылки:
Обзор хостинга CLR
В процессе работы бок о бок @ Журнал MSDN

Answer 2

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

Проблема в том, что перед вами была загружена надстройка, которая просила загрузить версию CLR 1.1. Вот где доллар останавливается, процесс может иметь только одну версию CLR. Вы можете запросить загрузку версии 2.0.50727 в вашем вызове CorBindToRuntimeEx (), который вам нужен для вашей надстройки. Но это не удастся. Запрос версии по умолчанию будет успешным, но теперь ваша надстройка не сможет загрузиться.

Угол «чего-то мягкого» заключается в том, что вы можете технически изменить порядок загрузки надстроек, гарантируя, что CLR 2.0 будет загружен первым. На самом деле не уверен, как это сделать. Надстройка, которая требует 1.1, имеет разумные шансы по-прежнему работать правильно. Спросите на сайте superuser.com, хотите ли вы это сделать.

Существует долгосрочное решение, CLR версии 4 поддерживает параллельное управление версиями CLR. Не то, что тебе сейчас поможет.