C#에서 잘못된 어셈블리 참조를 찾는 방법

Question

C#/Azure 응용 프로그램에서 잘못된 어셈블리 참조 문제의 원인을 추적하는 데 매우 어려움을 겪고 있습니다. 내가 찾고있는 것은 내 문제에 대한 정확한 해결책을 누군가에게 알려주는 것이 아니라 시스템이 어떤 어셈블리를로드하려고하는지, 그리고 왜 이것을 하는지를 찾는 방법을 찾는 것이다.

우리가 Azure 도구를 업그레이드 할 때 문제가 발생했습니다. 정말 이상한 점은 Entity Framework를 통해 데이터베이스 함수를 호출하려고 할 때만 오류가 발생한다는 것입니다. EF는이 모든 암시 적 어셈블리 로딩과 일부 혼란스러워지고 버전 2.2.0.0 대신 Microsoft.ServiceBus 1.8.0.0을로드하려고 시도하는 방법 (또는 해당 어셈블리를 찾는 방법)을 수행합니다.

우리는 Entity Framework 4.0을 사용하고 있습니다. 그리고 참고로 스토어드 프로 시저를 호출하고 다른 종류의 쿼리를 수행 할 수 있습니다. 이 문제를 일으키는 db 함수 호출 일뿐입니다.

내 응용 프로그램을 통해 높거나 낮음을 검색했으며 1.8.0.0에 대한 참조를 찾을 수 없으며 1.8.0.0 dll을 아무데도 찾을 수 없습니다. 1.8.0.0에 대한 언급을 고수하고있는 제 3 자 라이브러리에 대한 최신 정보가있을 수는 있지만 가능성은 희박합니다.

여전히 내 목표는 누군가 X가 내 문제라고 말하지 않고, Entity Framework를 감시 할 수있는 방법과 그 어셈블리를로드하려고하는 이유를 알 수있는 단서를 제공합니다. 찾을 것으로 예상하고 실제로 무엇을 찾고 있습니다.

여기 내 전체 스택 추적입니다.

