.Net 잘못된 참조 어셈블리 버전 선택

방금 기존 프로젝트를 새로운 컴퓨터에 복사하여 개발을 시작했으며 참조 된 어셈블리 중 하나 (텔레 릭 DLL)의 버전에 문제가 발생했습니다.

프로젝트는 원래 이전 버전의 어셈블리를 참조했습니다 (v1.0.0.0이라고 함). 새 컴퓨터에는 최신 버전의 어셈블리가 설치되어 있으므로 업데이트한다고 생각했습니다 (새 버전 v2.0.0.0이라고 함).

이제 문제가 있습니다 : 이전 v1.0.0.0 dll을 프로젝트 폴더에 복사하고 참조로 추가하면 웹 사이트가 문제없이 시작됩니다. 해당 참조를 삭제하고 시스템에서 이전 DLL을 삭제하고 새 버전 (v2.0.0.0)을 추가하면 페이지에 다음 예외가 표시됩니다.

파일 또는 어셈블리 'XXXXXX, Version = 1.0.0.0, Culture = neutral, PublicKeyToken = 121fae78165ba3d4'또는 해당 종속성 중 하나를로드 할 수 없습니다. 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다. (HRESULT 예외 : 0x80131040)

분명히 코드가 오래된 버전을 찾고 있으며 찾을 수 없습니다. 그런데 왜?

해당 버전 번호에 대한 솔루션 폴더를 찾은 후 단일 참조를 찾을 수 없습니다. .csproj 파일의 텍스트를 두 번 확인하고 버전에 최신 버전이 올바르게 표시되고 HintPath가 새 DLL의 경로를 올바르게 표시한다는 것을 알았습니다. 또한 시스템에 이전 DLL을 설치하지 않았기 때문에 GAC에 표시되지 않습니다 (v2.0.0.0은 예상대로).

그런 다음 퓨전 로그 뷰어가 이전 버전을 찾는 이유를 알아 내려고 시도했지만 운이 없었습니다.

Assembly Load Trace: The following information can be helpful to determine why the assembly 'XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4' could not be loaded.


=== Pre-bind state information ===
LOG: User = MyComp\me
LOG: DisplayName = XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
 (Fully-specified)
LOG: Appbase = file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/
LOG: Initial PrivatePath = d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\bin
Calling assembly : WebApp, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null.
===
LOG: This bind starts in default load context.
LOG: Using application configuration file: d:\My Documents\Visual Studio 2010\Projects\CoolProj\WebApp\web.config
LOG: Using host configuration file: 
LOG: Using machine configuration file from C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319\config\machine.config.
LOG: Post-policy reference: XXXXXX, Version=1.0.0.0, Culture=neutral, PublicKeyToken=121fae78165ba3d4
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX.DLL.
LOG: Attempting download of new URL file:///C:/WINDOWS/Microsoft.NET/Framework/v4.0.30319/Temporary ASP.NET Files/root/90233b18/10d54998/XXXXXX/XXXXXX.DLL.
LOG: Attempting download of new URL file:///d:/My Documents/Visual Studio 2010/Projects/CoolProj/WebApp/bin/XXXXXX.DLL.
WRN: Comparing the assembly name resulted in the mismatch: Major Version
ERR: Failed to complete setup of assembly (hr = 0x80131040). Probing terminated.

그것은 오래된 어셈블리를 찾는 것으로 시작한다고 말합니다. 나는 온라인으로 해결책을 찾으려고 노력했지만이 비슷한 SO 질문 을 보았지만 내 문제와 정확히 반대 인 것 같습니다. 해당 질문자의 프로그램이 참조 된 DLL 대신 잘못된 DLL을 찾았습니다. 내 문제는 프로그램이 신비하게 잘못된 DLL을 찾고 bin 폴더와 GAC에서 로컬에서 올바른 DLL을 찾을 수 없으면 찾을 수 없다는 것입니다.

이전 버전을 찾는 이유는 무엇입니까? 이 나쁜 참조를 찾기 위해 다른 곳을 검색 할 수 있습니까?

