찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다


751

C # Windows Forms 응용 프로그램 (Visual Studio 2005)에서 일부 단위 테스트를 실행하려고하는데 다음 오류가 발생합니다.

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

x.Foo.FooGO ()에서

Foo.cs : x 선 123의 x.Foo.Foo2 (String groupName_)에서

FooTests.cs의 x.Foo.UnitTests.FooTests.TestFoo ()에서 : line 98 **

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

나는 나의 참고 문헌을보고, 나는 단지 Utility version 1.2.0.203다른쪽에 대해서만 언급한다 .

이 DLL 파일의 이전 버전을 참조하려고하는 것이 무엇인지 어떻게 알 수 있습니까?

게다가, 나는이 오래된 어셈블리를 내 하드 드라이브에 가지고 있다고 생각하지 않습니다. 이 오래된 버전의 어셈블리를 검색하는 도구가 있습니까?


필자의 경우 이것은 동일한 DLL을 다른 버전으로로드하는 두 개의 프로젝트가 있었기 때문에 발생했습니다. (이 사람을 도움이되기를 바랍니다!)
miguelmpn

답변:


461

.NET 어셈블리 로더 :

  • 1.2.0.203을 찾을 수 없습니다
  • 하지만 1.2.0.200을 찾았습니다

이 어셈블리는 요청한 것과 일치하지 않으므로이 오류가 발생합니다.

간단히 말하면 참조 된 어셈블리를 찾을 수 없습니다. GAC 또는 응용 프로그램 경로에 배치하여 올바른 조립품을 찾을 수 있는지 확인하십시오. https://docs.microsoft.com/archive/blogs/junfeng/the-located-assemblys-manifest-definition-with-name-xxx-dll-does-not-match-the-assembly-reference 도 참조 하십시오 .


19
그러나 프로젝트의 참조를 볼 때 1.2.0.203을 가리키고 있습니다. 아무것도 더 이상 1.2.0.200을 가리키는 것 같지 않습니다
leora

128
정확히 -1.2.0.203을 찾고 있지만 1.2.0.200 을 찾았 습니다. 해당 파일의 위치를 ​​찾아 올바른 버전으로 바꾸십시오.
Jon Skeet

18
여기 비슷한 질문을하고 작업 솔루션을 가지고 : stackoverflow.com/questions/4187907/...
마이클 라 Voie

13
참조 버전을
확인한

4
이 메시지는 매번 혼동됩니다. 거꾸로 쓰여진 것 같습니다. 찾은 버전이 아니라로드 요청한 버전에 대해 불만을 표시 할 것으로 예상됩니다. 나는 그것이 잘못되는 유일한 사람이 아니라 다행입니다.
그렉 우즈

91

이 문제를 해결하기 위해 몇 가지 작업을 수행 할 수 있습니다. 먼저 Windows 파일 검색을 사용하여 하드 드라이브에서 어셈블리 (.dll)를 검색하십시오. 결과 목록이 있으면보기-> 세부 사항 선택 ...을 수행 한 다음 "파일 버전"을 확인하십시오. 결과 목록에 버전 번호가 표시되므로 이전 버전의 출처를 확인할 수 있습니다.

또한 Lars가 말했듯이 GAC에서 어떤 버전이 있는지 확인하십시오. 이 Microsoft 기사에 따르면 GAC에서 찾은 어셈블리는 빌드 중에 로컬로 복사되지 않으므로 모두 다시 빌드하기 전에 이전 버전을 제거해야 할 수 있습니다. ( 이를 위해 배치 파일을 만드는 방법에 대한 참고 사항은 이 질문에 대한 내 대답을 참조하십시오 )

이전 버전의 출처를 여전히 파악할 수없는 경우 Visual Studio와 함께 제공되는 fuslogvw.exe 응용 프로그램을 사용하여 바인딩 실패에 대한 자세한 정보를 얻을 수 있습니다. Microsoft는이 도구에 대한 정보를 여기에 있습니다 . HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog레지스트리 키를 1 로 설정하여 로깅을 활성화해야합니다 .


19
파일 버전이 어셈블리 ID의 일부가 아님을 잊지 마십시오. 어셈블리 버전은 파일 버전과 동일 할 필요는 없습니다!
Lars Truijens

