ResolveEventArgs.RequestingAssembly가 Null입니다.

Reflection을 통해 동적으로 어셈블리를로드하려고합니다.ResolveEventArgs.RequestingAssembly가 Null입니다.

project 
    \-- BIN 
     |-- myApp.exe 
     |-- SOMEEXTENTION1 
     | |-- someExtention1.dll 
     | \-- itsDependency1.dll 
     |   
     |-- SOMEEXTENTION2 
      |-- someExtention2.dll 
      \-- itsDependency2.dll

난 반사를 사용하여 someExtention로드 할 수 있습니다 내가 폴더 같은 구조를 가지고있다. 문제는 실행 중 someExtention이 종속성을 찾을 때 발생합니다. 닷넷은 BIN 폴더를 찾습니다. 그것은 거기에서 그것을 발견하지 못한다. Appdomain 's AssemblyResolve 이벤트가 발생했습니다 ...

이 이벤트를 트래핑 중입니다. ResolveEventArgs에서로드해야하는 어셈블리의 이름을 얻습니다. 문제는 내가 RequestingAssembly를 얻지 못한다는 것입니다. ResolveEventArgs의 해당 속성은 항상 비어 있습니다. 자체 EXTN 폴더에서 직접 볼 수 있도록 요청 어셈블리가 필요합니다. 그것 없이는 모든 EXTN 폴더를 조사해야하는데, 내 경우에는 상당히 클 수 있습니다.

RequestingAssembly에는이 msdn 기사에 따라 실제 파일에 대한 경로가 포함 된 위치가 있습니다. this article 또한이 속성이 Nothing 일 수있는 상황을 사이트에 표시합니다. 나는 그곳에서 논의 된로드 컨텍스트를 이해하지 못한다. 동적으로 어셈블리를로드 할 때

어떤 도움이 감지 될 것이다 ... 내가 (지원 다시 검색 결과) 실험과 발견 것과

출처

2012-02-29 inquisitive

, 폴더 이름은 어셈블리 이름과 일치하지 않아야합니다. 나는 그때 무슨 일이 일어날 지 정확히 알지 못하지만, 로더 메커니즘 내부는 뭔가 엉망이됩니다.

그런데 LoadFrom 메서드를 사용하여 어셈블리를로드하면로드 할 때 컨텍스트에서로드됩니다. 이 컨텍스트에서 종속성 어셈블리는 먼저 응용 프로그램 기반을보고 어셈블리 자체 폴더에서 확인하여 해결됩니다. 내 경우에 이것은 의존성을 해결하는 문제를 해결합니다.

아래쪽에서로드 -가 종속성을 해결하지 못하고 AssemblyResolve 이벤트가 발생하면 요청한 어셈블리를 사용할 수 없다는 것을 발견했습니다. 이는 path-to-requesting-assembly를 결정할 수 없다는 것을 의미합니다.

LoadFile 메서드를 사용하면 load-from을 사용하는 대신 하위 폴더에서 종속성이 자동으로 해결되지 않습니다. 오히려 AssemblyResolve 이벤트가 트리거됩니다. 이 경우 ResolveEventArgs에는 요청 어셈블리 속성이 포함됩니다. 여기서 사용자 코드는 대상 경로를 쉽게 결정할 수 있습니다. 사용자 코드는 종속성을로드 할 수 있습니다.

출처

2012-04-20 11:05:16 inquisitive

네 말이 맞아. LoadFrom()은 RequestingAssembly 속성이있는 이벤트를 생성하지만 'Assembly.Load (AssemblyName.GetAssemblyName (path))'는 수행하지 않습니다. 나는 이유를 모르지만 전환해야했습니다. – ekkis

이 줄은 "동적으로 어셈블리를로드 할 때 폴더 이름이 어셈블리 이름과 일치하지 않아야합니다"라는 시간을 저에게 저장했습니다. 또한이 시나리오에서는 Resolver 이벤트에서 RequestingAssembly가 null임을 알았습니다. Microsoft는 LoadFrom()의 msdn 페이지에서 이에 대해 경고해야합니다! – Makolyte

ResolveEventArgs.RequestingAssembly가 Null입니다.

답변

관련 문제