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.
Comment: 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..
Comment: 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.
Comment: possible duplicate of [Metadata file '...\Release\project.dll' could not be found in Visual Studio](http://stackoverflow.com/questions/898559/metadata-file-release-project-dll-could-not-be-found-in-visual-studio)
Comment: 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!
Comment: 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.
Comment: 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.
Comment: The solution to similar question http://stackoverflow.com/questions/20490857/visual-studio-getting-error-metadata-file-xyz-could-not-be-found-after-edi worked for me.
Comment: 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.
Comment: Something else to try, I fixed all the other errors in the solution and this problem went away.
Comment: 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.
Comment: One of my projects was unloaded. Right clicking to reload in Solution explorer worked.
Answer: I just had the same problem. Visual Studio isn't building the project that's being referenced.
Written Instructions:

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

Screen capture Instructions:

They say a picture is worth a thousand words. Click on the GIF to zoom in, and hopefully it will be easy to follow:
Comment: 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
Comment: 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.
Comment: 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
Comment: 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.
Comment: 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)
Comment: 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  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 ;)
Comment: doing so leads me to an IL merge issue (ilmerge exited with code 1)
Comment: 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.
Comment: 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
Comment: 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.
Comment: Isn't this supposed to be automatically set when you add a project reference?
Comment: 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!
Comment: For me I needed to update the Target framework(properties -> applictaion tab).  Then the .dll was being created.
Comment: 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
Comment: 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.
Comment: Doesn't work. All projects already checked for build, and unchecking, saving, checking again, saving doesn't help, either.
Comment: 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.
Comment: Just update all reference package from nuget package manager.After that just restart Visual Studio.
Comment: 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.
Comment: 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.
Comment: 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.
Comment: 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.
Comment: If you have wcf in your project, clean the solution, update their references and Rebuild solution. Restart VS. That fixed my problem!
Comment: 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.
Comment: 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
Comment: it was the solution for me too.  i was getting error like this "metadata file '' could not be found" It doesn't give the file name either.
Comment: Make sure to apply after each check. Unchecking and checking all projects and then applying did not work for me.
Comment: If this doesn't work straight away, consider restarting Visual studio after doing it.
A little heads up, before I restarted my visual studio, I had made some changes, after the restart, I noticed my last few changes were gone, so you might want to copy your changes somewhere temporarily or save them with git
Answer: 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.
Comment: 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`
Comment: 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.
Comment: 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.
Comment: 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
Comment: 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.
Comment: I had it happen on VS 2015 update 3 and Matt's solutions worked for me.
Comment: I am using VS2017RC and deleting the .suo file in the hidden top level .vs folder worked for me!
Comment: Thanks a lot. This solved this problem for me on VS 2013, after struggling with it for almost an hour
Comment: In VS2017 the `.suo` has the same path as in @Wyck 's comment. Altough, yours may be in a v15 folder and not v14.
Comment: Closing and opening visual studio helped me. Thanks
Comment: 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.
Comment: This worked for me with VS 2019 Community Ed.
Comment: Worked for me. I am using VS 2019
Answer: 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.
Comment: 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.
Comment: 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.
Comment: 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.
Comment: 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.
Comment: 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**.
Comment: 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.
Comment: I concur.  I had a project dependency on a 4.7.2 Framework by a 4.8 Framework project.  No error identifying this dependency fail was thrown.
Comment: if you try to open a solution which references to any .NET 6 Or .NET 7 projects in Visual Studio 2019, this error will appear, opening in VS 2022 Fixed it, thank for your answer.
Answer: Well, my answer is not just the summary of all the solutions, but it offers more than that.
Section (1):
In general solutions:
I had four errors of this kind ('metadata file could not be found') along with one error saying 'Source File Could Not Be Opened ('Unspecified error ')'.
I tried to get rid of 'metadata file could not be found' error. For that, I read many posts, blogs, etc. and found these solutions may be effective (summarizing them over here):

Restart Visual Studio and try building again.
Go to 'Solution Explorer'. Right click on Solution. Go to Properties. Go to 'Configuration Manager'. Check if the checkboxes under 'Build' are checked or not. If any or all of them are unchecked, then check them and try building again.
If the above solution(s) do not work, then follow sequence mentioned in step 2 above, and even if all the checkboxes are checked, uncheck them, check again and try to build again.
Build Order and Project Dependencies:
Go to 'Solution Explorer'. Right click on Solution. Go to 'Project Dependencies...'. You will see two tabs: 'Dependencies' and 'Build Order'. This build order is the one in which solution builds. Check the project dependencies and the build order to verify if some project (say 'project1') which is dependent on other (say 'project2') is trying to build before that one (project2). This might be the cause for the error.
Check the path of the missing .dll:
Check the path of the missing .dll. If the path contains space or any other invalid path character, remove it and try building again.
If this is the cause, then adjust the build order.

Section (2):
My particular case:
I tried all the steps above with various permutations and combinations with restarting Visual Studio a few times. But, it did not help me.
So, I decided to get rid of other error I was coming across ('Source File Could Not Be Opened ('Unspecified error ')').
I came across a blog post: TFS Error–Source File Could Not Be Opened ('Unspecified error ')
I tried the steps mentioned in that blog post, and I got rid of the error 'Source File Could Not Be Opened ('Unspecified error ')' and surprisingly I got rid of other errors ('metadata file could not be found') as well.

Section (3):
Moral of the story:
Try all solutions as mentioned in section (1) above (and any other solutions) for getting rid of the error. If nothing works out, as per the blog mentioned in section (2) above, delete the entries of all source files which are no longer present in the source control and the file system from your .csproj file.
Comment: 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.
Comment: Removing "%" from referenced dll path helped me
Comment: I faced this problem by down-grading `.NET v4.5` project to `.NET v.4`.
Comment: 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.
Comment: The solution in Section 2 worked for me! I had another error and when I fixed that the others magically dissappeared.
Comment: 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.
Comment: 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
Comment: @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.
Comment: @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.
Comment: 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.
Comment: 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.
Comment: @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.
Answer: 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.
Comment: Yes, seems any time a framework version is different, this happens. Great error Microsoft!
Comment: This also happens between 4.5.2 Vs. 4.6
Comment: Indeed, I had one of 4.6.1 and the rest was 4.5.2, thanks!
Comment: 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
Comment: 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.
Answer: Visual Studio 2019 this worked for me:

Close Visual Studio
Delete the hidden .vs folder
Reopen Visual Studio and rebuild the solution.
Comment: Using MAUI here, this did not directly fix the error but it helped. I had renamed a class without refactoring and one of my Views could not find it anymore. I could not see the relevant error in the Output log when I compiled. In order to see the right error in the Output log, I had to: 1. Close Visual Studio 2. Delete the `.vs` folder in the repo 3. Reopen Visual Studio and compile. This highlighted the view's unknown type reference error in the Output window (but it still didn't appear among the Errors)!
Comment: Not working for me
Comment: This one worked
Comment: This worked for me.
Answer: Closing and reopening Visual Studio 2013 worked for me!
Comment: In my case, I also opened another project and then the original.
Answer: 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:

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

Please make sure you backup your old .csproj before you fiddle.
Comment: please MAKE SURE YOU USE VERSION CONTROL BEFORE YOU DO ANYTHING
Answer: In my case, it was an issue with my directory names.
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.
When a repository is cloned from certain sites, the directory name is URL encoded. Which would convert space characters in directory names to %20, forward slashes to %2f, underscores to %5f, etc. Although, I'm not sure why the % symbol is breaking things.
Renaming the path into one with valid characters resolved my issue. This can be done manually in the File Explorer. In my case, I just removed the %2cs.
Comment: that helped me, git extensions changed '.' to %20
Comment: @Gabriel Petersen, I agree with you. I had cloned a project from Git on AzureDevOps and it added %20 where there's spaces in a project directory name. So rename the directory and it should work.
Answer: I also met this problem. Firstly you have to manually build you DLL project, by right-click, Build. Then it will work.
Comment: 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.
Comment: 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`!
Answer: 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...
Comment: Exactly. I had a similar error. I found out it was related to an error in a dependant project that prevented a successful build.
Answer: 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.
Comment: 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.
Answer: 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.
Answer: 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).
Comment: 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
Comment: 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.
Answer: 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
Comment: Which is...? 260? Or slightly less (in practice)?
Comment: Not sure if this was the case. I tried top solution but that didn't work. I copied all code to parent folder to shorted the path (220 characters), reduced to 192 characters with it worked fine.
192 is longest path I can see in solution solution/obj/debug/net6.0/ref/ abc.xyz.dll
Answer: 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.
Comment: I experienced this problem as well. There was no error in the Error List, but the failed build results in DevOps showed the error
Answer: 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.
Answer: For me the following steps worked:

