Metadata file '.dll' could not be found

Question

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.

Solution 1

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

Written Instructions:

1. Right click on the solution and click Properties.
2. Click Configuration on the left.
3. 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.
4. (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:

Solution 2

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.

Solution 3

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.

Solution 4

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

1. Restart Visual Studio and try building again.

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

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

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

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

Solution 5

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.

View more solutions

Comments

[phoad]

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

[Oliver]

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.

[Des Horsley]

possible duplicate of Metadata file '...\Release\project.dll' could not be found in Visual Studio

[A user]

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!

[narendramacha]

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.

[StayOnTarget]

The solution to similar question stackoverflow.com/questions/20490857/… worked for me.

[Crismogram]

The fact that this thing still happens in 2018 pains me a lot. I'm not even sure how I manage to fix it. Its like a VS thing or something.

[niico]

Something else to try, I fixed all the other errors in the solution and this problem went away.

[Lupa]

This worked for me in VS2019 .Net Core, ASP.Net Core solution. Open a PowerShell console in the same location of the solution. type dotnet restore and then dotnet build, the solution will be built and now it can be built from Visual Studio IDE too. None of the other solution given worked for me.

[Matt]

In my case, none of the answers helped. So I reviewed error by error in the following way. Example: ProjectA.dll could not be found. In the same line it is listed from which other projects it is referenced. say RefProject.csproj. In solution explorer, go to "Dependencies" and remove there the ProjectA reference. Do that for all errors. Then, perform a clean+rebuild getting more errors. Most of them are due to missing reference. Re-Add them using Intellisense, and process error by error. In the end the solution will compile again. It was likely caused by corrupt csproj file metadata.

[Oliver]

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

[Matt_Bro]

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.

[frankie]

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

[Anicho]

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.

[George Howarth]

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.

[Eric]

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.

[user145400]

Isn't this supposed to be automatically set when you add a project reference?

[abarisone]

Could you elaborate more your answer adding a little more description about the solution you provide?

[Nacht]

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.

[svick]

please MAKE SURE YOU USE VERSION CONTROL BEFORE YOU DO ANYTHING

[Alexander Derck]

Just had the same problem with one of the projects in my solution. Unchecking and checking "build" didn't work. What did the trick for me was to remove the project from the solution and add it again.

[Erik Bergstedt]

My git clone added % to my folder path, removing these solved the issue.

[Admin]

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

[StronglyTyped]

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.

[Vin]

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.

[Yatrix]

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

[guneysus]

I faced this problem by down-grading .NET v4.5 project to .NET v.4.

[AlbatrossCafe]

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

[jhenninger]

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)

[Emil]

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

[Wyck]

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

[Dmytro Laptin]

I had it happen on VS 2015 update 3 and Matt's solutions worked for me.

[Juan]

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.

[Ben]

I am using VS2017RC and deleting the .suo file in the hidden top level .vs folder worked for me!

[A-Sharabiani]

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!

[Patrick Borkowicz]

For me it was also a missing library (Microsoft.SqlServer.Types in my case). that NuGet failed to restore properly when I cloned the solution from version control. I ran update-package -reinstall <package-name> which fixed it. The missing dll errors were a consequence of this, and I failed to scroll down far enough in the Error List to notice ;)

[Veverke]

doing so leads me to an IL merge issue (ilmerge exited with code 1)

[George Polevoy]

It's not a summary of all other answers as claimed in the heading. The solution to your particular case does not address the original problem

[Vikram]

@GeorgePolevoy, please read first line of my answer properly. "Well, my answer is not just the summary of all the solutions, but it offers more than that." I myself made it clear that it is not just the summary of other answers. I have given few common strategies that may work (kind of summary) (section 1). But, after that I explained a case where none of these worked and I had to solve the problem by some other way (section 2). So, people can try section 1 first and if they have case similar to mine, they can try section 2.

[Vikram]

@GeorgePolevoy, already 56 users have upvoted it. Your downvote brought it down to 55. If it would not have been useful, why would so many users have upvoted it? Please read properly before you comment and think before you downvote.

[AzzamAziz]

This also happens between 4.5.2 Vs. 4.6

[Mathieu VIALES]

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

[DGibbs]

In my case, I had a couple class library projects which were running under lower .NET target frameworks than the main project. Switching them from 4.5 > 4.6 fixed my issue.

[Andy Mepham]

After cleaning my solution Visual Studio 2015 crashed out and restarted. I was subsequently getting this issue; all projects were checked under the solution configuration; unchecking and checking again worked. Very strange!

[Lost]

It's funny how this shows up as Page 2 solution to this problem but in my case this was the real problem.

[RayLoveless]

For me I needed to update the Target framework(properties -> applictaion tab). Then the .dll was being created.

[Phil M]

Fix any other errors you get; They might silently stop the project building so no dll is created. When I resolved the other error I had, the build completed and all errors went away.

[Jota.Toledo]

2017 and this answer is still saving some asses. In one my class libraries a dependency was being shown as "installed", but NugetPackageManager showed that it needed to be installer. Reinstalling solved my issue

[Mason]

Indeed, I had one of 4.6.1 and the rest was 4.5.2, thanks!

[Admin]

Yes, seems any time a framework version is different, this happens. Great error Microsoft!

[Sanjeev Rai]

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.

[alfi]

@abarisone I removed the "%2c" string from the path, then it worked

[Brk]

This might be too obvious, but make sure that the targeted dll's are not already in use via another instance of Visual Studio or by another exe.

[Gabriel Marius Popescu]

