로드 오류 닷넷 어셈블리

Question

나는 어떤 DLL myDLL1에

Assembly.loadFrom("filePath") 

를 사용하여 조립 ASSEMBLY가 런타임에 동적으로로드되는 문제를 anyalyse 것을 시도하고있다. 동일한 어셈블리가 정적으로 다른 DLL myDLL2와 동일한 솔루션에서 링크되었으며 솔루션의 두 DLL에 대한 호출 인 myExecutable이 있습니다. 솔루션이 배포 된 폴더에서 정확히 동일한 어셈블리가 발견되면 올바르게 작동합니다. 조립은, 말하자면, 파일 버전 1.0로 exaxtly 같은 닷넷 버전 1.0.1.1을 가지고 닷넷 버전 1.0.1.1 지금 파일 버전 1.0.1.7

새로운 파일 ASSEMBLY의 1.0.1.8를 발행 버전이 .1.7의 조립. 어셈블리는 강력한 이름을 가지며 다른 파일 버전의 공개 키 토큰도 다릅니다. 첫 번째 질문 : 합리적인가?

솔루션 배포 위치에 어셈블리의 새 파일 버전을 배치하면 오류가 발생합니다. NET 런타임은 myDLL1의 매니페스트에 따라 예상대로 공개 키 토큰에 대해 불만을 가지고 있기 때문에 이것이라고 추측합니다.이 추측을 확인할 수 있습니까?

Assembly Binder Log Entry (11.11.2011 @ 13:38:52) 

The operation failed. 
Bind result: hr = 0x80070002. The system cannot find the file specified. 

Assembly manager loaded from: C:\Windows\Microsoft.NET\Framework\v2.0.50727\mscorwks.dll 
Running under executable myExecutable 
--- A detailed error log follows. 

=== Pre-bind state information === 
LOG: User = xxxxx 
LOG: DisplayName = ASSEMBLY (Partial) 
LOG: Appbase = (folder the solution is deployed to) 
LOG: Initial PrivatePath = NULL 
LOG: Dynamic Base = NULL 
LOG: Cache Base = NULL 
LOG: AppName = NULL 
Calling assembly : myDLL1, Version=2.1.2.0, Culture=neutral, PublicKeyToken=..... 
=== 
LOG: Start binding of native image ASSEMBLY, Version=1.0.1.1, Culture=neutral,  PublicKeyToken=xxxxxxxx. 
LOG: IL assembly loaded from ASSEMBLY. 
WRN: No matching native image found. 
LOG: Bind to native image assembly did not succeed. Use IL image. 

I 어셈블리 파일 버전 1.0.1.8 공개 키 토큰으로 함께 제 버전 1.0.1.1에 bindingRedirect 사용하려고 다음과 같이

예시 설명하도록 이름으로 fuslogvw 출력된다 파일 버전 1.0.1.7에 해당하는 myDLL1의 매니페스트 정보에서 sn -Tp로 생성하고 ASSEMBLY에 대한 공개 키 토큰을 사용하지만 동일한 오류가 발생합니다. 리디렉션 정보를 myExecutable 구성에 추가했습니다.

그런 다음 새로운 버전의 어셈블리 인 공개 키 토큰 으로 버전 1.0.1.2로 bindingRedirect를 사용하려고했습니다. 새로운 파일 버전이로드되었지만 개정 불일치가 발생합니다.

새로운 파일 버전에 정적으로 링크 된 전체 솔루션을 교체하지 않고도이 설치에서 새 파일 버전의 어셈블리를 사용하는 방법을 알려 줄 수 있습니까? 물론 작동합니까?

TIA와 안부,

Answer 1

확인

토마스, 좀 더 많은 연구와 실험을 수행 한 후 지금은 내 질문에 나 자신에 대답 할 수있다. 여기에 내가 무엇을 발견 :

1. 닷넷 프레임 워크 어셈블리는 응용 프로그램이 정적으로 컴파일시에 링크 된에 대해 어셈블리가 있었다 같은 키로 서명되어 있지 않은 경우 응용 프로그램에 대한 어셈블리를로드 거부합니다. application.config 파일이나 machine.config 파일을 사용하여 변경 될 수는 없지만이 문서에 대한 증거는 찾을 수 없습니다. 이 문제에 대해 잠시 생각한 후에는 응용 프로그램 사용자가 개발자가 사용한 동일한 어셈블리에서 작동한다는 것을 증명하는 것처럼 합리적인 동작이라고 생각합니다.

2. 이제 정확히 1)이 올바른지 여부는 다음과 같습니다. 키가 서로 다른 버전의 어셈블리에 대해 동일하게 유지되면 바인딩 리디렉션이 이러한 버전에서 올바르게 작동합니다. 이는 machine.config 파일뿐만 아니라 application.config를 사용하여 리 바인드하는 경우에도 마찬가지입니다.

그러나 이러한 동일한 구성 파일은 어셈블리가 다른 키로 서명되는 즉시 작동을 멈 춥니 다. 이 경우 불쾌한 점은 fuslogvw에서 생성 된 로그가 다른 이유로 인해 바인딩에 실패했음을 알리는 것입니다 (예 : 부 버전 번호가 일치하지 않음). 잘못된 공개 키 토큰에 대해 불평하지 않습니다.

다른 불쾌한 점은 설정 파일의 XML 태그에 공개 키 토큰을 속성으로 추가 할 수 있다는 것입니다. 처음에는 잘못된 길로 나를 안내합니다. 공개 키가 구성 파일에 추가되거나 추가되어야하는 이유는 모르겠지만 .NET은 어셈블리 및 응용 프로그램 바이너리에서이 정보를 검색 할 수 있습니다.

1)에서 설명한 동작이 .Net Framework의 security.config 파일을 사용하여 변경 될 수 있는지 여부를 알 수 없습니다. (비록 그것이 그렇게 변경 될지라도 이것은 아마도 내 PC에서 생성하고 싶지 않은 보안 위험을 초래할 것이다).