MMC 기반 응용 프로그램의 스냅인 인 C++ 코드가 있습니다. 이 스냅인은 COM 래퍼 (AssemblyA)를 통해 .net 2.0 dll을 사용합니다. AssemblyA는 MMC 세션을 시작하는 앱과 동일한 디렉토리에 있습니다. AssemblyA는 다른 제어 할 수없는 이유로 AssemblyA와 같은 디렉토리에 살 수없는 몇 가지 .net dll (OtherAssemblies)을 사용합니다. 또한 일부 구성 요소를 AssemblyB에서 동적으로로드 할 수 있으며 세 번째 디렉토리에서 이러한 구성 요소를 검색합니다. AssemblyB 참조 AssemblyA의 동적 구성 요소는 기본 클래스를 확장 할 때 AssemblyA를 참조합니다.런타임에서 내 어셈블리 종속성을 자동으로 해결하지 않는 이유는 무엇입니까?
내 문제는 동적 구성 요소를로드하려고 할 때 AssemblyA에 대한 종속성을 해결할 수없고 내 AssemblyResolve 처리기가 해고 당했다는 것입니다 (이는 OtherAssemblies을 해결하는 데 사용됨). AssemblyResolve 핸들러에서 Assembly.GetExecutingAssembly()을 쿼리하면 어셈블리가 해결하려고하는 어셈블리입니다.
이 동작은 .NET 런타임에서로드 된 어셈블리의 종속성을 먼저 확인한 다음 응용 프로그램 디렉터리에서로드 할 어셈블리의 로컬을 검색 할 것으로 예상했기 때문에 조금 이상하게 보입니다. 이 중 첫 번째와 세 번째에는로드하려고하는 어셈블리가 있어야합니다.
현재 응용 프로그램 디렉토리와 같이 작동하도록 다른 위치의 종속성을 검색하도록 AssemblyResolve 메소드를 수정했지만 도움이 필요하다면 실제로이 작업을 수행하고 싶지는 않습니다.
이 동작이 필요합니까? MMC 응용 프로그램이거나 C++에서 호출 된 COM에서 시작된다는 사실 때문입니까? 내가 둔탁한가?
가상 도움말 : http://stackoverflow.com/questions/2188024/c-calling-managed-com-object-cant-find-dependent-assemblies/2188116#2188116 – Ruddy
감사합니다. 내 확장 프로그램은 기존 플러그인의 스냅인입니다. 확실하지 않은 경우 관리되는 네임 스페이스를 사용하는 기존 C++ 플러그인에서 작동하도록 다시 작성할 수 있습니다. 특히 이미 작동합니다. GAC는 실제로 옵션이 아니므로 내 기존 솔루션과 같아 보이지만 잘못되었다고 생각됩니다. –