In my case, I had to remove the bad reference that was under the References -> Analyzers. As soon as I removed it, I was able to build it properly.

[Boogier]

Removing "%" from referenced dll path helped me

[Jorge Urreta]

Thanks a lot. This solved this problem for me on VS 2013, after struggling with it for almost an hour

[Florian Winter]

Doesn't work. All projects already checked for build, and unchecking, saving, checking again, saving doesn't help, either.

[w00ngy]

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.

[Douglas Gaskell]

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.

[jwatts1980]

C#7 features in VS2015 were causing this error message for me. (Expressions-bodied member for a setter, specifically) I had to update to VS2017.

[Erick Smith]

Had 4.5.2 and 4.5 as my project frameworks so I made them both 4.5.2 and then ran Update-Package -reinstall

[Peter Mortensen]

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

[Peter Mortensen]

What is a "fake assembly"? Can you elaborate? (Respond by expanding your answer.)

[Esaith]

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

[Peter Mortensen]

Can you provide another example of the value of "Language Version"?

[haughtonomous]

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.

[ethane]

In VS2017 the .suo has the same path as in @Wyck 's comment. Altough, yours may be in a v15 folder and not v14.

[guneysus]

@kkuilla It was too long ago. Unfortunately I dont remember. Since I have not upvote any answers, may be created a clean .NET 4 project and manually moved source files.

[Diwas Poudel]

Just update all reference package from nuget package manager.After that just restart Visual Studio.

[Lanklaas]

Closing and opening visual studio helped me. Thanks

[user3613932]

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.

[Casey Crookston]

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.

[Martin Johansson]

The solution in Section 2 worked for me! I had another error and when I fixed that the others magically dissappeared.

[Steve]

Visual Studio 2015. I did this, but I still had an error I needed to resolve. It might be worth mentioning that doing this didn't make this error disappear until I resolved the other error.

[alelom]

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.

[alelom]

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.

[Sébastien Richer]

@AlexanderDerck Unload and Reload on the project did it for me. After trying a bunch of the answers here. Thanks for the tip!

[S.L. Barth]

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.

[Marcus Parsons]

I just had an error that was unrelated to all of this. I had an extra } at the end of the class file which caused the metadata error.

[Lenny K]

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.

[Douglas Gaskell]

This just started happening out of the clue... every project file fails to build, with the only errors being the metadata ones. Nothing seems to work to resolve this.

[Flemming Bonde Kentved]

This did not work for me. I found the error in my case. It was because I removed the nuget package Mahapps which I was no longer using anywhere so I just wanted to clean up. After I removed it, I got the error without anything indicating the mahapps nuget package. I found out that I had the nuget package in 2 projects, one projectreferencing the other. They had a different version of the package, which might have been the underlying problem. I updated both to the latest version before removing them. That fixed the problem.

[Abdul Wahab]

If you have wcf in your project, clean the solution, update their references and Rebuild solution. Restart VS. That fixed my problem!

[Yusuf Tarık Günaydın]

Using preview versions of .NET Core can also cause this problem. It can be disabled from: Options - Project and Solutions - .NET Core - Use previews of the .NET Core SDK.

[FrenkyB]

For me, there was an error in code. But, VS2019 was not showing where error is - instead, it was just showing 'metadata could not be found...' - because it was not able to build project. After restart, all was good - error was shown, I've made correction and solution was normally build. Sometimes restart makes miracles with Microsoft products.

[J.D.]

Still happening in VS 2019 as of today. Marked answer actually worked for me. I just had to make sure I iterated through every configuration type (Release, Debug, etc) and unchecked, apply, rechecked, apply on all of them.

[J.D.]

Still a bug in VS 2019 and this fix works, as of 12/10/2019. I had to ensure to clean the project first, then just run the project (not rebuild) after this fix.

[amartin]

I experienced this problem as well. There was no error in the Error List, but the failed build results in DevOps showed the error

[M. A. Cordeiro]

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.

[Selthien]

When I cloned my project from TFS it also added a %20 for some reason. Deleting fixed the issue for me as well.

[AHAMED AAQIB]

this happen due to some existing issues also such as NuGet Packages update wanted,any file mixing etc.Once you fixed the other issues and rebuild then this issue may be sorted.

[Ivan-San]

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.

[hijinxbassist]

This was the issue i had as well, the error was being swallowed when building from the project containing the other projects. Opening the new or suspect projects and trying to compile revealed the mismatch in target framework (not as an error but in the output log).

[Raphael Pinel]

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

[computercarguy]

This worked for me with VS 2019 Community Ed.

[JimiSweden]

This pointed me to the underlying problem, I had put the string interpolation '$' on the wrong side of the '@' , like this: @$"som text {myVariable}"; when it should be like this: $@"som text {myVariable}"; causing one project not to build and thus other depending projects failed to build. - When I disabled all project builds and enabled them one by one with the "core / library project" first I got the warnings in output needed to pinpoint the root cause

[Zimano]

No files of that sort are in the same folder as my solution file.

[Reddy]

Also fixed it for me, I re-cloned and removed the %20 that git added in place of a space

[paparush]

My solution path had %20 in the directory path. That was a cloned repo from Azure DevOps. Not sure why Visual Studio decided to create an html safe string when cloning from Azure DevOps Removing the %20 from the directory path resolved this issue for me.

[Imran Khan]

Worked for me. I am using VS 2019

[Had To Ask]

I just had to run dotnet restore xxx.sln from a dev prompt due to nuget restore commad not picking up PackageReferences