서비스에 fuslogvw를 사용하는 경우 blogs.msdn.com/b/junfeng/archive/2004/02/14/72912.aspx
Nick

파일 이름을 검색하면 문제가 해결되었습니다. Temporary ASP.Net 폴더에 dll의 이전 버전이 있었고 InstallShield가 최신 버전 대신 사용했습니다! 깨끗한 솔루션, 재 구축, PC 재시작은 아무 것도하지 않았습니다. 로컬에서 잘 작동하고 배포 될 때마다 폭발했습니다.
JumpingJezza

빌드 직후, 내 사이트는 정상적으로 작동하지만 잠시 후이 문제가 발생합니다.
Shavais

대신 어셈블리 버전을 말하도록이 답변을 편집했습니다.
Worthy7

60

방금이 문제에 부딪 쳤고 다른 사람들이 겪었던 것과 다른 문제가 있음을 알았습니다.

내 주요 프로젝트가 참조하는 두 개의 DLL, CompanyClasses.dll과 CompanyControls.dll이 있습니다. 런타임 오류가 발생했습니다.

파일 또는 어셈블리 'CompanyClasses, Version = 1.4.1.0, Culture = neutral, PublicKeyToken = 045746ba8544160c'또는 해당 종속성 중 하나를로드 할 수 없습니다. 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다

문제는 버전 번호가 1.4.1 인 시스템에 CompanyClasses.dll 파일이 없다는 것입니다. GAC에는 없으며 앱 폴더에는 없습니다. 하드 드라이브 전체를 검색했습니다. 내가 가진 모든 CompanyClasses.dll 파일은 1.4.2입니다.

실제 문제는 CompanyControls.dll이 CompanyClasses.dll의 버전 1.4.1을 참조한다는 것입니다. 방금 CompanyControls.dll을 다시 컴파일하고 (CompanyClasses.dll 1.4.2를 참조한 후)이 오류가 사라졌습니다.


2
+1 DLL 중 하나가 이전 버전의 Caliburn Micro를 참조 할 때 비슷한 문제가 발생했습니다.
Jason Massey

나도, 당신의 경험이 내가 어디를 봐야하는지 촉발 시켰고 문제가 해결되었습니다.
Esen

또 다른 옵션은 열 것 CompanyControls마우스 오른쪽 버튼을 클릭하면, 프로젝트를 CompanyClasses.dll참조 -> 속성 ->SpecificVersion = false
BlueRaja - 대니 Pflughoeft

이것은 종종 xamarin 애플리케이션의 경우입니다. xamarin.droid 프로젝트와 다른 xamarin.forms 프로젝트가있었습니다. 방금 당신의 게시물을보고 그것을 인식했습니다.
batmaci

CompanyClasses.dll에 서명하면 SpecificVersion = false혼자서는 잘라낼 수 없습니다. 당신이 필요합니다 bindingredirect.
Denise Skidmore

53

다음은 모든 어셈블리 버전을 버전 3.1.0.0으로 리디렉션합니다. App.config에서 항상이 참조를 업데이트하는 스크립트가 있으므로이 문제를 다시 처리 할 필요가 없습니다.

리플렉션을 통해 어셈블리 publicKeyToken을 가져 와서 .dll 파일 자체에서이 블록을 생성 할 수 있습니다.

<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
 <dependentAssembly>
    <assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-65535.65535.65535.65535" newVersion="3.1.0.0" />
  </dependentAssembly>
</assemblyBinding>

XML 네임 스페이스 특성 (xmlns)이 없으면 작동하지 않습니다.


1
이것은 나를 위해 일했습니다. 'newVersion = 3.3.3'을 'newVersion = 3.1.0'으로 변경
jward01

당신이 그것을 피할 수 있다면 리바운드 경로를 내려 가지 않는 것이 가장 좋습니다. 그 벌레가 당신을 물었을 때 열심히 물릴 것입니다.
BanksySan

1
내 문제는 리디렉션이 존재하지 않는 어셈블리를 가리키고 있다는 사실이었습니다 .App.Config는 내가 설치 한 최신 NuGet 패키지의 어셈블리 정보를 보유했습니다. 나중에이 패키지를 다운 그레이드 할 때 정리하지 않았습니다. 이것은 4.7.2 프레임 워크 단위 테스트 프로젝트에 의해 영향을받는 .NET 표준 클래스 라이브러리였습니다. 유닛 테스트 프로젝트의 이슈는 런타임에 발표되었습니다.
D-Sect