Find the project that is not building
Remove/add references to projects within the solution.
Comment: 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
Answer: 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.
Comment: Ugh, this. So many things Microsoft require a restart to work again.
Answer: 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.
Answer: 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.
Answer: 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.
Comment: 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.
Answer: 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.
Comment: 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.
Answer: 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.
Answer: 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#?.
Answer: 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.
Comment: Same problem, but on "Manage Packages for Solution" > Consolidate nothing was shown, I had to check the installed one by one. In my case: Microsoft.EntityFramework.*
Answer: 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.
Comment: Had the same problem after adding an additional parameter to a function which was called in a .razor-file. VS did not show me the error until I manually got into the razor-file and saw the red underlinings.
Comment: Same here, only using MAUI. However, I could not see the relevant error in the Output log. In order to see the right error in the Output log, I had to: 1. Close Visual Studio 2. Delete the `.vs` folder in the repo 3. Reopen Visual Studio and compile.
Comment: I had the same problem. A dublicated function in a partial class. Had to read the output to find the file in which the error was thrown.
Answer: 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?
Comment: I dunno how as I haven't changed anything and don't have any custom build events or configurations
Answer: 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.
Answer: This error may be shown if you use fake assemblies. Removing fakes leads to successful build of the project.
Comment: What is a "fake assembly"? Can you elaborate? (Respond by expanding your answer.)
Answer: I am running Visual Studio 2013.
It appears that the build dependencies were incorrect. Deleting the *.suo files did fix the problems I had.
Answer: 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)!!!!
Comment: 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.
Answer: 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.
Answer: 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?)
Answer: 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:
Answer: 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.
Answer: I had a class in 4.6.1 refering an interface that was in 4.6.2... upgrading the class to 462 fixed it.
Answer: 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 to restore al packages and projects
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
Answer: For me it is still a "feature" in the current version of VS2022.