내 생각에는 사용중인 다른 어셈블리가 이전 dll을 참조하는 것입니다. 사용중인 다른 모든 프로젝트 참조에 익숙하고 Telerik dll에 대한 참조가 있습니까?

이와 같이 web.config 파일에 바인딩 리디렉션을 넣을 수 있습니까?

<dependentAssembly>
 <assemblyIdentity name="Telerik" publicKeyToken="121fae78165ba3d4"/>
 <bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.0.0"/>
</dependentAssembly>

나는 Chris Conway와 함께 있습니다. 문제는 프로젝트에서 Telerik 어셈블리 중 하나를 참조하는 Telerik 어셈블리 중 하나를 참조한다는 것입니다.

첫 번째 : 모든 공급 업체 (예 : telerik) 어셈블리를 GAC에 설치하지 않습니다. Telerik의 자료는 어쨌든 두 개의 어셈블리 (telerik.web.design 및 telerik.web.ui)로 컴파일됩니다. 응용 프로그램과 함께 배포하십시오.

둘째, .csj와 같은 각 .proj 파일에는 <reference include..> Telerik.Web.UI 파일을 가리키는 파일이 있습니다. 일반적으로 버전 번호가 포함됩니다. bin 폴더에 넣은 어셈블리가 해당 버전과 일치하는지 확인하십시오.

셋째, 모든 프로젝트가 최신 어셈블리를 사용하는지 확인하십시오. 또한 GAC 대신 로컬 경로에서 어셈블리를 가져와야합니다. (정말 GAC가 마음에 들지 않습니다. 제가 진행 한 일부 프로젝트에서 문제가 발생하지 않았습니다.) 일반적으로 모든 프로젝트에서 외부 어셈블리 참조에 사용하는 "어셈블리"폴더가 있습니다.

넷째, Visual Studio는 웹 사이트 프로젝트가로드 될 때마다 자동으로 gac를 검색하고 gac에서 무언가를 찾으면 어셈블리 위치를 다시 대상으로합니다. 웹 응용 프로그램 프로젝트 에서이 작업을 수행했는지 기억이 나지 않지만 오랫동안 문제가 없었습니다. 배포 중에 비슷한 문제가 발생할 수 있습니다.

다섯째, web.config에서 어셈블리의 버전 번호를 리 바인드 할 수 있습니다. 이 runtime/assemblybinding섹션 에서는 다음과 같은 것을 사용할 수 있습니다. 2008 년에 배포 된 모든 telerik 어셈블리를 매우 구체적인 버전으로 지정합니다.

  <dependentAssembly>
    <assemblyIdentity name="Telerik.Web.UI" publicKeyToken="121fae78165ba3d4" />
    <bindingRedirect oldVersion="2008.0.0.0-2020.0.0.0" newVersion="2010.02.0713.35" />
  </dependentAssembly>

나는 대부분의 답변을 시도했지만 여전히 작동하지 못했습니다. 이것은 나를 위해 일했다 :

참조 -> 속성 -> 'Specific Version'을 false로 변경하십시오.

도움이 되었기를 바랍니다.

시험:

• 임시 프로젝트 파일 정리
• 빌드 및 obj 파일 정리
• 에 설치된 이전 버전 청소 C:\Users\USERNAME\.nuget\packages\

그것은 나를 위해 일했다.

1. C : \ WINDOWS \ Microsoft.NET \ Framework \ v2.0.50727 \ CONFIG로 이동하십시오.
2. machine.config 파일 찾기
3. 메모장에서 열기
4. 충돌 dll을 찾으십시오
5. 이것을 제거하고 저장하십시오.

컴파일 어셈블리

addassembly = dllName, Version = 1.0.0000.0000 Culture = neutral, PublicKeyToken = "QWEWQERWETERY"

어셈블리 컴파일

나를 위해 작동합니다.

왜 그런지에 대한 명확한 대답은 아니지만, 우리는이 문제를 겪었습니다. 여기에 우리의 상황과 해결 된 것이 있습니다.

개발자 1 :

