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

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.

The suggested answer did not work for me. The error is a decoy for another problem.

I found out that I was targeting a slightly different version of .NET and this was flagged as a warning by the compiler, but it was causing building to fail. This should have been flagged as an error and not a warning.

Well, my answer is not just the summary of all the solutions, but it offers more than that.

Section (1):

In general solutions:

I had four errors of this kind (‘metadata file could not be found’) along with one error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.

I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs, etc. and found these solutions may be effective (summarizing them over here):

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.

In my case it was caused by a .NET Framework version mismatch.

One project was 3.5 and the other referencing project 4.6.1.

Closing and reopening Visual Studio 2013 worked for me!

Well, nothing in the previous answers worked for me, so it got me thinking about why am I clicking and hoping when as developers we should really try to understand what is going on here.

It seemed obvious to me that this incorrect meta data file reference must be held somewhere.

A quick search of the .csproj file showed the guilty lines. I had a section called <itemGroup> that seemed to be hanging onto the old incorrect filepath.

<ItemGroup>
    <ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
        <Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
        <Name>Beeyp.Entities</Name>
    </ProjectReference>
...

So a simple fix really:

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.

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.

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 also met this problem. Firstly you have to manually build you DLL project, by right-click, Build. Then it will work.

I got the same error "Metadata file '.dll' could not be found", and I tried several things described above, but the reason for the error was that I was referencing third-party DLL file which was targeting a .NET version higher that my project target .NET version. So the solution was to change the target framework of my project.

I added a new project to my solution and started getting this.

The reason? The project I brought in was targeting a different .NET framework (4.6 and my other two were 4.5.2).

For me, it was trying to find a DLL in a path that used to contain the Project, but we'd moved it to a new directory. The Solution had the correct path to the Project, but Visual Studio somehow kept looking in the old location.

Solution: Rename each problem Project - just add a character or whatever - then rename it back to its original name.

This must reset some global cache of some kind in Visual Studio, because this clears both this issue up and several like it, while things like Clean do not.

In my case, the problem was caused by a simple build error,

> error CS0067: The event 'XYZ' is never used

that, for any reason, did not show up in the error window.

Because of that, the Visual Studio build system seemed to miss the error and tried to build dependent projects, which in turn failed with the annoying metadata message.

The recommendation is -as stupid as it may sound-:

First look at your Output Window!

It took me half an hour before this idea hit me...

It looks like such kind of errors related to the fact that Visual Studio doesn't provide correct information about an error. The developer doesn't even understand the reason for the failed build. It can be a syntax error or something else. In common, to solve such problems you should find the root of the problem (for example, look at the build log).

In my case the problem was in fact that the Error List window didn't show any errors. But really there were syntax errors; I found these errors in the Output window, and after fixing them, the problem was solved.

For me it occurred when I included a new project to a solution.

Visual Studio automatically selects .NET framework 4.5.

I changed to version .NET 4.5.2 like the other libraries, and it worked.

For me the following steps worked:

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

I was pulling my hair out with this problem also, but after trying the previous answers the only thing that worked for me was to open each project in my solution 1 by 1 and build them individually.

Then I closed Visual Studio 2013, reopened my solution and it compiled fine.

It's strange, because if I clicked each project in my Solution Explorer and tried to build them that way, they all failed. I had to open them alone in their own solutions.

Coming back to this a few years later, this problem is more than likely related to the Windows maximum path limit:

Naming Files, Paths, and Namespaces, Maximum Path Length Limitation

In my case the 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.

My instance of the problem was caused by a common project that had a duplicate class name in it (under a different filename). It is strange that Visual Studio could not detect that and instead just blew up the build process.

I got this problem in Visual Studio 2012 in a solution that had many projects. Rebuilding each project in the solution manually in the same order as the Project Build Order (right-click and rebuild in Solution Explorer) fixed it for me.

Eventually I got to one that gave me a compile error. I fixed the error, and the solution would build correctly after that.

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.

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.

I too had the same error. It hides as in the below path. The path which I referred to for the DLL file is like "D:\Assemblies Folder\Assembly1.dll".

But the original path in which the assembly referred was "D:\Assemblies%20Folder\Assembly1.dll".

Due to this path name variation, the assembly could not be retrieved from its original path and hence throws the "Metadata not found" error.

The solution is in Stack Overflow question How do I replace all the spaces with %20 in C#?.

I'd faced the same problem. In my case I'd referenced to a class library project with higher .Net version than my project and VS failed to build the project and raised the same error you posted.

