메타 데이터 파일 '.dll'을 찾을 수 없습니다.
WPF, C # 3.0 프로젝트에서 작업 중이며이 오류가 발생합니다.
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
이것이 내 사용자 컨트롤을 참조하는 방법입니다.
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
모든 실패한 빌드 후에 발생합니다. 컴파일 할 솔루션을 얻을 수있는 유일한 방법은 모든 사용자 컨트롤을 주석 처리하고 프로젝트를 다시 빌드 한 다음 사용자 컨트롤의 주석 처리를 제거하면 모든 것이 정상입니다.
빌드 순서 및 종속성 구성을 확인했습니다.
보시다시피 DLL 파일의 절대 경로가 잘린 것 같습니다. 길이에 버그가 있다는 것을 읽었습니다. 이것이 가능한 문제입니까?
매우 성 가시고 주석을 달고, 빌드하고, 주석을 제거해야하는 빌드가 매우 지루해지고 있습니다.
나는 단지 같은 문제가 있었다. Visual Studio는 참조되는 프로젝트를 빌드하지 않습니다.
서면 지침 :
- 솔루션을 마우스 오른쪽 버튼으로 클릭하고 속성을 클릭합니다.
- 왼쪽에서 구성을 클릭합니다.
- 찾을 수없는 프로젝트에 대한 "Build"아래의 확인란이 선택되어 있는지 확인하십시오. 이미 선택되어 있으면 선택을 취소하고 적용을 누른 다음 상자를 다시 선택하십시오.
- (선택 사항) 솔루션 속성에서 릴리스 및 디버그 모드 모두에 대해 수행해야했습니다.
화면 캡처 지침 :
- 그들은 사진이 천 단어의 가치가 있다고 말합니다. 확대하려면 GIF를 클릭하면 쉽게 따라 할 수 있습니다.
이는 최신 버전의 Visual Studio에서 여전히 발생할 수 있습니다 (방금 Visual Studio 2013에서 발생했습니다).
시도 할 또 다른 방법은 Visual Studio를 닫고 .suo
파일 옆에있는 .sln
파일 을 삭제하는 것입니다 . (다음 번에 Save all
(또는 Visual Studio를 종료 할 때) 다시 생성됩니다 ).
I've had this problem when adding new projects to the solution on another machine and then pulling the revisions in, but the .suo
file can be corrupted in other cases as well and lead to very strange Visual Studio behaviour, so deleting it is one of the things I always try.
Note that deleting the .suo
file will reset the startup project(s) of the solution.
More on the .suo
file is here.
The suggested answer did not work for me. The error is a decoy for another problem.
I found out that I was targeting a slightly different version of .NET and this was flagged as a warning by the compiler, but it was causing building to fail. This should have been flagged as an error and not a warning.
Well, my answer is not just the summary of all the solutions, but it offers more than that.
Section (1):
In general solutions:
I had four errors of this kind (‘metadata file could not be found’) along with one error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.
I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs, etc. and found these solutions may be effective (summarizing them over here):
Restart Visual Studio and try building again.
Go to 'Solution Explorer'. Right click on Solution. Go to Properties. Go to 'Configuration Manager'. Check if the checkboxes under 'Build' are checked or not. If any or all of them are unchecked, then check them and try building again.
If the above solution(s) do not work, then follow sequence mentioned in step 2 above, and even if all the checkboxes are checked, uncheck them, check again and try to build again.
Build Order and Project Dependencies:
Go to 'Solution Explorer'. Right click on Solution. Go to 'Project Dependencies...'. You will see two tabs: 'Dependencies' and 'Build Order'. This build order is the one in which solution builds. Check the project dependencies and the build order to verify if some project (say 'project1') which is dependent on other (say 'project2') is trying to build before that one (project2). This might be the cause for the error.
Check the path of the missing .dll:
Check the path of the missing .dll. If the path contains space or any other invalid path character, remove it and try building again.
If this is the cause, then adjust the build order.
Section (2):
My particular case:
I tried all the steps above with various permutations and combinations with restarting Visual Studio a few times. But, it did not help me.
So, I decided to get rid of other error I was coming across ('Source File Could Not Be Opened (‘Unspecified error ‘)').
I came across a blog post: TFS Error–Source File Could Not Be Opened (‘Unspecified error ‘)
I tried the steps mentioned in that blog post, and I got rid of the error 'Source File Could Not Be Opened (‘Unspecified error ‘)' and surprisingly I got rid of other errors (‘metadata file could not be found’) as well.
Section (3):
Moral of the story:
Try all solutions as mentioned in section (1) above (and any other solutions) for getting rid of the error. If nothing works out, as per the blog mentioned in section (2) above, delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file.
In my case it was caused by a .NET Framework version mismatch.
One project was 3.5 and the other referencing project 4.6.1.
Closing and reopening Visual Studio 2013 worked for me!
Well, nothing in the previous answers worked for me, so it got me thinking about why am I clicking and hoping when as developers we should really try to understand what is going on here.
It seemed obvious to me that this incorrect meta data file reference must be held somewhere.
A quick search of the .csproj file showed the guilty lines. I had a section called <itemGroup> that seemed to be hanging onto the old incorrect filepath.
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
So a simple fix really:
- Backup your .csproj file.
- Find the incorrect paths in the .csproj file and rename appropriately.
Please make sure you backup your old .csproj before you fiddle.
I also met this problem. Firstly you have to manually build you DLL project, by right-click, Build. Then it will work.
I got the same error "Metadata file '.dll' could not be found", and I tried several things described above, but the reason for the error was that I was referencing third-party DLL file which was targeting a .NET version higher that my project target .NET version. So the solution was to change the target framework of my project.
In my case, I have my installed directory in mistaken ways.
If your solution path is something like "My Project%2c Very Popular%2c Unit Testing%2c Software and Hardware.zip", it cannot resolve the metadata file, perhaps we should prevent some invalid words like %2c.
Renaming the path into normal name resolved my issue.
I added a new project to my solution and started getting this.
The reason? The project I brought in was targeting a different .NET framework (4.6 and my other two were 4.5.2).
For me, it was trying to find a DLL in a path that used to contain the Project, but we'd moved it to a new directory. The Solution had the correct path to the Project, but Visual Studio somehow kept looking in the old location.
Solution: Rename each problem Project - just add a character or whatever - then rename it back to its original name.
This must reset some global cache of some kind in Visual Studio, because this clears both this issue up and several like it, while things like Clean do not.
For me it occurred when I included a new project to a solution.
Visual Studio automatically selects .NET framework 4.5.
I changed to version .NET 4.5.2 like the other libraries, and it worked.
For me the following steps worked:
- Find the project that is not building
- Remove/add references to projects within the solution.
I was pulling my hair out with this problem also, but after trying the previous answers the only thing that worked for me was to open each project in my solution 1 by 1 and build them individually.
Then I closed Visual Studio 2013, reopened my solution and it compiled fine.
It's strange, because if I clicked each project in my Solution Explorer and tried to build them that way, they all failed. I had to open them alone in their own solutions.
My instance of the problem was caused by a common project that had a duplicate class name in it (under a different filename). It is strange that Visual Studio could not detect that and instead just blew up the build process.
I got this problem in Visual Studio 2012 in a solution that had many projects. Rebuilding each project in the solution manually in the same order as the Project Build Order (right-click and rebuild in Solution Explorer) fixed it for me.
Eventually I got to one that gave me a compile error. I fixed the error, and the solution would build correctly after that.
In my case the issue was that I'd manually deleted a non-compilation file which was marked as "missing". Once I deleted the reference to the now-missing file and recompiled - all was well.
Coming back to this a few years later, this problem is more than likely related to the Windows maximum path limit:
Naming Files, Paths, and Namespaces, Maximum Path Length Limitation
In my case, the problem was caused by a simple build error,
error CS0067: The event 'XYZ' is never used
that, for any reason, did not show up in the error window.
Because of that, the Visual Studio build system seemed to miss the error and tried to build dependent projects, which in turn failed with the annoying metadata message.
The recommendation is -as stupid as it may sound-:
First look at your Output Window!
It took me half an hour before this idea hit me...
It looks like such kind of errors related to the fact that Visual Studio doesn't provide correct information about an error. The developer doesn't even understand the reason for the failed build. It can be a syntax error or something else. In common, to solve such problems you should find the root of the problem (for example, look at the build log).
In my case the problem was in fact that the Error List
window didn't show any errors. But really there were syntax errors; I found these errors in the Output
window, and after fixing them, the problem was solved.
I too had the same error. It hides as in the below path. The path which I referred to for the DLL file is like "D:\Assemblies Folder\Assembly1.dll".
But the original path in which the assembly referred was "D:\Assemblies%20Folder\Assembly1.dll".
Due to this path name variation, the assembly could not be retrieved from its original path and hence throws the "Metadata not found" error.
The solution is in Stack Overflow question How do I replace all the spaces with %20 in C#?.
I'd faced the same problem. In my case I'd referenced to a class library project with higher .Net version than my project and VS failed to build the project and raised the same error you posted.
I simply set .Net version of my class library project(the one that had broken the build) identical to the .Net version of referenced project and problem solved.
If you have a space in your solution name, this will also cause the issue. Removing the space from your solution name, so path doesn't contain %20 will solve this.
Just pointing out the blatantly obvious: if you don't have "Show output window when build starts" enabled, make sure you're noticing if your build is failing (small "build failed" error in lower left)!!!!
I had this error when I was trying to publish a web application. Turned out that one of a class properties was wrapped into
#if DEBUG
public int SomeProperty { get; set; }
#endif
but the property usage was not. The publishing was done in Release configuration without the DEBUG
symbol, obviously.
Based on the error message I don't believe the file path is being truncated. It looks to just be incorrect. If I'm reading the message correctly it appears to be looking for the DLL file at ...
WORK=-\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
This is not a valid path. Is it possible that you have a macro definition in the build process set to an invalid value?
This error may be shown if you use fake assemblies. Removing fakes leads to successful build of the project.
I am running Visual Studio 2013.
빌드 종속성이 잘못된 것 같습니다. * .suo 파일을 삭제하면 문제가 해결되었습니다.
제 경우에는 특정 (빈) 네임 스페이스의 클래스를 주석 처리했습니다.
namespace X.Y.Z.W
{
// Class code
}
네임 스페이스 코드와 가져 오기 (사용) 명령을 제거하면 문제가 해결되었습니다.
빌드에서 프로젝트의 누락 된 DLL 파일과 함께 다음과 같이 말합니다.
오류 CS0234 : 유형 또는 네임 스페이스 이름 'W'가 네임 스페이스 'XYZ'에 없습니다 (어셈블리 참조가 누락 되었습니까?).
참고 URL : https://stackoverflow.com/questions/1421862/metadata-file-dll-could-not-be-found
'developer tip' 카테고리의 다른 글
jQuery로 요소에 대한 클래스 목록 가져 오기 (0) | 2020.10.02 |
---|---|
하나를 수정하지 않고 Python에서 두 목록을 연결하는 방법은 무엇입니까? (0) | 2020.10.02 |
날짜를 일반 형식으로 인쇄하는 방법은 무엇입니까? (0) | 2020.10.02 |
std :: string과 int를 연결하는 방법은 무엇입니까? (0) | 2020.10.02 |
Bash에서 stderr 및 stdout 리디렉션 (0) | 2020.10.02 |