Building all ~80 projects of a solution
Cancelling the build in the middle
Unloading ~70 projects and doing a rebuild all

causes the error. Fix:

Reload all projects
Rebuild all up to the end
then do the unload

and a rebuild all succeeds without that metadata error
Answer: I received this error after opening a project in which Entity Framework was referenced, so I deleted such references, and reinstalled Entity Framework version 126.96.36.199 through pthe acket manager this way:
install-package entityframework -version 22.214.171.124

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.
Answer: 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.
Answer: 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.)
Answer: 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.
Answer: 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.
Answer: My issue came when i wrote c# 7 code but the project was using older version for .net framework
Answer: 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.
Answer: 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.
Comment: It's funny how this shows up as Page 2 solution to this problem but in my case this was the real problem.
Answer: 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.
Answer: 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
Comment: 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.
Comment: @AlexanderDerck Unload and Reload on the project did it for me. After trying a bunch of the answers here. Thanks for the tip!
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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>
  </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).
Answer: 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
Comment: 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).
Answer: 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
Comment: 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.
Answer: 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.
Answer: 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.
Comment: No files of that sort are in the same folder as my solution file.
Answer: 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.
Comment: I just had to run `dotnet restore xxx.sln` from a dev prompt due to nuget restore commad not picking up PackageReferences
Answer: 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!
Answer: Check that the project does not contain errors, otherwise the DLL cannot be generated
In my case, I had syntactic errors that were not visible from the Error List,
when I checked the Output tab line by line I found some errors in the cshtml classes
Answer:
Right click on the solution and click Clean.
Right click on the solution and click Rebuild.
Answer: I have found out that if you remove Microsoft.CSharp assembly as a reference in the project, you will get this error.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: I had the same issue in VS2019. Here is what you need to do:

Push latest changes on some branch
Delete the project
Remove project from QuickStart - you can try to reference not existing project and it will ask you to remove
Clone the project
Run the project
Answer: 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
Answer: 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!
Answer: 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.
Answer: For me it was an unused import "using ApsNetCore" on a Controller. Removed it, clean, rebuild it and it worked.
Answer: 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.
Answer: VS2022: Cause not found in the extensive listing already here.
Had a static class comprised entirely of static methods.  Removing static from the class declaration didn't raise either a compile error or warning but did cause the OP build error.
Reverted the class declaration back to static and fixed the problem.
Answer: Sometimes a local project is automatically referenced twice.
Check your .csproj file for something like this and remove one line:
  <ItemGroup>
    <ProjectReference Include="..\ReferenceProject\ReferenceProject.csproj" />
    <ProjectReference Include="..\ReferenceProject\ReferenceProject.csproj" />
  </ItemGroup>

Answer: Very strange! I tried all the previous answers and unfortunately nothing worked in my case.
I encountered two errors:

Missing .dll file
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!
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Comment: Can you provide another example of the value of "Language Version"?
Answer: In my case, setting the target framework solved the problem:

Right click on the project and select Properties
In Application, change Target framework to the same as the main project (e.g. ".NET Framework 4.5").
Answer: 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.
Answer: 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
Answer: 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" />.
Answer: 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
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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"/>

Answer: 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.
Answer: 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);

Answer: 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.
Answer: 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.
Answer: 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.
Answer: 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!
Answer: 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.
Answer: The framework version of the current project differs from remaining projects.
Change of framework version to existing projects version will resolve this.
Answer: Nothing else here worked for me, but this did:

Stash changes with Git
Clean and build
Apply stash
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.
Answer: 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.
Answer: 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
Answer: 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.
Answer: I was facing the same issue with my project, I added console application in a solution but those other solution was not working and showing .dll not found, so I tried this method:

Right click on the project which is having issue
Click on Application tab, that is default
Change output type Console Application to Class Library
Answer: I ran into this when doing a clean CLI rebuild of a MonoGame solution that had pure content projects.
The solution was to add a single dummy class file with an empty constructor to each of the content projects.
Answer: In my case, I mistakenly wrote #endregion twice. The problem was solved when I deleted one.
Answer: This might also be caused by the fact that you have multiple projects in your solution but different projects target different versions of .net framework.
Answer: The issue for me was that someone had copied the source project into the project, added a project reference to debug an issue and then re-added the NuGet package without removing the project reference!
This actuall built on some dev machines and failed on others, depending on if it tried to use the NuGet package or the project.
Manually editing the project files to delete the project references resolved the issue.
Answer: For me I checked the warnings not errors and noticed something wrong with one .dll in a bin folder.
I deleted that bin folder, Clean solution, Rebuild, all works now.

Metadata file '.dll' could not be found


Running Specific TestNG Groups from Maven

Question: I have 2 groups of test cases as mentioend below.
@Test(groups="one", dataProvider = "TestData")
public void firstTest(String data){
   //Code
}

@Test(groups="one", dataProvider = "TestData")
public void secondTest(String data){
   //Code
}

@Test(groups="two", dataProvider = "TestData")
public void thirdTest(String data){
   //Code
}

Below is the XML file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">