솔루션에는 NuGet 패키지를 참조하는 프로젝트 A와 프로젝트 A를 참조하는 MVC 프로젝트가 포함되어 있습니다. NuGet 패키지 복원을 활성화 한 다음 NuGet 패키지를 업데이트했습니다. NuGet 라이브러리를 찾을 수 없다는 런타임 오류가 발생했습니다. 그러나 오류는 이전의 업데이트되지 않은 버전을 찾는 것입니다. 해결책 (그리고 이것은 우스운 일입니다) : 프로젝트 A를 호출하는 MVC 프로젝트의 첫 번째 코드 줄에 중단 점을 설정하십시오. F11로 시작하십시오. 해결-다시는 문제가 없었습니다.

개발자 2 :

동일한 솔루션 및 프로젝트이지만 솔루션의 마술 세트 중단 점 및 단계가 작동하지 않습니다. 이 Nuget 패키지에 대한 버전 리디렉션 또는 기타 잘못된 참조가 있는지 찾아보고 패키지를 제거했다가 다시 설치했습니다. 마지막으로 프로젝트 A로 이름을 바꾸고 MVC 프로젝트를 수정했습니다. 원래 이름으로 다시 이름을 바꾸면 고정 된 상태로 유지됩니다.

나는 그것이 왜 효과가 있었는지에 대한 설명이 없지만 심각한 루치에서 벗어날 수있었습니다.

해당 솔루션에 다른 프로젝트가 있습니까? (다른 프로젝트가 이전 버전을 참조하고있을 수 있습니다) 일반적으로 VS에서는 dll 종속성이 솔루션의 모든 프로젝트에 걸쳐 있습니다.

내 문제는 이전 어셈블리가 웹 응용 프로그램의 _bin_deployableAssemblies 폴더에 있다는 것입니다. 이는 이전 어셈블리가 프로젝트를 빌드 할 때 GAC 어셈블리를 덮어 쓰는 것을 의미했습니다.

경우에 따라 3 시간 동안 다른 사람을 구할 수 있습니다. 제 경우는 조금 달랐습니다. 내 코드는 DevExpress v11.1 v11.1.4.0을 사용했습니다. 내 코드에서 모두 올바르게 참조했습니다. 그러나 .net 메모리 프로파일 러는 GAC에 DevExpress v11.1 v11.1.12.0을 설치했습니다. 사실 그것은 내가 참조한 구성 요소가 아니라 내부적으로 참조한 구성 요소가 아니 었습니다. 내가 시도하는 것처럼 GAC는 항상 먼저 확인됩니다. 컴파일하고 잘 실행했지만 승리 양식 디자이너를 볼 수 없었고 스택 추적은 전혀 도움이되지 않았습니다. 마지막으로 .net 메모리 프로파일 러를 제거하고 모두 복원되었습니다.

비슷한 문제가 있었고 bin 및 obj 폴더에서 모든 것을 삭제하고 문제를 극복하기 위해 다시 빌드해야했습니다. 도움이 되었기를 바랍니다.