'Microsoft.ServiceBus, 버전 = 1.8.0.0, Culture = neutral, PublicKeyToken = 31bf3856ad364e35'또는 해당 종속성 중 하나를로드 할 수 없습니다. 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다. (HRESULT에서 예외 : 0x80131040) 시스템에서 System.Reflection.RuntimeAssembly._nLoad (의 AssemblyName 파일 이름, 문자열 코드베이스, 증거 assemblySecurity, RuntimeAssembly locationHint, StackCrawlMark & ​​stackMark, IntPtr입니다 pPrivHostBinder, 부울 throwOnFileNotFound, 부울 forIntrospection, 부울 suppressSecurityChecks) 에서 . System.Data.Metadata에서 System.Reflection.Assembly.Load (assemblyRef의 AssemblyName) 에서 Reflection.RuntimeAssembly.InternalLoadAssemblyName (assemblyRef의 AssemblyName, 증거 assemblySecurity, RuntimeAssembly reqAssembly, StackCrawlMark 및 stackMark, pPrivHostBinder을 IntPtr 부울 throwOnFileNotFound 부울 forIntrospection 부울 suppressSecurityChecks) .Edm.MetadataAssemblyHelper.SafeLoadReferencedAssembly (AssemblyName assemblyName) at System.Da ta.Metadata.Edm.MetadataAssemblyHelper.d__0.MoveNext() at System.Data.Metadata.Edm.AssemblyCache.LoadAssembly (어셈블리 어셈블리, 부울 loadReferencedAssemblies, ObjectItemLoadingSessionData loadingData) at System.Data.Metadata.EdemblyCache.LoadAssembly Assembly 어셈블리, 부울 loadReferencedAssemblies, ObjectItemLoadingSessionData loadingData) System.Data.Metadata.Edm.AssemblyCache.LoadAssembly (어셈블리 어셈블리, 부울 loadReferencedAssemblies, ObjectItemLoadingSessionData loadingData)의 System.Data.Metadata.Edm.AssemblyCache.LoadAssembly의 loadReferencedAssemblies, ObjectItemLoadingSessionData loadingData) System.Data.Metadata.Edm.AssemblyCache.LoadAssembly에서 (어셈블리 어셈블리, 부울 loadReferencedAssemblies, KnownAssembliesSet knownAssemblies, EdmItemCollection edmItemCollection, Acti on`1 logLoadMessage 개체 및 loaderCookie, Dictionary`2 & typesInLoading, List`1 및 오류) System.Data.Metadata.Edm.ObjectItemCollection.LoadAssemblyFromCache (ObjectItemCollection objectItemCollection, 조립 조립, 부울 loadReferencedAssemblies, EdmItemCollection edmItemCollection, Action`1 logLoadMessage에서 ) System.Data.Metadata.Edm.ObjectItemCollection에서.System.Data.Objects.ObjectContext.CreateQuery [T] (String queryString, ObjectParameter [] parameters)에서 에있는 System.Data.Metadata.Edm.MetadataWorkspace.ImplicitLoadAssemblyForType (형식 유형, 어셈블리 호출 어셈블리)의 ImplicitLoadAllReferencedAssemblies (어셈블리 어셈블리, EdmItemCollection edmItemCollection) ) at Pallas.FlightBridge.Services.Internal.Data.Model.FlightBridgeDatabaseContext.TripPermissions (Nullable`1 companyPersonId) c : \ Users \ RMacgrogan \ dev \ flightbridge \ BaseOps \ trunk \ FB 버전 7.8 \ code \ InternalServices \ Data \ Model \ FlightBridgeDataModel.Designer.cs : 줄 3778 at Pallas.FlightBridge.Services.Internal.Data.Repository.TripRepository.GetTripAndOrdersAndTravelers (Int32 tripId, Int32 companyPersonId) (c : \ Users \ RMacgrogan \ dev \ flightbridge \ BaseOps \ trunk \ FB 버전 7.8 \ code \ InternalServices \ Data \ Repository \ TripRepository.cs : 줄 50

Answer 1

하늘색 도구 업그레이드 후에 비슷한 문제가 발생했습니다. 우리와 함께, 그것은 Microsoft.WindowsAzure.Storage의 다른 버전을 찾고있었습니다. 이것은 우리를 위해 그것을 고정. 이것은 작업자 역할에서의 app.config에서, 그러나 동일한 섹션도의 Web.config에서 유효합니다 : 당신을 위해 그래서

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
     <assemblyIdentity name="Microsoft.WindowsAzure.Storage" publicKeyToken="31bf3856ad364e35" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.1.0.0" newVersion="2.1.0.0" /> 
    </dependentAssembly> 
    </assemblyBinding> 
</runtime> 

, 그것은 비슷한 바인딩 리디렉션이 문제가 역할의 구성에 필요한 것 같다 파일. 다음과 같은 내용 :

<runtime> 
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1"> 
    <dependentAssembly> 
     <assemblyIdentity name="Microsoft.ServiceBus" publicKeyToken="31bf3856ad364e35" /> 
     <bindingRedirect oldVersion="0.0.0.0-2.2.0.0" newVersion="2.2.0.0" /> 
    </dependentAssembly> 
    </assemblyBinding> 
</runtime> 

왜 이런 일이 발생합니까?

Microsoft에서 EF, WindowsAzure Storage 등의 라이브러리를 빌드하면 다른 라이브러리에 종속됩니다. dll이 빌드 될 당시 Microsoft는 Microsoft.ServiceBus와 같은 라이브러리 버전 1.8에 의존 할 수있었습니다. 이러한 종속성은 종종 Azure SDK와 같은 .NET 프레임 워크의 일부입니다.

나중에이 라이브러리의 최신 버전이 출시됩니다. 프로젝트는 .NET 프레임 워크, Azure SDK 또는 특정 라이브러리의 최신 버전과 원래 라이브러리의 종속성과 다른 버전 (1.8 대신 2.2)에 종속 될 수 있습니다. 문제의 라이브러리 (EF)는 컴파일 된 버전 (1.8)을 찾고, dll (2.2)의 최신 버전이 있어도 예외를 throw합니다. 해결 방법은 바인딩 리디렉션을 사용하여 앱을 구성하여 종속성을 알려주는 것입니다. "이봐,이 새 버전을 사용해도됩니다."

사실 멀티 프로젝트 솔루션을 사용하는 경우 새로운 패키지를 설치할 때마다 nuget에서 이러한 바인딩 리디렉션을 다른 프로젝트에 넣기 시작했습니다. 기본적으로 솔루션의 모든 프로젝트에 "이 라이브러리를 사용하고 있다면 솔루션의 새 버전이 있습니다. 이전에 사용하던 이전 버전 대신이 새 버전을 사용하십시오."