<suite name="Test-Automation" parallel="methods" thread-count="2" verbose="1">
    <test name="Suite Test" parallel="methods" thread-count="2" verbose="1">
        <listeners>
             <listener class-name="GroupByInstanceEnabler"></listener>
        </listeners>

        <classes>
            <class name="SampleTest">
                <methods>
                    <include name="firstTest"/>
                    <include name="secondTest"/>
                    <include name="thirdTest"/>
                </methods>
            </class>
        </classes>
    </test>
</suite>

Below is the pom.xml build details.
 <build>
        <finalName>Automation</finalName>
        <filters>
            <filter>profiles/${build.profile.id}/config.properties</filter>
        </filters>
        <resources>
            <resource>
                <filtering>true</filtering>
                <directory>${basedir}/src/test/resources</directory>
            </resource>
        </resources>

        <plugins>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-compiler-plugin</artifactId>
                <version>3.7.0</version>
                <configuration>
                    <source>1.8</source>
                    <target>1.8</target>
                </configuration>
            </plugin>

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-surefire-plugin</artifactId>
                <version>2.20.1</version>
                <configuration>
                    <suiteXmlFiles>
                        <suiteXmlFile>${project.basedir}/testng.xml</suiteXmlFile>
                    </suiteXmlFiles>
                    <parallel>method</parallel>
                    <threadCount>2</threadCount>
                </configuration>
            </plugin>

        </plugins>
    </build>

My Question:
Using Maven, how do I run the group "one" and group "two" separately.
I tried "mvn test -Dgroups=two" but it only runs as normal(all tests).
Note: I use 2 different profiles to run the group "one" twice with different values. This is the reason you see profile configuration in the pom.xml file.
Answer: You can make use of a beanshell expression for getting this done.
You first add a beanshell expression as below to your suite xml file.
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE suite SYSTEM "http://testng.org/testng-1.0.dtd">
<suite name="Suite" parallel="false">
    <test name="Test">
        <method-selectors>
            <method-selector>

            </method-selector>
        </method-selectors>
        <classes>
            <class name="organized.chaos.GroupsPlayGround" />
        </classes>
    </test>
</suite>

This way you can make use of the suite xml from your IDE and still choose which groups to be executed. You can enrich this beanshell to run everything by default if no value is provided via the JVM argument -DgroupToRun=one
For more information on beanshell execution refer:

Official TestNG documentation here
My blog post link
Comment: It works great. Please do something to have your blog listed in the top of google search results :D :)
Comment: @krishnan, can you help me with my question of same topic here [link](https://stackoverflow.com/questions/63194956/no-engine-found-for-language-beanshell-while-running-testng-with-groups) please.?
Answer: I got an error - Undefined argument: whatGroup  : at Line: 2 : in file: inline evaluation of: ``whatGroup = System.getProperty("groupToRun");


Inverse/Implicit Function Theorem Reasons?

Question: I watched an ICTP lecture on elementary real analysis & the lecturer went to great
pains to emphasize the importance of the intermediate value theorem because it is
what generalizes to higher dimensions via connectedness & how Bolzano-Weierstrass
generalizes to metric spaces & how just a few results following from these are what
really matters. Regardless of how true that is (I think he's biased because he is a
functional analyst (analysist?)) I found that bit of intuition & motivation extremely
clarifying & I'd read a lot of links, wiki's etc... just looking for that kind of
motivation but it was nowhere to be found beforehand.
Similarly, I've read a lot about the implicit/inverse function theorems but I just
don't understand the reasons for putting so much focus on them, but that's because
I don't really know what they are saying & that's partly because I don't understand
what you need to know to really appreciate these theorems.
I guess what I'm asking for is an insightful & human explanation of what these theories
are, what you need to know to lead up to them, why you need to know that certain material & why these things are so powerful (for instance, I believe you can use these to prove the Lagrange Multipliers theorem, though I don't know why it has anything to do with it, I also know that knowing one means you can prove the other & that it doesn't matter which direction you approach from, but again I don't appreciate why that is).
I'm more interested in the surrounding theory, i.e. what you need to know, why you
need to know that & why it is so important, than what the theorem says so I'd much
rather prefer to have the motivation so that I could prove this myself.
(Yes I've read the wiki page, the threads on this site, the many articles apparently trying to motivate it, I just feel I haven't read anything that directly quells my aforementioned concerns so I think that justifies the thread).
Thanks for your time.
Answer: The inverse/implicit function theorem tell you when you can (locally) solve a system of equations.  This is incredibly important whenever you want to study a nonlinear problem -- e.g. differential geometry, PDE, etc.  In the following I will call both of them "implicit function theorem", since they are the same thing, really.
Let me give an example: suppose you are in the plane, and want to solve for $x^2 + y^2 = 1$.  You found a solution by inspection ($x = 1, y = 0$, say).  Let's let $F(x,y) = x^2 + y^2 - 1$.  This is $F: \mathbb{R}^2 \to \mathbb{R}$.
You have a solution $F(1,0) = 0$ and want to understand $F(x,y) = 0$.
The implicit function theorem tells you to consider the derivative $dF(1,0) = (2, 0) \colon \mathbb{R}^2 \to \mathbb{R}$.  This linear map is surjective, so the implicit function theorem tells us that there is a small neighbourhood of $(1,0)$ so that if we restrict our attention to this neighbourhood, there is a solution space parameterized by the kernel of the linear map, i.e. by the vertical axis.  Furthermore, this describes all the solutions in this neighbourhood, and the solution space is tangent to this line at $(1,0)$.
In this example, we have used the implicit function theorem to tell us a lot about the circle.  We used it to say that the circle is 1-dimensional (at least near $(1,0)$), that the circle has a vertical tangent at $(1,0)$ and that near $(1,0)$, we don't have any accumulating branches getting closer and closer.
(i.e. we have ruled out something pathological like what happens if you take the union of the lines $x = 1/n$ and $x=0$.)
This is silly when we know what we are working with so specifically.  However, you can use the implicit function theorem to understand much more complicated situations ... e.g. consider $n \times n$ matrices.  Look at the matrices in here with determinant $1$.  What does that look like?  Using the implicit function theorem you can describe at least what it is tangent to at each point, and also that it is a "nice" space the way the circle is a nice space (I am trying to describe what is known as being a submanifold.)
Let me give a fancier example.  Consider a differential equation $(x',y') = (f(x,y), g(x,y))$.  Let's say that there are two rest points $p, q$ and you can find a trajectory connecting them by some method.  You may ask yourself if this is the only trajectory connecting the two points.  By using the implicit function theorem in infinite dimensions (on a Banach space), you have a tool to approach this problem.  Similar methods also sometimes work in studying certain PDE.
Often, you can't find a solution by inspection, but you know that the nonlinear problem you want to solve is of the form $F(x) = 0$, where $x$ lives in some suitable space.  Still, you can get some mileage from the implicit function theorem in this case.  It's much harder, so I will only give details if you are interested.  I suspect what I have written has already given enough to think about.
Surprisingly, the only thing you need to prove this key result is the understanding of the Banach Contraction Mapping Principle (and a good understanding of the fact that the first derivative at a point $p$ is the best linear map that approximates your nonlinear map near $p$).
Answer: These theorems are so fundamentally important because they say what you intuitively think should be true, is actually true. I shall explain this for the implicit function theorem; but you could give similar explanations for the inverse function theorem or for the rank theorem.
Assume, e.g., than three physical quantities like $p$, $V$, $T$ are related by a certain law $\Phi(p, V, T)=0$, where the left side is a complicated expression in the variables $p$, $V$, $T$. Counting "degrees of freedom" you have the impression that whenever values are given for two of the three variables the corresponding value of the third variable should be determined, even if you are not able to solve the equation $\Phi(p,V,T)=0$ explicitly for the third variable.
That's where the theorem on  implicit functions comes in: It not only guarantees under certain hypotheses that the values of, say, $V$ and $T$ determine the value of $p$, but that $p$ is actually a differentiable function $\phi(\cdot,\cdot)$ of $V$ and $T$, and it gives formulas for the partial derivatives ${\partial \phi\over\partial V}$, ${\partial \phi\over\partial T}$ that do not require the solution of $\Phi(p, V, T)=0$ for $p$ in variable terms.
Now the implicit function theorem (as well as the other theorems mentioned) is only a local theorem. This means that you need a feasible point $(p_0,V_0,T_0)$ to start with, and the graph of the function $\phi: (V,T)\to p:=\phi(V,T)$ is only defined in a small box with center $(p_0,V_0,T_0)$. In addition there is a certain "technical condition" which I won't explain here. It excludes cases like the equation $x+y^2=0$ which does not define $y$ as a good function of $x$ in the neighborhood of $(0,0)$.
Answer: Try the Krantz-Parks book
The implicit function theorem: History, theory, and applications.
See also What is the Implicit Function Theorem good for? at MO.
Comment: the book is excellent.
Answer: Suppose $f:\mathbb{R}^m\to\mathbb{R}^n$ is a smooth map. Recall that, at any given point $x \in \mathbb{R}^m,$ the derivative of $f$ is a linear map $D_x f: \mathbb{R}^m \to \mathbb{R}^n$ given by
$$ D_x f(\vec{v}) = \lim_{t\to 0} \frac{f(x + t \vec{v}) - f(x)}{t}.$$
Recall that, even when $f$ is not invertible, for any given point $y \in \mathbb{R}^n,$ we may still define the preimage $f^{-1}(y)$ to be the set of all points $x \in \mathbb{R}^m$ such that $f(x) = y.$
We say that a point $y \in \mathbb{R}^n$ is a regular point when for every point $x \in f^{-1}(y),$ $D_x f$ has full rank. In particular, if $m > n,$ this implies that $D_x f$ is surjective. Whenever $D_x f$ is surjective, we say that $f$ is a submersion at $x.$
Local Submersion Theorem: If $f$ is a submersion at $x,$ then there are local coordinates $(\tilde{x}_1,\ldots, \tilde{x}_m)$ around $x$ such that $f(\tilde{x}_1,\ldots,\tilde{x}_m) = (\tilde{x}_1,\ldots,\tilde{x}_n).$
Preimage Theorem: If $y \in \mathbb{R}^n$ is a regular point, then $f^{-1}(y)$ is a smooth $(m-n)$-dimensional submanifold of $\mathbb{R}^m.$ That is, $f^{-1}(y)$ is locally homeomorphic (by a smooth invertible map) to $\mathbb{R}^{(m-n)}.$ That is, up close, $f^{-1}(y)$ looks just like $\mathbb{R}^{(m-n)}.$
The proof of the local submersion theorem depends critically upon IFT. In turn, the proof of the preimage theorem depends critically upon the local submersion theorem.
Transversality and intersection theory---as given in, for instance, Guillemin and Pollack's classic Differential Topology---depend critically upon the preimage theorem. These tools are very useful; they can be used to prove the Borsuk-Ulam theorem and the fundamental theorem of algebra, and they are essential tools for the development of Lefschetz fixed point theory and the nebula of results called the "Poincare-Hopf index theorem." The Poincare-Hopf index theorem, in turn, is used to prove the general Gauss-Bonnet theorem.


Is there no TFS Snapin for PowerShell on x64?

Question: I am trying to use the TFSSnapin in PowerShell from C# code using System.Management.Automation from the PowerShell SDK, however I would like to compile it using "AnyCPU". When I try debugging it in any CPU I get the "No Plugins Registered" error, I try debugging it in x86 mode and it works just fine. Is there anyway to get the Plugins registered on x64 PowerShell so I can use AnyCPU? Or am I just out of luck?
Answer: No.  And it can't be changed until TFS 2010 Beta 2 at earliest.  See: Why is the TFS Powershell snapin marked 32-bit only?
Answer: This is now possible
Execute the following line in your 64-bit PowerShell command prompt
copy
HKLM:\SOFTWARE\Wow6432Node\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.TeamFoundation.PowerShell
 HKLM:\SOFTWARE\Microsoft\PowerShell\1\PowerShellSnapIns\Microsoft.TeamFoundation.PowerShell
-r

Then add the PSSnapin for Microsoft.TeamFoundation.PowerShell.
Answer: Make sure you run the 64-bit version of InstallUtil to install the snapin info to the 64-bit registry (not the Wow registry node).  If you start a 64-bit Visual Studio Command Prompt, it should have the path configured to execute the 64-bit version of installutil.exe.
Comment: The TFS snapin in the TFS PowerTools was built for x86 only.  He's not recompiling the TFS PowerTools snapin.
Comment: I cannot use the 64 bit InstallUtil as it just says the dll is the incorrect format. It appears they only have 32 bit dll's so maybe I just cannot do it.
Comment: That's weird.  We build the PSCX snapin as AnyCPU and I'm able to register it and use it in a 64-bit Powershell prompt.
Comment: Oh I misinterpreted.  I thought he had source code for the snapin and was trying to do just that - recompile it to target Any CPU. Doh!


Xaringan: How do you change code chunk background color?

Question: Is it possible to change the background color--and other attributes--of code chunks? Is there a class associated with code chunks?
Modifying the background color for inline code is simple:
<code>.remark-inline-code{
  background-color: #000000
}
</code>
But I am unable to find an equivalent specifically for code chunks.
Answer: Inspecting the div using Chrome developer tools, you see that the color is set by class <code>.hljs-github .hljs</code>.
Setting
<code>.hljs-github .hljs {
    background: red;
}
</code>
should do what you want :)


How to enumerate through the DataTables of a DataSet starting at the second table in the collection using C#

Question: A for loop starting at index 1 is an obvious answer. I'm sure there are many other ways to do this. But what is the most readable way?
The question is using C# 4.0. LINQ is optional.
Answer: How about
dataset.DataTables.Skip(1)

Comment: DataTableCollection does not implement IEnumerable, so you can't apply the Skip extension method directly to it.
Answer: ds.Tables.OfType<DataTable>().Skip(1).ToList().ForEach(ACTION);

Comment: This one looks good. However it hink you need to specify the generic type in OfType. So that means ds.Tables.OfType.Skip(1). I also think depending on the ACTION, it's better to have it in a foreach(DataTable dt in...). What do you think?
Comment: you are right...It's actually in there, but the editor strips out anytinhg between angle brackets for some reason.  I'll try putting it in a code block.


Como não fazer o site bugar quando diminuo a tela e problema com botão subindo no CSS?

Question: Estou fazendo um teste e queria saber como não fazer a tela bugar, logo abaixo tem a página normal e ela quando a tela encolhe.

E eu estou com outro problema, eu queria dar um efeito do botão afundar quando pressionado, vi umas videoaulas, porém o meu botão quando ativo o evento active e coloco top:5px; ele sobe como na imagem abaixo.

Código HTML
<code>    <div id="moldura"><!--Essa div serve para os slides também-->
    <input id="bt1"  type="button" value="<" onclick="troca(-1)" />
    <input id="bt2" type="button" value=">"onclick="troca(1)"/>
    </div>
</code>
Código CSS
<code> #moldura{//Localização da Div do slide
width:600px;
height: 450px;
background-color: #eeeeee;
transition: background-image 2s;
position:relative;
top:460px;
left:350px;
     }