I simply set .Net version of my class library project(the one that had broken the build) identical to the .Net version of referenced project and problem solved.

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 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 error may be shown if you use fake assemblies. Removing fakes leads to successful build of the project.

I am running Visual Studio 2013.

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

Just pointing out the blatantly obvious: if you don't have "Show output window when build starts" enabled, make sure you're noticing if your build is failing (small "build failed" error in lower left)!!!!

I had this error when I was trying to publish a web application. Turned out that one of a class properties was wrapped into

#if DEBUG
    public int SomeProperty { get; set; }
#endif

but the property usage was not. The publishing was done in Release configuration without the DEBUG symbol, obviously.

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

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:

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 class in 4.6.1 refering an interface that was in 4.6.2... upgrading the class to 462 fixed it.

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.

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

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.

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

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.

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.

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.

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

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

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.

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

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

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

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.

In Visual Studio 2019:

• Close Visual Studio.
• Delete the .vsccc file that lives in the same folder as your solution file.
• Open the solution and rebuild.

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

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

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.

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.

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.

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.

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

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

I'd faced the same problem. First i cleared all nuget cache from tools>Nuget Package Manager>Package Manager settings then click "Clear All Nuget Cache(s)". After this opened Powershell and run "dotnet restore" then "dotnet build". In my case this solution fixed my errors.

in my case: go to add references. in reference manager window uncheck dll project for other projects. save it. again add reference dll project to other projects.

I hit and solved this problem today on VS2022 in a solution with a Blazor project.

The underlying problem is that I had introduced a routine C# compilation error in C# code declared in a .razor file. VS2022 was dropping the display of the error from the Build Error List tab. I found the C# error by scanning the build output in the Output console log tab where my C# error was described as expected.

p.s. In case you are wondering, I had a Unit Test project referencing my Blazor web project. The project DLL reference from the Unit Test project to the Blazor app was complaining about the missing Blazor DLL.

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!

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

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.

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.

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

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

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

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

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.

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.

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.

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.

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 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"/>

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!

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.

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

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.

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

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.

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

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.

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!

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

Nothing else here worked for me, but this did:

1. Stash changes with Git
2. Clean and build
3. Apply stash
4. Rebuild

Now, suddenly VS pointed me to an error that wasn't showing up before. Furthermore, there were several errors in that one file that intellisense was ignoring. I corrected those without the help of red underlines and then was able to successfully build.

I'm using VS 2019. Our group is supposed to upgrade from 2017 to 2019.

Actual solution

I tried to clone to a folder on my C: drive that was part of my roaming profile (so on the network). I created a local folder that was guaranteed to be untracked and cloned there instead. The issues went away.

Notes:

• This could not have been a path-length issue because I also tried cloning it into a folder with a name longer than the original path, and it built fine.
• This could not have been due to spaces in the file name because our solution folders have spaces in them.
• This issue seems to only affect VS2019 and not VS2017. Though we have run into roaming profile issues before, it used to happen when we tried to sync with Git, not build.

Other things I tried/checked to no avail

• Restart VS, logout, restart, etc.
• Delete solution and re-clone from DevOps repo
• No Build Errors in our code
• Uncheck and re-check Build Configuration boxes
• Build-order makes sense
• All .NET Framework Targets the same. (In my case 4.6. Probably doesn't matter.)
• DLLs actually exist in path
• Reload project
• Reinstall NuGet Packages
• Re-add DLLs

Case Sensitive

In my case the error message was as follows

> Severity Code Description Project File Line Suppression State Error The command ""C:\Program Files (x86)\Microsoft SDKs\Windows\v10.0A\bin\NETFX 4.6.1 Tools\gacutil.exe" /i "C:\Users\cmaggiul\source\repos\consume-evalue-api\EValueApi\EValueApi\bin\debug\EValueApi.dll"" exited with code 3. EValueApi

I followed the path to the EValueApi.dll file and realized that the debug directory was capitalized in Windows. I changed the directory to be lower case ( to match the location being used by gacutil.exe and it resolved my issue.

In my case, I had a reference to another project which I deleted but I never used it in the code and therefore I didn't get any compilation errors.

Tip: Check if you have any references to other projects in your solution which do not exist.

Working with a Blazor WebAssembly ASP.NET Core hosted app, this problem arose when I deleted the WeatherForecast model and this caused a build error that wasn't visible as an error.

If this is the case for you, just remove the FetchData.razor file, and you'll be good to go!