[c#] 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 faced this problem. In my case I delete all bin and obj folders from all projects then this error will resolve for me. Try this for one more try to resolve the problem

I had the same issue. In my case, the project would still build in release mode and it was just when I tried to build in debug that it failed.

What I ended up doing to fix the issue was simply copy all of the dlls (and other files from my release folder) into my debug folder. After doing this for every project, the errors melted away.

I had this error when tried to publish my project,

All answered above, not helped me...

I just change my deploy and the publish successed!

For my case it was that I had commented out classes in a specific (empty) namespace:

namespace X.Y.Z.W
{

    // Class code

}

When I removed the namespace code and the import (using) commands of it - it fixed the problem.

In the build it was also saying - along with the missing DLL file of the project:

error CS0234: The type or namespace name 'W' does not exist in the namespace 'X.Y.Z' (are you missing an assembly reference?)

In my case it was ReSharper being dumb and, even though my project targets C# 6 I was being offered refactorings to use C# 7-only features.

For this reason I ended up changing this code,

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get { return _joinedDate ?? DateTime.Now; }
    set { _joinedDate = value; }
}

into this code:

private DateTime? _joinedDate;
[Column(TypeName = "DateTime2")]
public DateTime JoinedDate
{
    get => _joinedDate ?? DateTime.Now;
    set => _joinedDate = value;
}

For some reason having the getter and setter using expression bodies made the compiler come up with that metadata error instead of a syntax error.

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.

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:

1. Backup your .csproj file.
2. Find the incorrect paths in the .csproj file and rename appropriately.

Please make sure you backup your old .csproj before you fiddle.

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.

This worked for me in VS2019 .Net Core, ASP.Net Core solution.

1. Open a PowerShell console in the same location of the solution.
2. Type dotnet restore to restore al packages and projects
3. Type dotnet build. The solution will be built

Now it can be built also from Visual Studio IDE too. None of the other solution given worked for me

In my case, the parent folder of the solution had a %20 in the name. I renamed the parent folder by removing the %20 and the issue got fixed.

The Visual Studio IDE doesn't do any building behind the scenes, the Msbuild application does. The VS IDE essentially just constructs the project file that is used by Msbuild and quite often it makes mistakes if you leave it up to the IDE to figure things out on it's own. If you are getting the Metadata file '.dll' could not be found error it is likely due to the fact that the correct/expected assemblies are not being found. So perhaps Visual Studio might be creating a project file for a 4.5 framework app, and expecting 4,5 assemblies, while you are referencing 4.0 assemblies. So look at your Visual Studio settings for incompatibilities or go into the project file yourself, and manually fix it by specifying the correct path <Reference Include="C:\\correct path to assembly\\yourAssembly.dll" />.

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?

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.

aaaaaand six years later during an upgrade to Visual Studio 2015 the same problem. Because this particular solution is not in this list I'm adding to it.

Two referenced dll's were in the c:\windows\system32... folder. Moving them to a non system folder and adding a reference to the new folder fixed it finally. The rest of the issues was indeed what others have said here already

For me it was wrong folder name. If you close from source that replaces spaces with '%20', you will get such errors. Solution - just rename badly named folders.

In my case, I solved this problem after noticing that I had referenced a .Net Framework 4.7 project as a dependency on a .Net Framework 4.6.1 project. After migrating project 4.7 to 4.6.1 my application compiled normally

In my case inside my Web.config file changing this

<?xml version="1.0" encoding="utf-8"?>

to this

<?xml version="1.0"?>

fixed my problem

In my case some of the projects in the solution were targeted to Any CPU, some of them to x86. The compilation error disappeared after unifying the platform target across the solution.

I had a merge conflict in one .csproj file and ended up with two copies of one build target.

<Compile Include="SystemCodes\APSystemCodes.cs" />

After I eliminated the duplicate the build worked.

I received this error after opening a project in which Entity Framework was referenced, so I deleted such references, and reinstalled Entity Framework version 6.0.0.0 through pthe acket manager this way:

install-package entityframework -version 6.0.0.0

The error was still showing, so I thought that those references were there because there was an older version of Entity Framework supposedly "preinstalled" on the project, but it was not really working.

So I went up to the file packages.config and noticed that there was another reference:

<packages>
  **<package id="EntityFramework" version="5.0.0" targetFramework="net45" />**
  <package id="EntityFramework" version="6.0.0" targetFramework="net45" />
</packages>

Then I deleted the line, cleaned and rebuild the project and the container solution, and it finally worked.

1. Right click on the solution and click Clean.
2. Right click on the solution and click Rebuild.

Removing the packages folder containing NuGet in the solution folder worked for me. After rebuilding everything worked again. Check References in the solution and check for references that have a yellow triangle.

Example picture:

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.

I had a similar problem when I decompiled a very old library, which was deployed in a production environment, but the source code was lost.

I took .dll, decompiled and generated projects and solution. I was unable to build the solution due to several errors of this kind.

Tips in previous answers did not help, but after a while I noticed missing references in some projects to several assemblies like System.dll.

Suppose there is project A dependent on project B. There was no reference to System.dll in project B, but the error after build was like "Metadata file 'B.dll' could not be found".

There was no error about missing System.dll in project B.

Adding reference on libraries like System.dll in project B solved the problem. (System.Data, System.DirectoryServices, etc.)

In my case, these errors were caused by some corruption in the NuGet package manager. Subprojects of the solution were not getting built, but no errors were showing because of the metadata errors.

Once all the NuGet packages were corrected, the project could build properly again.

I had the same issue and another solution.

The issue: One solution, multiple Projects. The main application that uses some of the other results failed, saying:

CSC : error CS0006: Metadata file 'C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplication.dll' could not be found

But actually this Project generated C:\Repos\TheApplication\TheApplicationCommon\bin\Debug\TheApplicationCommon.dll Another project that also uses the same dll compiled flawlessly.

Before I updated an internal NuGet-package that used PostSharp 3.x.x.x and now uses PostSharp 4.x.x.x. And my solution was to add this to my *.csproj file:

<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="...">
  <Import Project="..." Condition="..." />
  <PropertyGroup>
    ...
    <AssemblyName>TheApplication</AssemblyName>
    ...
    <SkipPostSharp>True</SkipPostSharp> <!-- This line -->
  </PropertyGroup>
...

Another Solution->Clean, another Solution->Rebuild and it works locally and on the build server.

Hope it helps someone. The thread is old and quite long but this issue returns often and I didn't see this solution yet. Btw using Visual Studio 2017 (15.8.x).

I faced this issue after getting latest (Team Foundation Server (TFS) command).

After resolving the conflicts I found using a statement for a namespace that does not exist in the project.

So I removed that using statement then clean and rebuild, and everything was OK.

I got this issue after updating the dlls/nuget.

I could solve this manually by correcting the .csproj file. Mostly the version wasn't updated in the file. For example :

<Analyzer> Include="..\packages\Microsoft.CodeAnalysis.**VersionCheckAnalyzer.2.9.1**\analyzers\dotnet\Microsoft.CodeAnalysis.VersionCheckAnalyzer.dll"/>

<Analyzer> Include="..\packages\Microsoft.CodeAnalysis.**VersionCheckAnalyzer.2.9.7**\analyzers\dotnet\Microsoft.CodeAnalysis.VersionCheckAnalyzer.dll"/>

Wow, it seems like this error can come from everywhere.

Anyway, I added a new WebAPI controller to my MVC application and it automagically got all the references from NuGet. Little bit later I removed the references from the NuGet UI, but I forgot to delete the files using them (i.e. System.Http).

For some reason, the error I was receiving was this, along with a simple warning about a variable not being used.

I commented out the variable to get rid at least of the warning and rebuilding pointed me out of all the files that were using the non-existing reference. After deleting those files, everything went OK.

I ran into this error with Visual Studio 2015 when I removed the type annotation from a call to an extension method, which left only the empty angle brackets behind.

So instead of obj.extensionMethod<Type>() I had obj.extensionMethod<>().

I would classify this as a bug in Visual Studio since I don't see how that mistake could produce that error.

I have agree all aboves just a difference. In my case: I am using Visual Studio 2019. I closed VS-2019 and opened with VS-2017. and rebuild the project everything working great! For whom in my position date is: 4/19/2019

I have found out that if you remove Microsoft.CSharp assembly as a reference in the project, you will get this error.