@ D-Sect가 맞습니다. 소스 컨트롤이 web.config에 NuGets를 사용했기 때문에 변경 사항이 있음을 나타내는 경우 해당 bindingRedirects를 백업하는 것이 좋습니다. 다운 그레이드 NuGets 바인딩 리디렉션 정리하지 않습니다
bkwdesign

45

Visual Studio를 사용하는 경우 "clean solution"을 시도한 다음 프로젝트를 다시 빌드하십시오.


14
이것은 일반적으로 나를위한 해결책입니다. 종종 삭제 bin하고 obj수행하십시오. 기본적으로, 내가 참조했던 것은 여전히 ​​동일한 요구 사항을 충족시키기 위해 노력하고 있습니다. 예를 들어, 이전 버전은 내가 직접 참조한 것이고 새 버전은 NuGet에 있습니다.
David Betz

TFS에서 가져온 후 여러 DLL에 대해이 문제가 발생했습니다. 이 솔루션은 나를 위해 고쳤습니다.
Milo

3
나를 위해 일했다. bin amd obj 폴더를 삭제하고 문제를 해결했습니다.
user1619480

고맙습니다, 저에게도 bin 폴더를 삭제했습니다.
쿠키 개

나를 위해 bin폴더 를 삭제하기에 충분했습니다 . 놀랍게도, 나는 깨끗한 솔루션을 시도했지만 성공하지 않고 솔루션다시 빌드했습니다 . 때때로 조금 이상합니다.
Lion

36

다른 답변은 저에게 효과적이지 않습니다. 버전에 신경 쓰지 않고 앱을 실행하려면 참조를 마우스 오른쪽 버튼으로 클릭하고 '특정 버전'을 false로 설정하십시오 ... 이것은 저에게 효과적이었습니다. 여기에 이미지 설명을 입력하십시오


8
이 설정은 컴파일 타임 에만 적용됩니다 . 컴파일 된 후에는 컴파일 한 것과 동일한 어셈블리 버전이 필요합니다. 참조 stackoverflow.com/questions/24022134/...
라스 Truijens

22

방금이 문제를 겪었고 문제는 내 응용 프로그램 디버그 디렉토리에 .dll의 오래된 사본이 있다는 것입니다. GAC 대신 확인하여 확인할 수도 있습니다.


이 문제로 인해 백업을 유지하는 다른 서버로 마이그레이션했습니다. 백업 사본을 삭제 한 후 작업했습니다. 감사합니다 :)
Jtuck

22

나는 지금 모두의 마음을 날려 버릴 것입니다. . .

<assemblyBinding>.config 파일에서 모든 참조를 삭제 한 다음 NuGet Package Manager 콘솔에서이 명령을 실행하십시오.

Get-Project -All | Add-BindingRedirect

나를 위해 일했습니다. 감사합니다
Oleh Udovytskyi

당신은 내 시간을 구했습니다 👌👌
Abdu Imam

