ChatGPT解决这个技术问题 Extra ChatGPT

Metadata file '.dll' could not be found

I am working on a WPF, C# 3.0 project, and I get this error:

Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem

This is how I reference my usercontrols:

xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>

It happens after every failed build. The only way I can get the solution to compile is to comment out all my user controls and re-build the project, and then I uncomment the usercontrols and everything is fine.

I have checked build orders and dependencies configurations.

As you can see, it seems to have truncated the DLL file's absolute path... I have read that there is a bug with the length. Is this a possible problem?

It's very annoying and having to comment, build, and uncomment, the build is becoming extremely tiresome.

I had a similar problem (getting the same error that is indicated at the title) and handled it by cleaning and rebuilding the project. To correctly reference other projects, I do have no idea..
I have marked Matt's answer as it seems to have worked for most people however this did not resolve my original issue. I still think it is related to the Windows max path limit. See my answer below.
I tried all the answers above and unfortunately nothing worked in my case. I encountered with 2 errors 1. Missing .dll file 2. Method already defined at another place with same parameters I have cleared the second error first by removing the function which has been duplicated at another place. My first error - that is .dll file missing has solved on its own. I want to say if you have more than single error along with .dll missing file error! Please try to solve the other errors first. May be .dll error solves on it own!
We also get the metadata file '.dll' not found issue when you are referring a project dll which built on higher version .Net framework than your current project.

B
BenKoshy

I just had the same problem. Visual Studio isn't building the project that's being referenced.

Written Instructions:

Right click on the solution and click Properties. Click Configuration on the left. Make sure the check box under "Build" for the project it can't find is checked. If it is already checked, uncheck, hit apply and check the boxes again. (Optional) You had to do it for both Release and Debug modes on the solution properties.

Screen capture Instructions:

They say a picture is worth a thousand words. Click on the GIF to zoom in, and hopefully it will be easy to follow:

https://i.stack.imgur.com/F3Cs3.gif


Simble uncheck/check didn't solve issue so I've had to do next steps: - clean solution - uncheck all build checkboxes - restart VS - check all build checkboxes - build solution
The other thing to do is check each of the project dependencies, for some reason it wasn't setting this automagically. Solution Properties -> Common Properties -> Project Dependencies.
Dumbest thing ever. I unchecked/rechecked for the release config, because it said it was getting the error in the release/bin folder. That didn't fix it. I did the same thing for the debug configuration and then the release/bin error went away. Microsoft 0/10
This happened to me after updating some NuGet Packages for my solution. Visual Studio was not building the project that was being referenced in the error output, and the intellisense was incorrectly indicating that there were no issues with the project in error. After I built the specific project in error, the intellisense decided to kick in, and at that point, I was able to see the errors in my project. (some methods that I was using had been removed in an updated NuGet Package)
I tried all the solutions but it didn't worked for me. but updating framework version to higher version (in my case 4.6.1) fixed the issue. Actually, it was a newly added dll which required higher framework version in my project.
P
Peter Mortensen

This can still happen in newer versions of Visual Studio (I just had it happen on Visual Studio 2013):

