"Visual Studio에서 메타 데이터 파일 '… \ Release \ project.dll'을 찾을 수 없습니다"오류
최근 에이 메시지를 무작위로 받기 시작했습니다.
Visual Studio에서 메타 데이터 파일 '... \ Release \ project.dll'을 찾을 수 없습니다
여러 프로젝트가 포함 된 솔루션이 있습니다. 현재 빌드 모드는 디버그이며 모든 프로젝트 구성은 디버그로 설정되어 있습니다. 그러나 주 프로젝트를 실행하려고 할 때-때로는 몇 가지 오류가 발생합니다. 모든 메타 데이터 파일 '... \ Release \ projectX.dll'을 찾을 수 없습니다 '입니다-그리고, RELEASE에 대해 말합니다. 폴더이지만 현재 모드는 디버그입니다. 왜? 모든 솔루션 파일에서 "Release \ projectX.dll"에 대한 참조를 검색하려고했으나 ResolveAssemblyReference.cache 파일에서 하나를 찾았습니다.
나는 인터넷을 통해 좋은 검색을했고 비슷한 문제를 가진 몇몇 사람들을 찾았지만 해결책이 없거나 최소한 해결책이 없었습니다.
그 프로젝트에 대한 참조를 삭제하고 읽으려고했지만 언젠가 이러한 오류가 다시 발생하기 시작합니다.
버그 인 것 같습니다. 항상 디버그 모드를 사용할 때 릴리스 폴더에서 참조 된 프로젝트를 검색하는 이유는 무엇입니까?
추신. 이 문제를 만난 사람들을 위해 : 나는 쉽게 해결할 수 없었습니다. Windows를 다시 설치 한 후에 만 사라졌습니다.
모두가 정확합니다 ... 모든 것을 시도하십시오 ... (약간에서 많은 시간을 낭비하는 순서로)
- 잘못된 코드가 있습니까? 먼저 수정하십시오.
- 솔루션 정리 및 Visual Studio 다시 시작
- 참조 제거 / 추가
- 더 큰 프로젝트로 빌드 순서를 확인하고 확인하십시오.
- 하위 프로젝트 수동 재 구축
- 프로젝트 간 dll을 관련 bin 폴더에 수동으로 복사
- 가서 커피를 마시고, 핀볼을하고 내일 다시 오세요 ... 그 동안 다른 것을 생각할 수도 있습니다.
나는 똑같은 문제가 있었다. 50 개 이상의 프로젝트가 포함 된 큰 비주얼 스튜디오 솔루션.
모든 참조는 프로젝트로 추가되었습니다. 프로젝트 빌드 순서가 정확했습니다 (프로젝트를 마우스 오른쪽 버튼으로 클릭하고 빌드 순서를 선택하십시오).
그러나 더 높은 수준의 프로젝트를 만들 때 그들이 사용했던 "루트"프로젝트는 빌드되지 않았습니다.
문제는 이러한 프로젝트가 현재 구성에서 빌드되도록 선택되지 않았다는 것입니다 (이 방법을 모름).
이를 확인하려면 "구성 관리자"(빌드 메뉴)를 선택하십시오. e 문제가있는 프로젝트가 빌드되도록 설정되어 있는지 확인하십시오.
해당 프로젝트에 대한 참조를 삭제하고 다시 추가했다고 말하면 정확히 어떻게 다시 추가 했습니까? Visual Studio의 "참조 추가"대화 상자에서 "찾아보기"탭을 사용 했습니까? 또는 "프로젝트"탭을 사용 했습니까 (솔루션의 주변 프로젝트가 나열되어 있습니까)?
편집 : "찾아보기"탭을 사용하고 / Release 폴더에있는 .dll에 대한 참조를 수동으로 추가하면 Visual Studio는 사용자가 어떤 모드에 관계없이 항상 해당 위치에서 .dll을 찾습니다. 현재 (디버그 또는 릴리스)
Release 폴더에서 실제 .dll 파일을 수동으로 제거하거나 "Clean Solution"을 수행하여 제거하면 .dll이 없기 때문에 참조가 중단됩니다.
ProjectX.dll에 대한 참조를 제거하고 다시 추가하는 것이 좋습니다. 이번에는 "참조 추가"대화 상자의 "프로젝트"탭을 사용하십시오. 이 방법으로 참조를 추가하면 Visual Studio는 적절한 .dll을 얻을 수있는 위치를 알고 있습니다. 디버그 모드 인 경우 / Debug 폴더에서 가져옵니다. 릴리스 모드 인 경우 / Release 폴더 빌드 오류가 사라지고 디버그 모드에서 더 이상 Release .dll을 참조하지 않게됩니다.
글쎄, 내 대답은 모든 솔루션의 요약 일뿐 만 아니라 그 이상을 제공합니다.
섹션 1):
일반적인 해결책 :
이 종류의 오류 4 개 ( '메타 데이터 파일을 찾을 수 없음')와 '소스 파일을 열 수 없습니다 ('지정되지 않은 오류 ')'라는 오류 1 개가 있습니다.
'메타 데이터 파일을 찾을 수 없습니다'오류를 제거하려고했습니다. 이를 위해 많은 게시물, 블로그 등을 읽었으며 이러한 솔루션이 효과적 일 수 있음을 알았습니다 (여기에서 요약).
VS를 다시 시작하고 다시 빌드하십시오.
'솔루션 탐색기'로 이동하십시오 . 솔루션을 마우스 오른쪽 버튼으로 클릭하십시오. 속성으로 이동하십시오 . '구성 관리자'로 이동하십시오 . '빌드' 아래의 확인란이 선택되어 있는지 확인하십시오 . 그들 중 일부 또는 전부가 선택 해제 된 경우, 점검하고 다시 빌드하십시오.
위의 해결 방법으로 문제가 해결되지 않으면 위의 2 단계에서 언급 한 순서를 따르십시오. 모든 확인란이 선택되어 있어도 선택을 해제하고 다시 확인한 후 다시 빌드하십시오.
주문 및 프로젝트 종속성 빌드 :
'솔루션 탐색기'로 이동하십시오 . 솔루션을 마우스 오른쪽 버튼으로 클릭하십시오. 이동 '... 프로젝트 종속성' . 'Dependencies' 와 'Build Order'의 두 탭이 표시됩니다 . 이 빌드 순서는 솔루션이 빌드되는 순서입니다. 프로젝트 종속성 및 빌드 순서를 확인하여 다른 프로젝트 (예 : 'project2')에 종속 된 일부 프로젝트 (예 : 'project1')가 해당 프로젝트 (project2)보다 먼저 빌드하려고하는지 확인하십시오. 이것은 오류의 원인 일 수 있습니다.
누락 된 .dll의 경로를 확인하십시오.
누락 된 .dll의 경로를 확인하십시오. 경로에 공백 또는 유효하지 않은 다른 경로 문자가 포함 된 경우 경로를 제거한 후 다시 빌드하십시오.
이것이 원인이면 빌드 순서를 조정하십시오.
섹션 2):
내 특별한 경우 :
VS를 몇 번 다시 시작하여 다양한 순열과 조합으로 위의 모든 단계를 시도했습니다. 그러나 그것은 도움이되지 않았습니다.
그래서 나는 내가 겪었던 다른 오류 ( '소스 파일을 열 수 없습니다 ('지정되지 않은 오류 ')')를 제거하기로 결정했습니다.
나는 블로그를 발견했다 : http://www.anujvarma.com/tfs-errorsource-file-could-not-be-opened-unspecified-error/#comment-1539
나는 그 블로그에서 언급 한 단계를 시도하고 '소스 파일을 열 수 없습니다 ('지정되지 않은 오류 ')'오류를 제거했으며 놀랍게도 다른 오류 ( '메타 데이터 파일을 찾을 수 없음') 도 제거했습니다.
섹션 (3) :
이야기의 교훈:
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.
I've had this problem before and the only way I've found to solve it is to run Clean Solution and then restart Visual Studio.
Re-open Visual Studio as Administrator.
For me it's usually the target framework being off (4.5.2 instead of 4.6) If you fix the target framework of the project to match the target framework of the solution and build, a new .dll will be created.
Most of the answares say that you need to remove the libraries of your solution, this is true but when you re-add the libraries the error will be shown again. You need to verify if all the libraries referenced have a compatible .net framework with the .net framework of your solution. Then fix all the errors in your code and rebuild the solution.
Did you check the Configuration manager settings? In the project settings dialog top right corner.
Sometimes it happens that between all the release entries a debug entry comes in. If so, the auto dependency created by the dependency graph of the solution gets all confused.
I've also seen this error in solutions where I have multiple projects (usually netTiers projects where I've updated one or more of the sub-projects to target the 4.0 framework). It can be problematic to remove. Oftentimes it can be resolved, however, by first fixing all other errors in sub-projects (eg, any missing references), individually rebuilding those sub-projects, then removing/adding back any references to those sub-projects in Visual Studio. Personally, I've had little luck resolving this error by cleaning the solution alone.
We recently ran into this issue after upgrading to Office 2010 from Office 2007 - we had to manually change references in our project to version 14 of the Office Interops we use in some projects.
Hope that helps - took us a few days to figure it out.
In my case it was caused by two things (VS.2012):
1) One of the projects was configured for AnyCPU instead of x86
2) A project that was referenced had somehow the "Build" checkbox unchecked.
Do check your Build | Configuration Manager to get an overview of what is being built and for which platform. Also make sure you check it for both Debug & Release as they may have different settings.
In my case, I had some errors in my code. Visual Studio showed the error you had instead of the actual errors, like syntax errors or unknown class names. Try cleaning the solution and building project after project. This way you will discover the actual errors.
Again, this is just what cause the error for me.
I had this problem and took long while to figure it out. Problem came up when I removed projects from solution and replaced those with nuget packages.
Solution seemed to be fine but the .csproj file still contained those projects multiple times as reference.
Seems that VS does not clean that file appropriately. It was still referencing the removed projects under the hood. When manually removed the references from csproj file all works again! wohoo
This problem is due to pdb files or CodeContracts.
To resolve it:
Clean your output folder and rebuild the solution.
Re-Configure the CodeContracts or disable it for temporary build.
We have that problem quite often, but only with references to C++/CLI projects from C# projects. It's obviously a bug deep down in Visual Studio that Microsoft decided not to fix, because it's 'too complex' and they promised an overhaul of the C++ build system which is now targeted for Visual Studio 2010.
That was some time ago, and maybe the fix even went into Visual Studio 2008; I didn't follow up on it any more. However, our typical workaround was
- Switch configuration
- Restart Visual Studio
- Build the solution
I had the same problem myself.
Visual Studio 2013 only told me that it couldn't reference to it, and it couldn't find the metadata. When I opened my solution (which has multiple projects in it) it said that I was using projects lower than the framework version of one of my projects.
So I switched everything to version 4.5, and it worked again.
I seem to recall having a similar problem a few months ago. I solved it temporarily by copying the referenced DLL to the Release folder, thus satisfying Visual Studio's expectations. Later, I discovered the reference to the Release DLL in my actual code. You should try doing a search through the entire project for \release\project.dll.
Also, I have noticed that Visual Studio unit test projects sometimes put a "DeploymentItem" attribute on each of the test methods pointing to your target DLL, and if you switch between Debug and Release, Visual Studio can get confused if the DLL is no longer in the expected location. In my experience, these attributes can be safely deleted if you didn't put them there yourself as part of a "single deployment" scenario.
I had this problem and it was due to an invalid method in the offending library (dll) that did not return a value, e.g.
public bool DoSomething()
{
//I never bothered putting code here....
}
When I commmented this out everything compiled :)
Sometimes VS2010 switches my configuration from Any CPU to Mixed Platforms. When this happens I get this error message.
To resolve it I switch back to Any CPU:
1. Right click on the solution and select properties.
2. Click on Configuration Properties and then the Configuration Manager... button.
3. Under Active solution platform select Any CPU
I find that this usually occurs to me when i still have a method declaration in an interface, which a class implements, but that i had later removed and had forgotten to remove it from the interface as well. I usually just save the entire solution every 30mins n then just revert back to an earlier version if i cant find the error.
I ended up deleting my references (I had added them properly using the projects tab, and they used to build just fine), hand editing my .csproj files and removing bizarre entries that didn't belong -- and setting my outputs for debug and release, x86 and x64 and any cpu to all be "\bin" -- I built it once, then re-added the reference (again, using the projects tab), and everything started working again for me. Didn't have to restart Visual Studio at all.
For me this was caused by the Build target having been rewritten to not output the dll. Removing this to fall back on the default Build target fixed the issue.
in my case i was working on a branch off master. so i checked out master branch, ran a build and then checked out my branch. It fixed the issue. If you already are on master, i suggest you check out previous commit and then build it.
It seems to happen when you checkout a solution with multiple projects that have references between them, and you haven't built it before. If you have references directly to the dlls, instead of referencing the project, you'll get this message. You should always use the Projects tab in the Add Reference dialog to add a reference to a project in the same solution. This way, VS can know the correct order in which to build the solution
same happened to me today as described by Vidar.
I have a Build error in a Helper Library (which is referenced by other projects) and instead of telling me that there's an error in Helper Library, the compiler comes up with list of MetaFile-not-found type errors. After correcting the Build error in Helper Library, the MetaFile errors gone.
Is there any setting in VS to improve this?
I had the same problem. I noticed that my db context (EF4) that was located in the project dll wasn't recognize for some reason. I deleted it and created another one instead. and that solved it for me.
Had the same problem today.
My application, a Windows Forms applications, accidently had a reference to itself. Weird.
Once removed, the error went away.
The reference got added each time I dragged a user control, located in the Windows Forms project itself, to a form.
I agree with most of the answers posted here. However if all the suggested solutions didn't work, consider that you probably have another kind of error in your error list, that is preventing VS to build a project's DLL needed for the other projects. Then no matter the build order or configuration, you won't be able to get rid of "metadata" error till the other issues are sorted out.
I had the same problem. Manually removing and adding the dlls did not help. ClassLibraries did not compile for all the projects and were missing in the ...\bin\Debug folder for the project [because I cleaned solution by mistake]. Since the class library did not compile that means there may be some errors somewhere in one of those sub projects.
Solution: Since my dlls were there for the ...\bin\Release folder, I tried to rebuild on Release mode and found an error on one line in one of the sub projects. Solving the error and rebuilding the solution got rid off the build error.
'development' 카테고리의 다른 글
| 개인 유형에서 자동을 사용할 수있는 이유는 무엇입니까? (0) | 2020.06.28 |
|---|---|
| 도커 오류가 도커 컨테이너를 삭제할 수 없습니다. 충돌 : 저장소 참조를 제거 할 수 없습니다 (0) | 2020.06.28 |
| clang을 llvm IR로 컴파일하는 방법 (0) | 2020.06.28 |
| 프로그래밍 방식으로 루트 로깅 수준을 변경하는 방법 (0) | 2020.06.28 |
| Android에서 글꼴 크기에 sp를 사용해야하는 이유는 무엇입니까? (0) | 2020.06.28 |