2011-06-08 13 views
5

:CorBindToRuntimeEx tarafından yüklenen .NET CLR sürümünü yöneten nedir? Ben (eklenti bir .NET için bir COM şim) bir Excel 2003 eklentisinin gelen CLR örneğini için aşağıdaki yönetilmeyen C++ kodu kullanıyorum

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

ve makinelerin büyük çoğunluğundan Kuruluşumuzda (birkaç yüz) bu, çok sayıda CLR sürümleri yüklü olanlar bile mükemmel çalışır; Ancak, birkaç makinede, CLR'nin yanlış (eski) bir sürümü başlatılır ve ardından .NET 2 çalışma zamanı gerektirdiği için derleme yüklemesi başarısız olur. Ben Process Explorer koştu ve bu sorunun makinelerden birinde şu gösteren oldukça açıklayıcı oldu ilk defa

Dün: Excel çalışma zamanı yanlış sürümü bile daha yeni bir olsa yüklendikten yani

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 

kullanılabilir. Şimdi nedenini bulmalıyım.

akla gelen birkaç ihtimal:

belirli makinedeki CLR örnekleme ait 'öncelikli' ile tuhaf bir şey yoktur
  1. hatta MS docs (gerçi http://msdn.microsoft.com /en-us/library/ms231419.aspx), belirli bir sürümü istemediğiniz sürece her zaman en yeniyi alacağınızı gösterir.
  2. Excel'de başka bir eklenti zaten (kasıtlı olarak) bir .NET 1 CLR başlattı ve Excel birden fazla barındıramaz.

şiddetle bu ikincisini şüpheli ama/kanıtlamak nasıl düzeltebilirim bilmiyorum.

Benzer davranışlar gören oldu mu? Neler olduğu hakkında herhangi bir öneriniz var mı?

Birkaç diğer notlar:

  • Tüm iş istasyonları
  • Excel 2003 SP3

Ben birini değiştiremezsiniz organizasyonumuzda Excel'in tek sürümüdür Windows XP SP3 çalıştıran Bu yüzden daha yeni bir Excel sürümü bir seçenek değildir.

+1

Bu sorun şu şekilde görünebilir: http://support.microsoft.com/kb/948461 belki de söz konusu makinenin VSTO'nun eski bir sürümü vardır. Bu sorun olup olmadığını tespit etmeye çalışacağım. –

+0

Makinenin * doğru * VSTO'nun kurulduğunu görüyoruz, bu da sorun değil. Dolayısıyla, bu durumun Excel'in eklentileri, yani önceden yüklenmiş bazı eklenti isteklerini v1 CLR'yi başlattığı sıraya göre gitme olasılığı daha yüksek görünmektedir. –

cevap

3

Bu rezil CLR sürümü enjeksiyon sorundur. Bu, .NET'te bir kabuk uzantısı yazdığınızda aldığınız gerçekten kötü bir türün aksine biraz yumuşak bir türüdür.

Sorun, kendinizden önce yüklenen bir eklenti vardı ve yüklenecek CLR'nin 1.1 sürümünü sordu.Paranın durduğu yer burası, bir süreç CLR'nin sadece bir versiyonuna sahip olabilir. CorBindToRuntimeEx() çağrınıza yüklenecek 2.0.50727 sürümü için istekte bulunabilirsiniz, eklentiniz için ihtiyacınız olanı budur. Ama bu başarısız olur. Varsayılan sürümü sormak başarılı olacak, ancak artık eklentiniz yüklenmeyecek.

'Hafif bir şey' açısı, eklentilerin yüklenme sırasını teknik olarak değiştirebilmeniz ve önce CLR 2.0'ın yüklenmesini sağlamanızdır. Aslında bunu nasıl yapacağınızdan emin değilim. 1.1 gerektiren eklenti, doğru şekilde çalışmanın makul oranlarına sahiptir. Yapmak istediğiniz şey buysa superuser.com'a sorun.

Uzun süreli bir çözüm var, CLR sürüm 4, CLR'nin işlem içi yan yana sürümlerini destekler. Şu anda size yardımcı olacak bir şey değil.

3

CLR'nin önceden yüklenip yüklenmediğini kontrol etmek için GetCORVersion kullanabilir misiniz? Ve GetCORVersion yüklenen CLR sürümü olarak v1.x döndürürse, CLR'yi yüklemeyi iptal edin ve kullanıcıya bir hata iletisi gönderin.

Eklentinizi .net v4'e geçirme seçeneği var mı? v4, CLR ((v1.x VEYA V2) VE V4 ve daha yeni) işlemlerinin yan yana barındırılmasını destekler. CLRCreateInstance'a bakın.

Referanslar:
CLR Hosting Overview
In-Process Side-by-Side @ MSDN Magazine