Another thing to try is to close Visual Studio and delete the .suo file that is next to the .sln file. (It will be re-generated the next time you Save all (or exit 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.


This fixed the problem for me. Also worth mentioning is that .suo files are hidden. So you'll have to setup your explorer to show hidden files.
I'm working with Xamarin project and the .suo file is located in the .vs/ folder . I tried deleting it and it didn't solve my problem
VS2013 - I had to move my TFS Workspace to a different location. After I completed this I started to get this error. Deleting the sou file worked for me.
This worked for me too. But in Visual Studio 2015, the .suo file is both hidden and sits within a hidden .vs directory beside the .sln. e.g.: if the solution file is c:\foo\mysolution.sln then look for c:\foo\mysolution\.vs\mysolution\v14\.suo
For VS2017, for simplicity, I just deleted the .vs hidden folder instead which also deleted the .suo file. I reopened the solution, fixed one more unrelated error, and the issue was resolved.
P
Peter Mortensen

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.


I was able to fix by matching the framework for the project to the higher version indicated in the warning message by right clicking on the project > Properties > Application > Target Framework.
Wow, this fixed it for me. New project was targeting a different .net version. Can't believe there isn't a check for this even in vs2017.
Worth noting that the problem can go deeper than just the project that is causing problems. Even if that project is targeting the right framework, if that project depends on another project and the dependent project is targeting a different framework, then it can cause this problem too.
I think it's useful to point out that you might be able to spot the "decoyed" error by looking in the Ouput window. In my case, after disabling the build for the highlighted projects as described in the accepted answer from @Matt_Bro, I ran the build again and spotted the real problem in the Output window, since the build was failing even if no error was displayed in the Error List.
In my case it was yet again to do with with Target .NET Framework of the project being older than the one of a referenced assembly. I could visualize the correct error only in the Output window as per my previous comment.
P
Peter Mortensen

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.


My problem was Build Order/Project Dependencies. Removing and adding back references from other projects will correct this (I think) but you can just do it yourself as well.
I faced this problem by down-grading .NET v4.5 project to .NET v.4.
Removing "%" from referenced dll path helped me
The solution in Section 2 worked for me! I had another error and when I fixed that the others magically dissappeared.
I had the same issue as Boogier. Had a %20 in my folder name instead of a space and the dll was looking for a space. Spent so much time trying all the other fixes, when the actual one was the simplest.
P
Peter Mortensen

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.


This also happens between 4.5.2 Vs. 4.6
Indeed, I had one of 4.6.1 and the rest was 4.5.2, thanks!
Yes, seems any time a framework version is different, this happens. Great error Microsoft!
Yup! I was trying to use a .Net 4.7.1 .dll when my project was .Net 4.6.1. The warning was hidden by other items, but no error about it. My error was a red herring
Indeed!, I add a project reference trying to use a .NET 4.7.1 and my project was .NET 4.6.1. It doesn't show me a error in the Error List Window, but in the console keeps telling me "The type or namespace name '...' does not exist in the namespace '...' (are you missing an assembly reference?)". My solution was to move all the projects to .NET 4.8.
P
Peter Mortensen

Closing and reopening Visual Studio 2013 worked for me!


P
Peter Mortensen

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 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.


please MAKE SURE YOU USE VERSION CONTROL BEFORE YOU DO ANYTHING
A
Andrew

Visual Studio 2019 this worked for me:

Close Visual Studio Delete the hidden .vs folder Reopen Visual Studio and rebuild the solution.


B
BlueRaja - Danny Pflughoeft

I also met this problem. Firstly you have to manually build you DLL project, by right-click, Build. Then it will work.


While this fix works, it doesn't actually fix the problem and could lead to more underlying problems. First of all, if you're working with code in a repository, it is bad form to require a new developer to jump through hoops to get the code to a point where it will build. Second of all, in order to see changes in the referenced project, you would have to manually rebuild it every time. Please see my answer for a more robust fix to the problem.
In my case, it does not even build the project individually, it gives me the same error. Let say my project name is "proj1", when I build it (manually as you said) it give me Metadata file ...proj1.dll could not be found!
a
alfi

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.


Could you elaborate more your answer adding a little more description about the solution you provide?
My git clone added % to my folder path, removing these solved the issue.
That was my problem too, when I cloned the project it was named using "%20" instead of a simple space. Thanks @abarisone, your approach solved my problem.
When I cloned my project from TFS it also added a %20 for some reason. Deleting fixed the issue for me as well.
Also fixed it for me, I re-cloned and removed the %20 that git added in place of a space
P
Peter Mortensen

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.


Well, I was about to answer the same, in my case I added a new project targeting .Net 4.5.x and It started to happen when, form that project I added a reference to a project that was using .Net 4.6.
P
Peter Mortensen

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).


I dont know why now but i was running my projects for a year like that. my sub project was 4.6.1 and main project was 4.5.2. it worked without any problem. suddenly i am getting this error but i dont want to downgrade the sub project because it has feature that exist in 4.6.1 i dont believe this is the problem. Microsoft explains it should still be working
TLDR: Check compile warnings. This is what happened to me but with a twist. projs were at 4.5.2. Added new projects at 4.6. Installed nuget packages on 4.6 projects. Downgraded 4.6 projects to 4.5.2. Nugets were expecting 4.6. Downgrades of nugets solved.
C
Chris Moschini

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.


P
Peter Mortensen

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...


Exactly. I had a similar error. I found out it was related to an error in a dependant project that prevented a successful build.
P
Peter Mortensen

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 experienced this problem as well. There was no error in the Error List, but the failed build results in DevOps showed the error
P
Peter Mortensen

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.


P
Peter Mortensen

For me the following steps worked:

Find the project that is not building

Remove/add references to projects within the solution.


Right click on the reference "folder" in the solution explorer, "remove unused references". I did this on all my projects in this solution, it did the trick
P
Peter Mortensen

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.


Ugh, this. So many things Microsoft require a restart to work again.
D
David Ford

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.


A
Ajaco

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.


P
Peter Mortensen

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


Which is...? 260? Or slightly less (in practice)?
P
Peter Mortensen

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.


It is an additional solution to the same problem. I know the OP is old, but based on the last couple of posts, people are still finding other causes. Just trying to save the next guy some frustration as none of the other solutions worked for me either.
P
Peter Mortensen

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 error was hidden until I opened Visual Studio 2015 in Adminstrator mode. Only then did it show the compilation error. After fixing that, I could continue.
P
Peter Mortensen

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#?.


M
Murat Yıldız

Most of the methods explained here did not solved the problem for me.

Finally, I fixed the problem by applying the following steps:

1. Close Visual Studio.

2. Delete all the contents in the bin folders of each project.

3. Open solution and rebuild.


C
Code_Worm

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.


t
tbone

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 something similar recently - out of the blue, hundreds of cs0006 errors in the Error log but nothing else (and I combed through it with a very fine comb). Eventually (!) I thought of looking at the Output window, and there was a compiler error reported, and sure enough in the code the error had a red squiggle under it. I have no idea why the error wasn't reported in the Errors window. VS2017 Enterprise.
D
Dmitri Trofimov

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.


P
Peter Mortensen

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?


I dunno how as I haven't changed anything and don't have any custom build events or configurations
P
Peter Mortensen

I had this issue because .nuget\NuGet.exe was not included in my repository. Although I enabled DownloadNuGetExe in NuGet.targets, it reported a proxy error when trying to download it. This caused the rest of the project builds to fail.