#bt1{//Botão 1
position: relative;
top:170px;
left:-20px;
font-size: 70px;
font-family: arial;
font-weight: 700;
border:none;
padding: 10px;
cursor: pointer;
background: black;
color: #fff;
box-shadow: 0 5px 0 #006000;
    }

#bt2{//botão2
position: relative;
clear:both;
top:170px;
left:500px;
font-size: 70px;
font-family: arial;
font-weight: 700;
border:none;
padding: 10px;
cursor: pointer;
background: black;
color: #fff;
box-shadow: 0 5px 0 #006000;
}

#moldura input:hover{
background: blue;
color: #fff;
box-shadow: 0 5px 0 #003f00;
}

#moldura input:active{
box-shadow: none;
top:5px;//Aqui era para acontecer o pulo do gato, era pra parecer que o
botao afundou, mas leva o botao la em cima como na imagem.
}
</code>
Answer: Quanto a sua primeira dúvida, tente colocar uma porcentagem para cada espaço.
Crie uma div para armazenar os textos e assim separar um tamanho em porcentagem.
Exemplo:
<code>#wrap{
    max-width: 100%;
}

#foto-f-society{
    width: 20%;
    margin: 0 10%;
}

#textos{
    width: 60%;
}
</code>
Já a segunda questão, da uma olhada nesse
Efeito Botao Click com CSS.
Answer: Criar sites que se adaptam ao tamanho da tela é um trabalho que na maioria das vezes dependem um esforço desnecessário
"Não é necessário reinventar a roda" - Claro que você já ouviu falar nisso e para tanto existem muitas soluções prontas para adicionar responsividade as suas páginas
Você pode utilizar frameworks css como bootrstrap, foundation, pure, semantic ui
Porém você já pode ter um site pronto e não quer código de terceiros bagunçando tudo que você já fez? Uma outra solução é utilizar sistemas de grids. Ex: http://www.w3schools.com/css/css_rwd_grid.asp