4
이것은 패키지 관리 형식이 packages.config 인 경우에만 작동합니다. 만약 여러분이 packages.config없이 2017 csproj를 사용한다면, 그것은 작동하지 않습니다 :(
ManiVI

1
마음 공식적으로 날려
BGilman

그것은 멋진 작은 트릭입니다
hexagod

21

내 응용 프로그램의 블랙 박스 부분이 이전 버전의 라이브러리를 참조하고 있음을 깨닫기 위해 NuGet 패키지를 추가했습니다.

패키지를 제거하고 이전 버전의 정적 DLL 파일을 참조했지만 web.config 파일은 다음에서 업데이트되지 않았습니다.

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.5.0.0" newVersion="6.0.0.0" />
</dependentAssembly>

패키지를 제거 할 때 되돌려 놓은 내용으로 :

<dependentAssembly>
    <assemblyIdentity name="Newtonsoft.Json" publicKeyToken="30ad4fe6b2a6aeed" />
    <bindingRedirect oldVersion="0.0.0.0-4.0.0.0" newVersion="4.5.0.0" />
</dependentAssembly>

적어도 NuGet을 사용할 때 Entity Framework 모듈의 경우 솔루션을 마우스 오른쪽 버튼으로 클릭하고 솔루션의 NuGet 패키지 관리로 이동 한 다음 설치된 패키지> 모두로 이동하여 해당 모듈을 선택하고 관리를 선택하십시오. 일반적으로 프로젝트에서 선택을 해제하십시오. 벤더가 실사를했다고 가정하면 수동으로 할 필요없이 이와 같은 것을 제거해야합니다. 그러나 당신이 그것을 제거하는 방법이라면 분명히 때로는 그렇지 않은 것처럼 잘 잡습니다.
vapcguy

20

내 경우에는 ASP.NET 응용 프로그램을 실행하는 동안이 오류가 발생했습니다. 해결책은 다음과 같습니다.

  1. 프로젝트 폴더에서 objbin폴더 삭제

클린은 작동하지 않았고, 재 구축은 작동하지 않았으며, 모든 참조는 훌륭했지만 라이브러리 중 하나를 작성하지 않았습니다. 해당 디렉토리를 삭제하면 모든 것이 완벽하게 작동했습니다.


3
고마워, 레비 풀러이 답변은 더 높아야합니다. 내 상황에 그것은 자리에 있었다! 나 에게이 오류는 web.config의 백업 복사본을 만들 때 시작되었으며 Visual Studio는 복제본을 삭제 한 후에도 실제 구성 대신이 구성 파일을 계속로드했습니다. 이것은 그것을 해결했다. 감사.
BruceHill

나에게도 효과가 있습니다. 그래도 왜 이것이 작동하는지 확실하지 않습니다 :(
KangarooWest

14

필자의 경우 C : \ WINDOWS \ Microsoft.NET \ Framework \ ~ \ Temporary ASP.NET Files \ 디렉토리에있는 이전 버전의 DLL이었습니다. 이전 버전을 삭제하거나 교체하거나 프로젝트에서 DLL에 대한 참조를 제거하고 다시 추가 할 수 있습니다. 기본적으로 어느 쪽이든 임시 ASP.NET 파일에 대한 새 포인터를 만듭니다.


2
이것은 Visual Studio를 닫고 IIS를 중지하고 모든 임시 ASP.NET 파일을 삭제했을 때 효과적이었습니다. 64 비트 시스템의 경우 Framework 및 Framework64 폴더와 .NET 2.0 및 4.0 폴더에 파일이있을 수 있습니다!
Bryan B

Windows 시작 메뉴 검색 기능을 사용하여 솔루션에서 만든 모든 DLL을 찾은 다음 찾은 곳마다 전체 로트를 삭제했습니다. Visual Studio 디버깅 중에 만 만들어야하므로 걱정할 필요가 없습니다. VS가 누락 된 DLL을 다시 작성하고 솔루션 외부에서 아무것도 참조하지 않아야하므로 이것은 "안전한"작업이었습니다.
Zarepheth

8

우리에게는 문제가 다른 것이 원인이었습니다. DevExpress 구성 요소의 라이센스 파일에는이 특정 컴퓨터에 설치되지 않은 이전 버전의 구성 요소에 대한 두 줄이 포함되어 있습니다. 라이센스 파일에서 이전 버전을 제거하면 문제가 해결되었습니다.

성가신 부분은 오류 메시지가 어떤 참조가 문제의 원인인지를 알려주지 않았다는 것입니다.


2
필자의 경우 새 DevExpress 버전으로 업그레이드 한 후 양식의 .resx 파일에 오래된 제거 된 라이브러리 버전에 대한 참조가 포함되었습니다. 코드보기에서 .resx를 열고 버전을 새 것으로 수정하거나 유효하지 않은 항목을 삭제해야했습니다.
Artemix

5

바인딩하는 어셈블리가 강력한 이름을 얻거나 공개 키 토큰이 변경된 경우 리플렉션을 사용하여 늦은 바인딩을 시도하면 이와 동일한 오류가 발생합니다. 지정된 공개 키 토큰으로 실제로는 어셈블리가 없지만 오류는 동일합니다.

오류를 해결하려면 올바른 공개 키 토큰을 추가해야합니다 (dll에서 sn -T를 사용하여 얻을 수 있음). 도움이 되었기를 바랍니다.


1
"sn -T"란 무엇입니까? 공개 키 토큰은 어디에 추가합니까?
Moritz 둘 모두

3
"sn.exe"는 Visual Studio와 함께 제공되는 도구이며 Visual Studio 명령 프롬프트에서 실행할 수있는 명령 줄 도구입니다. 시작 메뉴에서 Visual Studio 명령 프롬프트를 실행하고 어셈블리가 들어있는 폴더로 이동 한 다음 "sn -T <assembly>"를 입력하십시오. 여기서 <assembly>는 dll의 전체 이름입니다. 어셈블리 "토큰"정보를 얻습니다. 이 정보가 표시되면 리플렉션을 사용하여 늦게 바인딩 할 때 토큰 정보를 어셈블리 ID 문자열에 입력하십시오 (예 : "Assembly = MyAssembly.dll, 공개 키 토큰 = <token guid>)
Guy Starbuck

2
이 답변에 감사드립니다. App.ini에서 구성 섹션을 참조 할 때이 오류가 발생했습니다. 최근에 어셈블리에 서명 했으므로 PublicKeyToken = null을 새로운 (올바른) 토큰으로 업데이트해야했습니다.
Liam

5

광산은 Nathan Bedford의 게시물과 매우 비슷한 상황 이었지만 약간 비 틀었습니다. 내 프로젝트도 두 가지 방법으로 변경된 dll을 참조했습니다. 1) 직접 및 2) 변경된 dll에 대한 참조가있는 구성 요소 (클래스 라이브러리)를 참조하여 간접적으로. 이제 component (2)에 대한 Visual Studio 프로젝트가 변경된 dll의 올바른 버전을 참조했습니다. 그러나 compnent 자체의 버전 번호는 변경되지 않았습니다. 결과적으로 새 버전의 프로젝트 설치가 클라이언트 시스템의 해당 구성 요소를 대체하지 못했습니다.

최종 결과 : 직접 참조 (1)와 간접 참조 (2)는 클라이언트 시스템에서 변경된 dll의 다른 버전을 가리 켰습니다. 내 dev 컴퓨터에서 잘 작동했습니다.

해결 : 응용 프로그램을 제거하십시오. 응용 프로그램 폴더에서 모든 DLL을 삭제하십시오. 제 경우와 같이 간단합니다.


4

누군가 내 전단 어리 석음의 혜택을 받도록하겠습니다. 완전히 별도의 응용 프로그램에 대한 종속성이 있습니다 (이 App1이라고합시다). 해당 App1의 dll이 새 응용 프로그램 (App2)으로 가져옵니다. APP1에서 업데이트 할 때마다 새 dll을 만들어 App2에 복사해야합니다. 잘. . .2 개의 서로 다른 App1 버전간에 복사하여 붙여 넣는 데 지쳤으므로 dll에 'NEW_'접두사를 추가했습니다.

잘. . . 빌드 프로세스가 / bin 폴더를 스캔하고 잘못 일치하면 위에서 언급 한 것과 동일한 오류 메시지가 표시됩니다. 내 "new_"버전을 삭제하고 멋지게 만들었습니다.


4

내 문제는 참조 된 어셈블리를 가져 오지 않고 소스 코드를 새 컴퓨터에 복사하는 것이 었습니다.

오류를 수정 한 것은 없으므로 서둘러 BIN 디렉토리를 모두 삭제했습니다. 내 소스 코드를 다시 작성하고 그때부터 작동했습니다.


4

기본 ASP.NET MVC 4 프로젝트를 만들고 NuGet을 통해 DotNetOpenAuth.AspNet을 추가했다는 것을 추가하고 싶습니다. Microsoft.Web.WebPages.OAuth에 대해 일치하지 않는 DLL 파일을 참조한 후에도 같은 오류가 발생했습니다.

그것을 고치기 위해 나는 Update-Package 전체 재건을 위해 솔루션을 청소했다.

그것은 나를 위해 일했고 게으른 방법이지만 시간은 돈입니다.


1
저에게도 비슷한 대답입니다. Update-Package -reinstall모든 NuGet 패키지를 동일한 버전으로 다시 설치합니다.
Jess

1
이것은 위대하다. 게시 해 주셔서 감사합니다. 나는 다른 위대한 제안을 모두 시도했지만 이것이 트릭을 수행 한 솔루션이었습니다. 이용 가능한 80 개가있는 경우에도 대체 솔루션을 기꺼이 게시하려는 사람들에게 선의에 감사드립니다
Hambone

4

Team Foundation Server의 빌드 서비스를 빌드하는 동안이 오류가 발생했습니다. NuGet으로 추가 된 동일한 라이브러리의 다른 버전을 사용하여 솔루션에 여러 프로젝트가있는 것으로 나타났습니다. NuGet으로 모든 이전 버전을 제거하고 새로운 버전을 모두 참조로 추가했습니다.

Team Foundation Server는 모든 DLL 파일을 하나의 디렉터리에 저장하며 물론 한 번에 특정 이름의 DLL 파일은 하나만있을 수 있습니다.


또 다른 방법은 "솔루션 용 NuGet 패키지 관리 ..."를 클릭하고 테스트 프로젝트와 테스트중인 프로젝트를 모두 동일한 (최신) 버전으로 업데이트하는 것입니다.
lixonn

4

내 app.config에

<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>

npgsql의 경우. 어떻게 든 사용자 컴퓨터에서 내 app.exe.config가 누락되었습니다. 그것이 바보 같은 사용자인지, 설치 프로그램 결함인지, 또는 안티 바이러스를 아직 막았는지 확실하지 않습니다. 파일을 교체하면 문제가 해결되었습니다.


3

이 오류가 발생하는 또 다른 이유를 찾았습니다. 특정 라이브러리의 모든 버전에서 GAC를 정리하고 실행 파일과 함께 배포 된 특정 버전을 참조하여 프로젝트를 빌드했습니다. 프로젝트를 실행할 때 최신 버전의 라이브러리를 검색하는 예외가 발생했습니다.

그 이유는 게시자 정책 이었습니다. GAC에서 라이브러리 버전을 제거했을 때 로컬로 배포 된 어셈블리를 사용하는 대신 어셈블리 로더가 GAC에서 게시자 정책을 발견하여 새로운 버전을 검색하라는 게시자 정책 어셈블리도 제거하는 것을 잊었습니다.


3

나에게 "Local.testtesttings"파일의 코드 커버리지 구성이 문제를 "원인했다". 거기에서 참조 된 파일을 업데이트하는 것을 잊었습니다.


3

프로젝트의 bin 폴더 내용을 삭제하고 솔루션을 다시 빌드하면 내 문제가 해결되었습니다.


1
알다시피, 당신은 저의 불행을 도와주었습니다. 정말로 감사합니다
Ronny Mahlangu

2

솔루션을 정리하고 다시 빌드하면 출력 디렉토리의 모든 dll이 바뀌지 않을 수 있습니다.

내가 제안하는 것은 폴더를 "bin"에서 "oldbin"으로 또는 "obj"를 "oldobj"로 바꾸는 것입니다.

그런 다음 다시 용액을 만들어보십시오.

타사 dll을 사용하는 경우 성공적인 빌드 후 새로 만든 "bin"또는 "obj"폴더에 복사해야합니다.

이것이 당신에게 도움이되기를 바랍니다.


1

폴더 위치에서 이전 어셈블리를 수동으로 삭제 한 다음 새 어셈블리에 대한 참조를 추가하면 도움이 될 수 있습니다.


1

같은 오류가 발생했습니다 ... 내 경우에는 다음과 같이 해결되었습니다.

  • 처음에 응용 프로그램이 설치되었을 때 사람들은 응용 프로그램에서 Microsoft Enterprise Library 4.1을 사용했습니다.
  • 지난 주에 내 컴퓨터의 형식이 지정되었으며 그 후 오늘 해당 응용 프로그램을 빌드 할 때 Enterprise Library 어셈블리가 누락되었다는 오류가 발생했습니다.
  • 그런 다음 Google에 첫 번째 검색 항목으로 얻은 Microsoft Enterprise Library 5.0을 설치했습니다.
  • 그런 다음 응용 프로그램을 만들 때 위의 오류가 발생했습니다. 즉, 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다.
  • 많은 검색 작업 및 분석 후 응용 프로그램이 4.1.0.0을 참조하고 bin 폴더의 DLL 버전이 5.0.0.0임을 알았습니다.
  • 그런 다음 Microsoft Enterprise Library 4.1을 설치했습니다.
  • 이전 참조 (5.0)를 제거하고 4.0 참조를 추가했습니다.
  • 응용 프로그램 및 voila를 구축했습니다 ... 작동했습니다.

1

이 문제를 해결하는 방법은 다음과 같습니다.

  1. 예외 메시지에서 "문제"라이브러리의 이름과 "예상"버전 번호를 가져옵니다.

여기에 이미지 설명을 입력하십시오

  1. 솔루션에서 해당 .dll의 모든 복사본 을 찾아 마우스 오른쪽 단추로 클릭하고 .dll의 버전을 확인하십시오.

여기에 이미지 설명을 입력하십시오

자,이 예에서 내 .dll은 확실히 2.0.5022.0입니다 (예외 버전 번호가 잘못되었습니다).

  1. 솔루션의 모든 .csproj 파일에서 예외 메시지에 표시된 버전 번호를 검색 하십시오. 이 버전 번호를 dll의 실제 번호로 바꾸십시오.

따라서이 예에서는 이것을 대체 할 것입니다.

<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

... 이것으로 ...

<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />

작업 완료!


내 csproj 파일에 버전 참조가 없으면 어떻게합니까?
John Demetriou

1

내 경우에는 의자와 키보드 사이에 문제가있었습니다 :-)

Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference.
(Exception from HRESULT: 0x80131040)