Visual Studio 환경 (ASP.NET 개발 서버)에서 응용 프로그램을 테스트 및 / 또는 디버깅 할 때이 문제가 발생하면 개발 웹 사이트 폴더에서 모든 임시 파일을 삭제해야합니다. 해당 폴더의 위치를 ​​알려면 Windows 트레이 아이콘에서 ASP.NET Development Server 아이콘을 찾으십시오 (ASP.NET Development Server-Port ####와 같은 제목이 있어야 함). 아이콘을 마우스 오른쪽 단추로 클릭하고 표시를 선택하십시오. 세부; th, 실제 경로 필드는 임시 폴더가 무엇인지 알려주고, 문제를 해결하기 위해 모든 항목을 삭제해야합니다. 웹 사이트를 빌드하고 다시 실행하면 문제가 해결되어야합니다 (다시 개발 환경에서 해결됨).

다른 버전의 Newtonsoft.json을 참조하는 다른 어셈블리와 동일한 문제가있었습니다. 나를 위해 일한 솔루션은 Nuget Package Manager Console에서 업데이트 패키지를 실행 중이었습니다.

이 오류는 다소 오해의 소지가있었습니다. x64 아키텍처를 지정해야하는 일부 DLL을로드했습니다. 에서 .csproj파일 :

<PropertyGroup Condition="'$(Configuration)|$(Platform)' == 'Release-ABC|AnyCPU'">
    <OutputPath>bin\Release-ABC</OutputPath>
    <PlatformTarget>x64</PlatformTarget>
</PropertyGroup>

누락으로 PlatformTarget인해이 오류가 발생했습니다.

나는 얻고 있었다 :

파일 또는 어셈블리 'XXX-new-3.3.0.0'또는 해당 종속성 중 하나를로드 할 수 없습니다. 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다. (HRESULT 예외 : 0x80131040)

나는에서 어셈블리의 이름을 변경 때문이었다 XXX.dll에 XXX-new-3.3.0.0.dll. 이름을 원래대로 되 돌리면 오류가 수정되었습니다.

오래된 dll을 제거하려면 컴퓨터를 지우는 것과 거의 같습니다. 이미 위의 모든 것을 시도한 다음 컴퓨터에있는 .DLL 파일의 모든 인스턴스를 삭제하고 응용 프로그램에서 모든 참조를 제거하는 추가 단계를 수행했습니다. 그러나 여전히 잘 컴파일되고 실행될 때 dll 함수를 잘 참조합니다. 그것이 네트워크 드라이브에서 그것을 참조하고 있는지 궁금해지기 시작했습니다.

동일한 DLL의 다른 버전을 참조하는 두 버전의 응용 프로그램 간을 전환 할 때 동일한 메시지가 나타납니다. 다른 폴더에서 테스트했지만 실수로 최신 버전을 이전 버전으로 복사했습니다.

따라서 가장 먼저 확인해야 할 것은 응용 프로그램 폴더에있는 참조 된 DLL의 버전입니다. 만일을 위해서.

어쩌면 이것은 도움이 될 수도 있고 아닐 수도 있습니다. 디버그 및 릴리스 버전을 정리 한 다음 OBJ 폴더의 이름을 변경했습니다. 이것은 마침내 나를 아프게했다. 이전 단계는 기본적으로 프로젝트에서 참조를 제거하고 프로젝트 속성에서 다시 참조를 추가했습니다.

My Visual Studio 2015에서 문제가되는 Visual Studio 프로젝트의 참조 경로 목록이 비어 있는지 확인했습니다.

이것이 나를 위해 일한 것입니다.

Microsoft.IdentityModel.Clients.ActiveDirectory클래스 라이브러리 프로젝트에서 버전 3.19를 사용하고 있었지만 실제 ASP.NET 웹 응용 프로그램 프로젝트에는 버전 2.22 만 설치되었습니다. 웹 앱 프로젝트에서 3.19로 업그레이드하면 오류가 발생했습니다.

제 경우에는 3 개의 프로젝트, 1 개의 메인 프로젝트 및 2 개의 서브 프로젝트가 메인 프로젝트에 의해 참조되었습니다. 그래서 나는 서브 프로젝트를 제외하고 메인 프로젝트를 업데이트했습니다. 그것이 갈등이 있었던 곳입니다. 모든 프로젝트를 업데이트 한 후 모든 것이 잘 작동했습니다.

VS2017에서는 위의 모든 솔루션을 시도했지만 아무것도 작동하지 않습니다. 버전 관리를 위해 Azure devops를 사용하고 있습니다.

1. 팀 탐색기에서> 소스 제어 탐색기

2. 오랫동안 견과류를 운전하는 프로젝트를 선택하십시오.

3. 지점 또는 솔루션을 마우스 오른쪽 단추로 클릭> 고급> 특정 버전 가져 오기

4. 그런 다음 스크린 샷에 따라 파일 덮어 쓰기 확인란을 선택했는지 확인하십시오

필자의 경우 실수로 nuget에서 잘못된 버전의 Telerik 패키지를 선택한 다음 잘못된 버전으로 참조한 모든 패키지를 대체했습니다. 그런 다음 모든 버전을 올바른 버전으로 바꾼 후에도 여전히 잘못된 버전을 찾고 있도록 잘못된 버전으로 바인딩 리디렉션을 삽입했습니다.