찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다.
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 : line 123의 x.Foo.Foo2 (String groupName_)에서
FooTests.cs : line 98 **의 x.Foo.UnitTests.FooTests.TestFoo ()에서
System.IO.FileLoadException : 파일 또는 어셈블리 'Utility, Version = 1.2.0.203, Culture = neutral, PublicKeyToken = 764d581291d764f7'또는 해당 종속성 중 하나를로드 할 수 없습니다. 찾은 어셈블리의 매니페스트 정의가 어셈블리 참조와 일치하지 않습니다. (HRESULT에서 예외 : 0x80131040)
나는 내 참고 문헌을 살펴보고 Utility version 1.2.0.203(다른 하나는 오래되었습니다)에 대한 참조 만 있습니다 .
이 DLL 파일의 이전 버전을 참조하려는 것이 무엇인지 알아내는 방법에 대한 제안이 있습니까?
게다가, 내 하드 드라이브에이 오래된 어셈블리조차 없다고 생각합니다. 이 이전 버전의 어셈블리를 검색하는 도구가 있습니까?
.NET 어셈블리 로더가 1.2.0.203을 찾을 수 없지만 1.2.0.200을 찾았습니다. 이 어셈블리는 요청 된 것과 일치하지 않으므로이 오류가 발생합니다. 간단히 말해, 참조 된 어셈블리를 찾을 수 없습니다. GAC 또는 응용 프로그램 경로에 넣어 올바른 어셈블리를 찾을 수 있는지 확인하십시오. http://blogs.msdn.com/junfeng/archive/2004/03/25/95826.aspx 도 참조하십시오 .
이 문제를 해결하기 위해 몇 가지 작업을 수행 할 수 있습니다. 먼저 Windows 파일 검색을 사용하여 하드 드라이브에서 어셈블리 (.dll)를 검색합니다. 결과 목록이 있으면보기-> 세부 정보 선택 ...을 수행 한 다음 "파일 버전"을 확인하십시오. 그러면 결과 목록에 버전 번호가 표시되므로 이전 버전의 출처를 확인할 수 있습니다.
또한 Lars가 말했듯이 GAC에서 어떤 버전이 나열되어 있는지 확인하십시오. 이 Microsoft 문서 에서는 GAC에있는 어셈블리가 빌드 중에 로컬로 복사되지 않으므로 모두 다시 빌드하기 전에 이전 버전을 제거해야 할 수 있다고 설명합니다. ( 이 작업을 수행하기 위해 배치 파일을 만드는 방법에 대한 메모는 이 질문에 대한 내 답변을 참조하십시오 )
여전히 이전 버전의 출처를 알 수없는 경우 Visual Studio와 함께 제공되는 fuslogvw.exe 응용 프로그램을 사용하여 바인딩 실패에 대한 자세한 정보를 얻을 수 있습니다. Microsoft는 여기 에이 도구에 대한 정보를 제공 합니다 . HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Fusion\EnableLog레지스트리 키를 1 로 설정하여 로깅을 활성화해야합니다 .
나는이 문제를 직접 만났고 다른 사람들이 겪은 것과 다른 문제라는 것을 발견했습니다.
내 주 프로젝트에서 참조하는 두 개의 DLL, CompanyClasses.dll 및 CompanyControls.dll이 있습니다. 다음과 같은 런타임 오류가 발생했습니다.
파일 또는 어셈블리 'CompanyClasses, 버전 = 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를 참조한 후)이 오류가 사라졌습니다.
다음은 모든 어셈블리 버전을 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)이 없으면 작동하지 않습니다.
Visual Studio를 사용하는 경우 "클린 솔루션"을 시도한 다음 프로젝트를 다시 빌드하십시오.
다른 답변은 나를 위해 작동하지 않습니다. 버전에 신경 쓰지 않고 앱을 실행하려면 참조를 마우스 오른쪽 버튼으로 클릭하고 '특정 버전'을 false로 설정하십시오.
나는 방금이 문제를 만났고 문제는 응용 프로그램 디버그 디렉토리에 .dll의 이전 사본이 있다는 것입니다. GAC 대신 거기에서 확인하여 표시되는지 확인할 수도 있습니다.
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>
필자의 경우이 오류는 ASP.NET 응용 프로그램을 실행하는 동안 발생했습니다. 해결책은 다음과 같습니다.
- Delete the
objandbinfolders in the project folder
Clean didn't work, rebuild didn't work, all references were fine, but it wasn't writing one of the libraries. After deleting those directories, everything worked perfectly.
In my case it was an old version of the DLL in C:\WINDOWS\Microsoft.NET\Framework\~\Temporary ASP.NET Files\ directory. You can either delete or replace the old version, or you can remove and add back the reference to the DLL in your project. Basically, either way will create a new pointer to the temporary ASP.NET Files.
I am going to blow everyone's mind right now . . .
Delete all the <assemblyBinding> references from your .config file, and then run this command from the NuGet Package Manager console:
Get-Project -All | Add-BindingRedirect
For us, the problem was caused by something else. The license file for the DevExpress components included two lines, one for an old version of the components that was not installed on this particular computer. Removing the older version from the license file solved the issue.
The annoying part is that the error message gave no indication to what reference was causing the problems.
This exact same error is thrown if you try to late bind using reflection, if the assembly you are binding to gets strong-named or has its public-key token changed. The error is the same even though there is not actually any assembly found with the specified public key token.
You need to add the correct public key token (you can get it using sn -T on the dll) to resolve the error. Hope this helps.
Mine was a very similar situation to the post by Nathan Bedford but with a slight twist. My project too referenced the changed dll in two ways. 1) Directly and 2) Indirectly by referencing a component (class library) that itself had a reference to the changed dll. Now my Visual studio project for the component(2) referenced the correct version of the changed dll. However the version number of the compnent itself was NOT changed. And as a result the install of the new version of the project failed to replace that component on the client machine.
End result: Direct reference (1) and Indirect reference(2) were pointing to different versions of the changed dll at the client machine. On my dev machine it worked fine.
Resolution: Remove application; Delete all the DLLS from application folder; Re-install.Simple as that in my case.
I'll let someone benefit from my shear stupidity. I have some dependencies to a completely separate application (let's call this App1). The dll's from that App1 are pulled into my new application (App2). Any time I do updates in APP1, I have to create new dll's and copy them into App2. Well. . .I got tired of copying and pasting between 2 different App1 versions, so I simply added a 'NEW_' prefix to the dll's.
Well. . . I'm guessing that the build process scans the /bin folder and when it matches something up incorrectly, it barfs with the same error message as noted above. I deleted my "new_" versions and it built just dandy.
My issue was copying source code to a new machine without pulling over any of the referenced assemblies.
Nothing that I did fixed the error, so in haste, I deleted the BIN directory altogether. Rebuilt my source code, and it worked from then on out.
I would like to just add that I was creating a basic ASP.NET MVC 4 project and added DotNetOpenAuth.AspNet via NuGet. This resulted in the same error after I referenced a mismatching DLL file for Microsoft.Web.WebPages.OAuth.
To fix it I did a Update-Package and cleaned the solution for a full rebuild.
That worked for me and is kind of a lazy way, but time is money:-P
I got this error while building on Team Foundation Server's build-service. It turned out I had multiple projects in my solution using different versions of the same library added with NuGet. I removed all old versions with NuGet and added the new one as reference for all.
Team Foundation Server puts all DLL files in one directory, and there can only be one DLL file of a certain name at a time of course.
My app.config contains a
<bindingRedirect oldVersion="1.0.0.0" newVersion="2.0.11.0"/>
for npgsql. Somehow on the user's machine, my app.exe.config went missing. I am not sure if it was a silly user, installer glitch, or wacked out anti-virus yet. Replacing the file solved the issue.
I just found another reason why to get this error. I cleaned my GAC from all versions of a specific library and built my project with reference to specific version deployed together with the executable. When I run the project I got this exception searching for a newer version of the library.
The reason was publisher policy. When I uninstalled library's versions from GAC I forgot to uninstall publisher policy assemblies as well so instead of using my locally deployed assembly the assembly loader found publisher policy in GAC which told it to search for a newer version.
To me the code coverage configuration in the "Local.testtesttings" file "caused" the problem. I forgot to update the files that were referenced there.
Just deleting contents of your project's bin folder and rebuild the solution solved my problem.
clean and rebuild the solution might not replace all the dll's from the output directory.
what i'll suggest is try renaming the folder from "bin" to "oldbin" or "obj" to "oldobj"
and then try build your silution again.
incase if you are using any third party dll's those you will need to copy into newly created "bin" or "obj" folder after successful build.
hope this will work for you.
Manually deleting the old assembly from folder location and then adding the reference to new assemblies might help.
I got the same error... In my case it got resolved as follows:
- At first when the application was installed then the people here had used Microsoft Enterprise Library 4.1 in the application.
- In previous week my machine was formatted & after that today when I built that application then it gave me an error that Enterprise Library assembly is missing.
- Then I installed Microsoft Enterprise Library 5.0 which I got on Google as first search entry.
- Then when I built the application then it gave me the above error i.e. The located assembly's manifest definition does not match the assembly reference.
- After much of a search work & analysis, I found that application was referring 4.1.0.0 & the DLL in the bin folder was of the version 5.0.0.0
- What i did was then I installed the Microsoft Enterprise Library 4.1.
- Removed the previous reference(5.0) & added the 4.0 reference.
- Built the application & voila...it worked.
Here's my method of fixing this issue.
- From the exception message, get the name of the "problem" library and the "expected" version number.
- Find all copies of that .dll in your solution, right-click on them, and check which version of the .dll it is.
Okay, so in this example, my .dll is definitely 2.0.5022.0 (so the Exception version number is wrong).
- Search for the version number which was shown in the Exception message in all of the .csproj files in your solution. Replace this version number with the actual number from the dll.
So, in this example, I would replace this...
<Reference Include="DocumentFormat.OpenXml, Version=2.5.5631.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
... with this...
<Reference Include="DocumentFormat.OpenXml, Version=2.0.5022.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL" />
Job done !
In my case the problem was between the chair and the keyboard :-)
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)
Two or more different assemblies wanted to use a different version of the DotNetOpenAuth library, and that would not be a problem. Furthermore, on my local computer a web.config was automatically updated by 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>
Then I realized that I had forgot to copy/deploy the new web.config to the production server. So if you have manual way of deploying web.config, check it is updated. If you have completely different web.config for production server, you have to merge these dependentAssembly section in sync after using NuGet.
If you ever get an error like "The located assembly's manifest definition does not match the assembly reference" and if you have updated via Project > Manage NuGet Packages and Update tab in VS, the first thing you could do is try installing another version of the package after checking versions from NuGet Gallery page and running the folowing command from Package Manager Console:
PM> Install-Package YourPackageName -Version YourVersionNumber
//Example
PM> Install-Package Microsoft.Extensions.FileProviders.Physical -Version 2.1.0
Although answer is not directly related to the package in question and it was asked way back, it is kind of generic, still relevant and hope it helps someone.
I received this error message due to referencing an assembly that had the same name as the assembly I was building.
This compiled but it overwrote the referenced assembly with the current projects assembly - thus causing the error.
To fix it I changed the name of the project, and the assembly properties available through right-clicking on the project and choosing 'Properties'.
In your AssemblyVersion in AssemblyInfo.cs file, use a fixed version number instead of specifying *. The * will change the version number on each compilation. That was the issue for this exception in my case.
'IT박스' 카테고리의 다른 글
| 포트 번호가 지정된 scp (0) | 2020.09.30 |
|---|---|
| Android의 인 텐트에서 추가 데이터를 얻으려면 어떻게해야합니까? (0) | 2020.09.30 |
| @property와 getter 및 setter 사용 (0) | 2020.09.30 |
| @class vs. #import (0) | 2020.09.30 |
| 로컬 및 원격 Git 리포지토리 모두의 마스터 브랜치 이름 변경 (0) | 2020.09.29 |