두 개 이상의 다른 어셈블리가 다른 버전의 DotNetOpenAuth 라이브러리를 사용하려고했지만 문제가되지 않습니다. 또한 내 로컬 컴퓨터에서 web.config가 NuGet에 의해 자동으로 업데이트되었습니다.

<dependentAssembly>
    <assemblyIdentity name="DotNetOpenAuth.AspNet" publicKeyToken="2780ccd10d57b246" culture="neutral" />
        <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
    </dependentAssembly>
    <dependentAssembly>
        <assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780ccd10d57b246" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-4.3.0.0" newVersion="4.3.0.0" />
</dependentAssembly>

그런 다음 새 web.config를 프로덕션 서버에 복사 / 배치하는 것을 잊었다는 것을 깨달았습니다. 따라서 web.config를 수동으로 배포하는 방법이 있다면 업데이트되었는지 확인하십시오. 프로덕션 서버에 대해 완전히 다른 web.config가있는 경우 NuGet을 사용한 후 이러한 dependentAssembly 섹션을 동기화해야합니다.


1

" 위치 된 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다 "와 같은 오류가 발생 하고 VS의 프로젝트> NuGet 패키지 및 업데이트 관리 탭을 통해 업데이트 한 경우 가장 먼저 할 일은 다른 버전의 NuGet Gallery 페이지 에서 버전을 확인 하고 패키지 관리자 콘솔에서 다음 명령을 실행 한 후 패키지 :