Can I use two different forms in one module?

Question: I'm new to Drupal 8 and I was wondering if I can use two forms which are inside the Form folder(mymodule/src/Form/). The name of my forms are FormOne.php and FormTwo.php.
I can only display and use FormOne.php through my entire module.
I have researched it and can't find an answer.
Can you help me on displaying the second form?
Answer: Yes, you can define as many forms in a module as you need.
If you want to include two forms into one page, you can do so by using the form builder in your controller to call both forms and build a render array.
Instead of using _form in your *.routing.yml file, you would instead use _controller, and define a controller callback rather than a form callback. Your controller would then be something like this:
class ExampleController extends Drupal\Core\Controller\ControllerBase {

  function examplePageCallback() {
    // Note - you should use dependency injection to inject this service,
    // rather than this method.
    $form_builder = \Drupal::service('form_builder');

    $return [
      'form_a' => $form_builder->getForm('Drupal\[MODULE]\Form\FormA'),
      'form_b' => $form_builder->getForm('Drupal\[MODULE]\Form\FormB'),
    ];
  }
}

Comment: Thank you for your response, @Jaypan. I asked this question because I noticed that the FormOne can only be used and display. It seems that I can't use and display FormTwo. Should I declare each form in the routing.yml?
Comment: If you want the form to be accessible at a route, yes, that is one way you can use the second form.
Comment: Is it possible to add both routes in the routing.yml?

`mymodule.display_form:`
`       path: '/mymodule'`
`      defaults:`
`                _form: '\Drupal\mymodule\Form\FormOne'`
`                _form: '\Drupal\mymodule\Form\FormTwo'`
Comment: You need to build a controller that returns a render array containing both forms in that case.
Comment: I've updated my answer.
Comment: @Jaypan, thanks for the update. I am planning to use each form in a separate page. Is it also possible?
Comment: Yes, in that case you would use the method Razeem has posted as an answer. His answer is how to have separate pages for each form. My answer is how to have two forms on one page.
Comment: Thank you for the solution. @Jaypan
Comment: You should mark his answer as correct, but give both of us an upvote for our answers. That's the custom here :) Welcome.
Comment: Sure @Jaypan, both answers are helpful. Thank you so much.
Comment: Thank you also @Kevin for the additional info
Answer: You can create a custom Form in MyCustomFormA.php
<?php

namespace Drupal\MY_MODULE\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

/**
 * Class MyCustomFormA.
 */
class MyCustomFormA extends FormBase {

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'my_custom_form_a';
  }
.....
}

Same way you can create another Form in MyCustomFormB.php
<?php

namespace Drupal\MY_MODULE\Form;

use Drupal\Core\Form\FormBase;
use Drupal\Core\Form\FormStateInterface;

/**
 * Class MyCustomFormB.
 */
class MyCustomFormB extends FormBase {

  /**
   * {@inheritdoc}
   */
  public function getFormId() {
    return 'my_custom_form_b';
  }
....
}

In your MY_MODULE.routing.yml
MY_MODULE.my_custom_form_a:
  path: '/MY_MODULE/my_custom_form_a'
  defaults:
    _form: '\Drupal\MY_MODULE\Form\MyCustomFormA'
    _title: 'My Custom Form A Form'
  requirements:
    _permission: 'access content'
MY_MODULE.my_custom_form_b:
  path: '/MY_MODULE/my_custom_form_b'
  defaults:
    _form: '\Drupal\MY_MODULE\Form\MyCustomFormB'
    _title: 'My Custom Form B Form'

  requirements:
    _permission: 'access content'

Comment: Thank you for your response, @Razeem. For the `MyCustomFormB.php`, should I also declare it on the routing.yml?
Comment: If you wan to display it in a specific page then yes
Comment: do you need `requirements` in each form. It gives me an 'HTTP ERROR 500'. I also tried to clear cache and it gives me the same error.
Comment: yes you may also add that
Comment: Thank you so much @Razeem
Comment: Welcome @JeirodAbogado.