The framework version of the current project differs from remaining projects. Change of framework version to existing projects version will resolve this.

Navigate to Solution's Folder Explorer and delete the unused project folder that was throwing error. In my case, after deleting the project, the folder was still present in the directory. After deleting the folder solution built successfully!

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.

Hope this helps.

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.

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

This issue could occur due to a syntax error in your code that might not be visible to you because of the Meta Data error. So review your source file before doing any of the actions in previous answers.

Check the .csproj file of main project. Visual Studio does not clean that up in case you remove projects or alter references in the solution.

I had old projects referenced three times in the .csproj file and compile showed this error to those removed projects.

Visual Studio 2019 this worked for me:

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

I had a class in 4.6.1 refering an interface that was in 4.6.2... upgrading the class to 462 fixed it.

Deleting the bin/obj folders and then rebuilding the project worked for me.

In my case, what I believe happened was that I experienced a run time error the first time I built the project so my dll file was not not generated.

This happened when referencing a project from another. The project I was referencing was the one with the issue.

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.

This issue can happen because you are using features that are not supported by the version of .net selected for the project.

In my case the reason was I used ?? operator to check for null and throw exception.

Strange enough that VS doesn't inform about the actual reason of the problem in the list of build errors.

But you can find this information in the Output logs of the build.

In VS 2019, under the project References check if there are any unresolved items by expanding Analyzers:

For me, there were two .dll files with wrong paths. Right click on each and select Remove:

Build the project, then build the solution. Done.

In my personal case, I had failed to add a reference to one of the projects in the solution and this is what was kicking up the error for me.

None of the dozens of answers so far worked for me. In my case, I also got the error:

Tuple element name 'Value' is inferred. Please use language version 7.1 or greater to access an element by its inferred name

This appeared next to "Metadata file '.dll' could not be found" errors on building, but it disappeared shortly after, as errors sometimes do as the IDE "catches up".

Double clicking on the error to find it, and removing the offending code, fixes it.

Otherwise, you can, try this in Visual Studio:

Menu Project ? <Project name> Properties ? Build ? button Advanced ? Language Version ? C# <latest minor version> (e.g. "C# 5.0")

And that fixes it too.

It looks like "Metadata file '.dll' could not be found" is often a symptom of some other underlying problems, so if none of the top solutions work for you, check other errors and warnings and try to find the real issue.

I got the same error using Visual Studio 2019. After a closer look on what was going on in the background i found out there were errors on appended class libraries which in turn were not compiling correctly and throughing at the same time the error "Meta data file not found". Corrected the errors, compiled it again and all worked.

In my case the answer was found on analysis of the output tab.

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 faced this problem. In my case multiple C# projects were referenced as DLL files. Any compile time error in a project which is used as a DLL file (in other projects) would result in a flood of errors. The reason is, the compile time error prevents the creation of the corresponding DLL file, and this results in a series of errors in projects which refer to the missing DLL file.

Therefore when you rebuild in Solution Explorer (ignoring the trivial compile time errors), a bunch of "metadata file .dll could not be found" errors will occur (making you think what wrong you did other than a simple rebuild).

If you are facing this problem, then the best solution is to clean the solution and then build each project one by one to figure out which project is initiating the error.

My issue came when i wrote c# 7 code but the project was using older version for .net framework

A lot of these answers sound like trial and error. In my case though, it was simple: the referenced dll was not found in that particular location.

If you see the build errors, typically in this case, the build complains about many dlls. The key is to find the right dll that is missing. In my case, one of the projects in my solution had a direct dll reference instead of a project reference. So, I needed to build the project that outputs that dll before building the failing solution to make sure the failing solution finds the missing dll in that particular location.

Wow.. that was simple, but quite difficult to put it into words.

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.

In my case I had this error because, one of my project used a different .NET framework version from the others of the solution. I used the NuGet packages manager to install NLog, so, i think, it installed for the .Net version of this project.

I tried all solutions from this post, but none were working. I removed NLog, cleaned the solution and trid to compile: Same thing, CS006 error.

It was when I deleted all files in obj\Debug from this project that the solution compiled.

As user @burzhuy points out, it can be important to look at the Outputwindow, and not just the Error List window.

