동일한 솔루션에서 서로 다른 2 개의 log4net 버전 참조

log4net 1.2.10.0을 참조하는 NHibernate 2.1.2.400을 사용하고 있습니다. 같은 프로젝트에서 나는 또한 단순한 회계 SDK를 사용하는데, 슬프게도 여전히 log4net 1.2.9.0을 사용하고 있습니다.

따라서 log4net 1.2.10.0을 참조하면 NHibernate가 작동하도록 할 수 있지만 simplySDK가 작동하지 않습니다. 그 반대...

대부분의 문제는 log4net이 어셈블리 키를 변경했다는 사실에서 비롯된 것 같습니다. 성공하지 않고 바인딩 리디렉션을 사용해 보았습니다. 2 개의 DLL에 동일한 키가 없습니다.

나는 NHibernate를 다시 컴파일하여 log4net 1.2.9.0을 사용하는 것을 고려하고 있지만 잘못된 일처럼 보이며 Simply Accounting이 언제든지 log4net 1.2.10.0을 사용하도록 SDK를 업데이트하지 않을 것이라고 생각합니다.

이를 처리하는 가장 좋은 방법은 무엇입니까? 전혀 해결할 수 있습니까?

— Joel Gauvreau
소스

stackoverflow.com/questions/1744543/에 매우 유사한 질문이 있습니다 … 저는 재 컴파일에 의지했습니다. 나는 이것이 dll-hell v2.0의 출현이라고 생각합니다.

— Sandor Drieënhuizen

귀하의 질문을 확인하는 동안 내 문제를 해결 한 stackoverflow.com/questions/2460542/2461746#2461746 을 찾았습니다 .

— Joel Gauvreau

큰! 나는 CLR을 다른 위치에서 보이게 만드는 것에 대해 궁금해했고 href속성이 트릭을 수행하는 것 같습니다. 지적 해 주셔서 감사합니다!

— Sandor Drieënhuizen

답변:

149

비슷한 질문에 대한 답변을 사용하여 해결책을 찾았습니다.

프로젝트에 log4net의 각 버전에 대해 하나씩 2 개의 폴더를 만듭니다. 솔루션에 파일을 추가하여 각 log4net.dll을 해당 폴더에 배치합니다 (참조 추가가 아님). 출력 디렉터리로 복사 속성을 항상 복사하도록 설정하여 빌드 할 때 출력 폴더에 자동으로 복사되도록 할 수 있습니다.

그런 다음 다음과 같이 추가하여 app.config 파일을 수정합니다.

<configuration>
  <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <dependentAssembly>
        <assemblyIdentity name="log4net" publicKeyToken="681549d62126b7b8" />
        <codeBase version="1.2.9.0" href="log4netv1.2.9.0\log4net.dll" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821" />
        <codeBase version="1.2.10.0" href="log4netv1.2.10.0\log4net.dll" />
      </dependentAssembly>
      <dependentAssembly>
        <assemblyIdentity name="log4net" publicKeyToken="669e0ddf0bb1aa2a" />
        <codeBase version="1.2.11.0" href="log4net.dll" />
      </dependentAssembly>
    </assemblyBinding>
  </runtime>
</configuration>

sn -T [assemblyName]을 사용하여 어셈블리의 공개 키 토큰을 얻을 수 있습니다.

— Joel Gauvreau
소스

이것은 나에게도 효과가있는 것 같습니다. 충돌이 발생한 프로젝트에 대한 참조 목록에서 log4net을 제거했습니다. 또한 log4net.dll이 내 bin 폴더에 없기 때문에 내 href 경로는 ".. \ .. \ .. \ .. \ Lib \ NHibernate-2.0.1.GA \ log4net.dll"처럼 보였습니다. 빌드 시스템을 사용하는 모든 개발자의 컴퓨터에서 log4net이있는 상대 경로입니다.

— jyoungdev 2010 년

나는 이것이 확실하지 않다 : log4net이 참조되지 않는 경우 어떻게 컴파일 오류가 발생하지 않습니까?

— guidupuy

이것은 대단합니다. 간단한 바인딩 리디렉션이 API 변경으로 인해 문제가 발생하는 다른 경우를 수정합니다!

— Rhys Bevilaqua 2014

@guidupy 코드에서 사용하는 log4net을 참조 할 수 있지만 속성에서 copyLocal을 해제합니다.

— Jeff Martin

미래의 독자를 위해 (다른 답변에서 찾은 힌트이지만 여기에 게시하는 것이 현명합니다) ... 웹 응용 프로그램 (asp.net)의 경우 참조가 조정되었습니다. <codeBase version = "1.0.0.0"href = "bin \ folder \ namedll.dll "/>

— granadaCoder

레지스트리에 제외를 추가 할 수 있습니다. 다음 키를 추가하십시오.

HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,681549d62126b7b8
HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,1b44e1d426115821
HKEY_LOCAL_MACHINE\Software\Microsoft\StrongName\Verification\log4net,669e0ddf0bb1aa2a

이렇게하면 .net 런타임이 나열된 어셈블리에 대한 유효성 검사를 건너 뜁니다. 이론적으로 이것은 보안 문제이지만 어쨌든 비공개 키가 공개되어 있기 때문에 거의 영향을 미치지 않습니다.

— Joep Beusenberg
소스

말씀 하셨듯이 이것은 보안 문제입니다. 또한 이것은 소프트웨어를 실행하는 모든 워크 스테이션에서 이러한 변경을 수행해야 함을 의미합니다. 복잡한 엔터프라이즈 네트워크에서 이러한 종류의 것들이 합쳐져 엄청난 혼란이 발생합니다. 차라리 가능한 한 피하고 싶습니다. 다른 솔루션은 독립적이고 휴대 가능합니다.

— Joel Gauvreau

내가 말했듯이 개인 키는 어쨌든 공개적으로 사용 가능하기 때문에 실제 보안 문제는 전혀 없습니다. 특히 엔터프라이즈 네트워크에서는 사용중인 모든 LOB 응용 프로그램에 대해이를 구성하는 것보다 단일 그룹 정책 개체를 구성하는 것이 더 쉽습니다. 도메인 수준에서 한 번 구성 할 수 있으며 다시 생각할 필요가 없습니다.

— Joep Beusenberg 2016

바인딩 리디렉션이 작동하지 않고 단순히 회계 SDK가 폐쇄 된 소스 인 경우 가능한 솔루션은 NHibernate를 다시 컴파일하여 log4net 1.2.9.0을 사용하는 것입니다.

— 디에고 미 젤숀
소스

그래도 효과가 있지만 nhibernate의 특수 버전을 빌드해야하는 것은 라인을 지원하기가 더 어려울 것입니다. 감사합니다.

— Joel Gauvreau