PM> Install-Package YourPackageName -Version YourVersionNumber 
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0

답변은 문제의 패키지와 직접 관련이 없으며 답장을 받았지만 일반적이며 관련성이 있으며 누군가에게 도움이되기를 바랍니다.


1

해결책이 없습니다. 깨끗한 프로젝트 솔루션, 빈 제거, 패키지 업데이트, 다운 그레이드 패키지 등을 시도했습니다 ... 2 시간 후에 어셈블리가있는 프로젝트에서 기본 App.config를로드하고 잘못된 참조 버전을 변경했습니다.

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-5.5.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

에:

<dependentAssembly>
    <assemblyIdentity name="Microsoft.IdentityModel.Logging" publicKeyToken="31bf3856ad364e35" culture="neutral" />
    <bindingRedirect oldVersion="0.0.0.0-3.14.0.0" newVersion="5.5.0.0" />
</dependentAssembly>

이 후 프로젝트를 정리하고 다시 빌드하면 효과가 있습니다. 아무런 경고도 없습니다.


0

빌드 할 어셈블리와 이름이 같은 어셈블리를 참조하여이 오류 메시지가 표시되었습니다.

컴파일되었지만 참조 된 어셈블리를 현재 프로젝트 어셈블리로 덮어 써서 오류가 발생했습니다.

이 문제를 해결하기 위해 프로젝트 이름과 프로젝트를 마우스 오른쪽 버튼으로 클릭하고 '속성'을 선택하여 사용 가능한 어셈블리 속성을 변경했습니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.