In my case I was working on making modifications to the Roslyn compiler. Its build projects run an extra check to see if the public fields are consistent with what has been defined as the compiler's public interface, otherwise it produces an RS0016 or RS0017 error. I had added a couple of public fields, and fixed the RS0016 error by hovering the mouse over the error and selecting "Add to public API".

Later I changed my mind and moved the public fields to a different class. For some reason this produced the "Metadata file could not be found error", and the more I fiddled with it the more errors I got.

You need to to find the correct PublicAPI.Unshipped.txtfile (in my case it was in E:\Roslyn\32414\src\Compilers\Core\Portable) and edit it manually to remove the lines that are no longer relevant.

In my case, I deleted the git folder and removed Git (Azure DevOps). This was the only method that I did that worked.

I tried clean, rebuild, reconfigure build, deleting bin and obj folders; nothing worked. When I removed solution of Git, voilá! It worked for me.

I don't understand, but this solved it for me.

When I did a build, it would usually show errors like this in Visual Studio 2017:

Error   CS0006  Metadata file 'C:\src\ProjectDir\MyApp\bin\x64\Debug\Inspection.exe' could not be found MyApp   C:\src\ProjectDir\MyApp\CSC 1   Active

But sometimes an error like this would show for a couple seconds and then it would disappear and switch back to the above message:

Error   CS1503  Argument 1: cannot convert from 'MyApp.Model.Entities.Asset' to 'MyApp.Model.Model.Entities.Inspection' MyApp   C:\src\ProjectDir\MyApp\ViewModels\AssetDetailsViewModel.cs 1453    Active

So I spent time troubleshooting the first error but the real problem turned out to be due to the second error. First I had to delete all the /bin and /obj directories, then I also deleted the .suo files as indicated above. This allowed me to narrow down the problem to an interface issue.

In my interface I had this:

    Task<IList<Defect>> LoadDefects(Asset asset);

But in my actual implementation I had this code:

    public virtual async Task<IList<Defect>> LoadDefects(Inspection inspection)
    {
       var results ...
       // ....

        return results;
    }

The build completed successfully after I updated the interface to this:

    Task<IList<Defect>> LoadDefects(Inspection inspection);

So it seems like caching in VS caused it to keep showing the CS0006 error when the actual problem was the CS1503 error.

Closing and reopening Visual Studio 2013 worked for me!

I am running Visual Studio 2013.

It appears that the build dependencies were incorrect. Deleting the *.suo files did fix the problems I had.

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.

I started having this problem after changing the solution a lot, shelving the changes and undoing it.

Only way to solve it was removing and adding again the mapping from TFS to my local folder.

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.

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.

For me the problem was an error that didn't come up in the build output, namely I had two utility classes that were in different namespaces initially. I changed the namespace of the second one to match the first one's (without knowing there was another one utility class in the first one), and that's when this error started to come up.

I imagine the build output error surfaced, because the Logic Layer library DLL file could not be built, and the main application couldn't find it.

The solution was to change back the second utility class to a different namespace and that's when the real build errors started to pour in. After sorting them out the build went through just fine.

As an overview, if any of the previous solutions doesn't work for you, you might have suppressed errors in the code that Visual Studio is not showing, so try to retrack your coding steps and check for any irregularities.

PS: This was in Visual Studio 2015 Community Edition

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 it was caused by a .NET Framework version mismatch.

One project was 3.5 and the other referencing project 4.6.1.

The cause of the problem may be that you have mixed adding references to DLL files and projects in the solution.

If you have projects A, B, and C:

• A references B and C as projects in the solution.
• B references C as a DLL file (reference to a file)

You can build each project separately, but you can't rebuild a solution ending with: Metadata file 'C.dll' could not be found.

Changing the reference from a file to a project in the solution helps.

I had an quite unusual case of this error, but maybe someone would benefit from it.

I had this error with missing .dll file of one of projects in solution (with target framework netstandard 2.0) I'm working on and at once error with reference (to Microsoft.Office.Interop.Word) this project uses.

This solution was cloned from git repository, and same solution compiled well for other people in my team.

I tried every propsed solution for issue - restarting VS, computer; cleaning project; checking and unchecking build checkboxes; checking if build order is proper etc.