Random "No input files specified" in Nginx and php-fpm

Question: I recently starts using Nginx with php-fpm. Everything seems alright except occasionally I am getting "No input file specified" and a 404 logged in the access.log. It appears random where one request getting an 200 while another request to the same file getting 404 with the above error. No related errors found in both Nginx and php-fpm error.log.
Here's an extract of the access.log:
10.0.0.5 - - [09/Aug/2011:18:14:27 -0400]  200 "POST /services/ChangeAccount HTTP/1.1" 110 "http://slotspot-internal.blitzoo.com/" "Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0" "18.104.22.168"
10.0.0.5 - - [09/Aug/2011:18:15:27 -0400]  404 "POST /services/ChangeAccount HTTP/1.1" 36 "http://slotspot-internal.blitzoo.com/" "Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0" "22.214.171.124"
10.0.0.5 - - [09/Aug/2011:18:15:28 -0400]  200 "POST /services/ChangeAccount HTTP/1.1" 110 "http://slotspot-internal.blitzoo.com/" "Mozilla/5.0 (Windows NT 5.1; rv:5.0) Gecko/20100101 Firefox/5.0" "22.214.171.124"

Have done some research and made sure the document root is defined in Nginx configuration server block and fastcgi_param  SCRIPT_FILENAME is defined as $document_root$fastcgi_script_name
Here's my nginx.conf:
user       nginx nginx;
worker_processes  5;
error_log  /var/log/nginx/error.log;
pid        /var/run/nginx.pid;
worker_rlimit_nofile 8192;

events {
  worker_connections  4096;
}

http {
  include    /etc/nginx/mime.types;
  include    /etc/nginx/proxy.conf;
  include    /etc/nginx/fastcgi.conf;
  index    index.html index.htm index.php;

  default_type application/octet-stream;
  log_format   main '$remote_addr - $remote_user [$time_local]  $status '
    '"$request" $body_bytes_sent "$http_referer" '
    '"$http_user_agent" "$http_x_forwarded_for"';
  access_log   /var/log/nginx/access.log main;
  sendfile     on;
  tcp_nopush   on;
  server_names_hash_bucket_size 128; # this seems to be required for some vhosts

  server {
     listen       80;
     server_name  _;
     root   /opt/myapp/current/server/public;

     location / {
         root   /opt/myapp/current/server/public;
         index  index.php index.html index.htm;
     }

     error_page  404         /404.html;
     location = /404.html {
         root   /usr/share/nginx/html;
     }

     # redirect server error pages to the static page /50x.html
     #
     error_page   500 502 503 504  /50x.html;
     location = /50x.html {
        root   /usr/share/nginx/html;
     }

     # deny access to .htaccess files, if Apache's document root
     # concurs with nginx's one
     #
     location ~ /\.ht {
         deny  all;
     }

     location ~ /admin {
     rewrite   ^/admin(.*)$ /router.php last;
     }
     location ~ /index/ {
     rewrite   ^/index/(.*)$ /router.php last;
     }
     location ~ /services/ {
     rewrite   ^/services/(.*)$ /router.php last;
     }
     location ~ /skupdater/ {
     rewrite   ^/skupdater/(.*)$ /router.php last;
     }

     location ~ \.php$ {
     root           /opt/myapp/current/server/public;
     fastcgi_pass   127.0.0.1:9000;
     fastcgi_index  index.php;
     include        fastcgi_params;
     fastcgi_param  SCRIPT_FILENAME  $document_root$fastcgi_script_name;
     fastcgi_param  PATH_INFO $fastcgi_script_name;
     }

  }
}

Thanks everyone in advance.
Answer: This can happen when PHP-FPM tries to open the PHP file, hits the rlimit about open files and returns a 404.
Here are the relevant parts of an strace (complete strace output) :
open("/home/julien/www/shape/engine/index.php", O_RDONLY) = -1 EMFILE (Too many open files)
write(4, "\1\6\0\1\0d\4\0Status: 404 Not Found\r\nX"..., 128) = 128

So you can edit your rlimit_files or your system configuration to let PHP-FPM open more files.
Answer: I had the same problem and found this hint in the logs:
open_basedir restriction in effect

So what I did to get it working is to add the folder where phpmyadmin sits to the list in php.ini.
Comment: Had similar problem here. Your tip sure helped me. Thanks
Comment: Thank you very much, was turned off in `php.ini`, but my `/etc/php5/fpm/pool.d/domainname.conf` was over riding the setting.
Answer: I have been running into the same issue, and I have found out that the solution is the same as for https://superuser.com/questions/787888/too-many-files-open-on-mac-osx-after-running-apache-in-php-with-xdebug-for-som
There's a bug in xdebug which doesn't close the file correctly, so you are hitting a limit. If you deactivate the remote debugging this error doesn't appear anymore.
For now I have set xdebug.remote_enableto on and xdebug.remote_autostartto off, in case I want to debug something I am activating the debugger with this handy chrome extension: https://chrome.google.com/webstore/detail/xdebug-helper/eadndfjplgieldjbigjakmdgkmoaaaoc