I figured out that manifest of this project was not selected by default (dropdown of manifest in project properties was empty and disabled). Therefore I tried to add it, but nothing worked.

At last I started comparing this project .csproj file with one in other, older version of this project, which compiled without problem. After a bit of usless tries I figured out, that path to Microsoft.Office.Interop.Word is the same in both projects, even thought it was a relative path starting with lots of "go up" symbols ( ..\ ). And not working project was one level lower than other.

Adding one more "go up" symbol ( ..\ ) in reference path to Microsoft.Office.Interop.Word inside project .csproj file solved the issue.

I have no idea why this path was created that way and doesn't update in my case, while it work properly for others in my team.

For me the issue was that I had two Visual Studio windows opened, my project was running in debug in one window, and I tried to build it in another.

I had to stop debugging and then it let me build successfully.

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

I had the same issue in VS2019. Here is what you need to do:

1. Push latest changes on some branch
2. Delete the project
3. Remove project from QuickStart - you can try to reference not existing project and it will ask you to remove
4. Clone the project
5. Run the project

In my case, I had a bunch of other build errors as well (some simple type conversions) along with this one, I was scratching my head trying to solve this, and I wasn't focusing on the other errors.

What finally solved my problem was that I fixed all the other build error and then I build again and it build successfully.

So in case you have other build errors along with missing DLL file error, and nothing else is working for you then try to fix the other errors first and then build the solution again.

For me it was an unused import "using ApsNetCore" on a Controller. Removed it, clean, rebuild it and it worked.

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 saw this error because I had the following line in my code (looks like I was still thinking in SQL mode):

if(myVar is null)
    DoSomething();

Visual studio (2017) reported no errors at design or compile time however the project would not build and gave the "missing .dll" error. Upon changing the erroneous line to:

if(myVar == null)

The problem was resolved.

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

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.

For me the following steps worked:

• Find the project that is not building
• Remove/add references to projects within the solution.

In my case it was that the dependor project (the project depending upon the one in the error message) was missing values in its "Assembly version" fields under the project's "Properties ? Application ? Assembly Information...". I just added in the same numbers which were there for "File version", clicked "OK" and the compiler errors disappeared!

It turns out that re-adding the AssemblyVersion then building the project again resulted in another error claiming that it was already present in the project. It was! Under the properties node of the project in Solution Explorer, there was a "SolutionVersionInfo.cs" file which also contained an AssemblyVersion attribute - deleting this file from the project resolved this error.

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

This error may be shown if you use fake assemblies. Removing fakes leads to successful build of the project.

In my case it happened to me when I was referencing NuGet packages locally and moved their directory to somewhere else, I changed the path inside NuGet.Config but unfortunately I discovered that I should change the .csproject files manually to update the reference path, but the error message CS0006 was way far from describing this problem. Generally it also happens when there is a reference to DLL that couldn't be found, to be able to identify issue search your references in the project with the problem you will find some references with warning icon associated with them, try fixing those and it should work as expected.

for me the problem occurred because I was in-lining variable.

so the following does successful build:

ReportCategory reportCategoryEnum;
Enum.TryParse(reportCategory, true, out reportCategoryEnum);

while when I modified my code as following, no errors were shown but build was failing

Enum.TryParse(reportCategory, true, out ReportCategory reportCategoryEnum);

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 I got this error message for the simple reason that, after getting the latest version of the project from TFS, the wrong project in the solution was marked as the startup project. Choosing the correct project as the startup project solved this for me.

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.

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.

Very strange! I tried all the previous answers and unfortunately nothing worked in my case.

I encountered two errors:

1. Missing .dll file
2. Method already defined at another place with the 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 it on its own.

I want to say, if you have more than a single error along with the .dll missing file error, please try to solve the other errors first. Maybe the .dll error solves it on its own!

None of the previous solutions worked for me so I'll share what did.

I had this problem after merging some new class libraries from another branch which referred to each other. Deleting the references in the projects and recreating them finally fixed the problem. Apparently Visual Studio had merged over the wrong file paths.

In my case, setting the target framework solved the problem:

1. Right click on the project and select Properties

2. In Application, change Target framework to the same as the main project (e.g. ".NET Framework 4.5").