We Keep Coding

Problem with building of the solution - Visual Studio 2022

Did anyone of You had the same problem as described below? If so, do you have any tip or solution for this?
I have a problem with my local environment. Every time I try to build the solution, a lot of its projects are being skipped and I receive many CS0006 errors: "Metadata file (...) could not be found".
Another thing I noticed is ribbon with message "Current solution contains incorrect configurations mappings. It may cause projects to not work correctly. Open the Configuration Manager to fix them." When I open Configuration Manager, all projects of solution are checked, and everything seems to be correct there.
I use Visual Studio 2022 (64-bit), version 17.4.1 and .NET Framework version 4.8.04084.
I tried almost all recommendations from the Internet, including uninstalling and installing again Visual Studio or reuploading of repository, but there is no update about this problem.
Thank You in advance.

You could try the steps provided by Sabah Shariq.
Right click on the solution and click Properties.
Click Configuration on the left.
Make sure the check box under "Build" for the project is checked. If check then uncheck and check again and save the settings.
Clean the solution by right clicking on the project solution and rebuild the project again.
Make sure you don't have any other error messages in your project and if you do, fix those first!
For more information, please refer to:
Error CS0006_Metadata file could not be found

Thank you for your help. I have found the cause of this problem by myself. It turned out that some lines of code was removed from sln file by mistake (in my opinion there was an error of Visual Studio). When I re-added them, the solution is able to be built.
Anyway, thank you for your support.

Xamarin IDE Access to the Path is denied

I'm porting over a Visual Studio C# solution with many projects and creating a new solution in the Xamarin IDE - all on windows.
I am porting / re-creating 1 project at a time and then compiling. I can compile each project individually but and then I can compile the solution (with some errors).
The problem arises if I try a Rebuild All, then it shows the error:
'Access to the path "[my build path\some.dll]" is denied.'
I have full admin rights and, as I mentioned, I originally could build the dll's so it's not an access issue.
If I try to actually delete the dll's in question, I can't - windows denies me.
If I close Xamarin, I can then delete the file manually. So, I assume, Xamarin still has a 'lock' on the file which won't allow it to be deleted.
Has anyone else seen this and if so, how did you get around it?
If this is a bug, then this makes this nearly unusable.

I just started with Xamarin in Windows as well and am having this problem. A quick fix I found it to switch from Debug over to Release; but this disables your debug output. Closing and reopening Xamarin has also relieved the issue for a few more debug builds.
I have found no rhyme or reason why this is occurring, seems to be at random.

Check the read-only property of the dll on that path, make sure it is not checked. I had the same issue, After unchecking the read-only property, the issue resolved.

Remove all cache in this file C:\Users{user}.nuget\packages And update xamarin.forms

Why is my MonoDroid/Xamarin.Android project suddenly giving me a "'java' exited with code 1." error?

While working on my MonoDroid/Xamarin.Android app, it suddenly stopped building, telling me
"java" exited with code 1.
After turning on normal MSBuild output verbosity, it showed that the error occurred in Xamarin.Android.Common.targets, located in C:\Program Files (x86)\MSBuild\Xamarin\Android. The line (line 988) starts this block of xml:
<CompileToDalvik
JavaMaximumHeapSize="$(JavaMaximumHeapSize)"
JavaOptions="$(JavaOptions)"
AndroidSdkDirectory="$(_AndroidSdkDirectory)"
ClassesOutputDirectory="$(IntermediateOutputPath)android\bin\classes"
JavaSdkDirectory="$(_JavaSdkDirectory)"
MonoPlatformJarPath="$(MonoPlatformJarPath)"
JavaSourceFiles="#(AndroidJavaSource)"
JavaLibraries="#(AndroidJavaLibrary)"
LibraryProjectJars="$(IntermediateOutputPath)__library_projects__\*.jar"
UseDx="$(UseDx)"
/>
Also, when I have the above file open, I have 53 warnings, all similar to:
The element 'PropertyGroup' in namespace 'http://schemas.microsoft.com/developer/msbuild/2003' has invalid child element 'ResolveReferencesDependsOn' in namespace
'http://schemas.microsoft.com/developer/msbuild/2003'. List of possible elements expected: 'Property, AllowUnsafeBlocks, ... [followed by a long list of elements]
I deleted all the code that I had recently added, then ended up doing a full revert to previous code that worked, but the error continues no matter what I do. I found a resolved bug that may occur on the same line, but the solution given there didn't work for me. Also, because of the warnings and the fact that my code used to work it its current revision, it doesn't seem to be the same problem. Any ideas why this would happen, and how I might fix it?
More details: I tried running a new M4A project and it worked fine, so it looks like it isn't a problem with the M4A file, but something my code.
Even more details: I was going through each class, commenting them out to see if I could find a particular block that was causing the problem, when the error suddenly changed. It now displays an error identical to the one found in this question. I am also using the 30-day trial. However, I am using Visual Studio. I'll be seeing if the answer and comments there will help me too.

I had the same problem and solved it by deleting my entire solution an pulling it from source control again. If you do not have a source to pull from, then i suggest deleting all generated files such as the contents of bin and debug folders.

Yes It's a good solution I have removed same problem from my project.
Step that you have need
1. Delete Bin and obj folder from project
2. Delete Solution File From Project Folder
3. Open New Visual Studio and then Click File > Open > Project/Solution >
Select Folder Where placed you project.
and after all, Rebuild Solution file and then rebuild your project.
I am sure u will success about this problem.....

I encountered this problem on a colleague's computer. The problem ended up being that his old sdk was installed under Program Files, while the update installed it under AppData. Changing this folder under Options > Xamarin > Android in Visual Studio solved the problem for him.

I have solved by disabling the Proguard option and able to build it.
Right Click on Project -> Click Properties -> Android Options -> Uncheck Checkbox of Enable Proguard.

Can't rebuild my application anymore

I'll give you 2 versions of my problem to describe it, first the short version.
When I try to build my application it does that perfectly and my app works but when I try to rebuild it, that fails and gives an error message saying that 2 files are missing (bin/debug/MusicPlayer.exe and bin/debug/MusicPlayer.pdb). When I then try to build normally, it fails to with the same error.
Now the longer version:
The way this happened was quite out of nowhere, I program on 2 different locations (both in Visual Studio 2010 sp1) but to always have the recent version in the right place I copy the entire solution folder to a usb stick, this folder I copy over again on the other PC and use it to continue were I left off, I've done this many times without problem. Yesterday however, I got an exception while testing the app. But instead of showing this in my code, it was complaining that it could not find the program.cs file (it was there, but apparently it had a different checksum (md5) and it asked me to use this one. After a while I found what part of my code caused the exception and fixed it. Since then I haven't got that error anymore. But when I later tried to rebuild instead of build, it gave me the error described in the short version. I have tried to fix it, but apparently I was not very successful.
Basically, what I think it does is delete the files in the debug folder that need rebuilding and then gives me the error of missing files (the files that it deleted) and thus failing to rebuild succesfully because these deleted files the normal build option won't work to.
(What I then do is re-copy them from my usb to make the normal build work).
Don't know if it's important, but I program in C# and I'm still learning.
Also when I copied it to my usb I believe I had no errors and the app was working fine (except the part I fixed later, which I could not test at that location). And when I build the entire solution it gives some warning ==> "Assembly 'bun/debug/MusicPlayer.exe' is incorrectly specified as file" and this for 5 files.
Does anyone know how to fix this rebuild problem and if necessary the warnings?
Thanks in advance
(and sorry for my bad English)

OK it seems like you might be confusing yourself with your directory structure here. If you want to add Content or Resources (Images, Text Files, etc.) you should place them in a folder within your project (not called bin or obj). All your build files will go here. Instead place the Content in another folder and Right Click -> Properties and Set the build action to "Content" or "Resource" and set the Copy to Output Directory (bin folder) to "Do not Copy" or "Copy if newer."
The project is failing because you have the built executable "MusicPlayer.exe" in your project. So Visual Studio is trying to build an executable file in adding to the project. Restructure your directories or remove "MusicPlayer.exe" ever time your build your project.

Do you have any anti-virus software running? They can go way too aggressive on removable drives. You are actually continuously deleting and creating a runnable program on usb stick by recompiling.
Just a guess tho...

Sounds to me like you have a pre- or post-build event with a hardcoded path in it. Fix that using variables and it should be ok.

Metadata file '.dll' could not be found

I am working on a WPF, C# 3.0 project, and I get this error:
Error 1 Metadata file
'WORK=- \Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug
\BusinessLogicLayer.dll' could not be found C:\-=WORK=- \Tools
\VersionManagementSystem\VersionManagementSystem\CSC VersionManagementSystem
This is how I reference my usercontrols:
xmlns:vms="clr-namespace:VersionManagementSystem"
<vms:SignOffProjectListing Margin="5"/>
It happens after every failed build. The only way I can get the solution to compile is to comment out all my user controls and re-build the project, and then I uncomment the usercontrols and everything is fine.
I have checked build orders and dependencies configurations.
As you can see, it seems to have truncated the DLL file's absolute path... I have read that there is a bug with the length. Is this a possible problem?
It's very annoying and having to comment, build, and uncomment, the build is becoming extremely tiresome.

I just had the same problem. Visual Studio isn't building the project that's being referenced.
Written Instructions:
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:

This can still happen in newer versions of Visual Studio (I just had it happen on Visual Studio 2013):
Another thing to try is to close Visual Studio and delete the .suo file that is next to the .sln file. (It will be re-generated the next time you Save all (or exit Visual Studio)).
I've had this problem when adding new projects to the solution on another machine and then pulling the revisions in, but the .suo file can be corrupted in other cases as well and lead to very strange Visual Studio behaviour, so deleting it is one of the things I always try.
Note that deleting the .suo file will reset the startup project(s) of the solution.
More on the .suo file is here.

The suggested answer did not work for me. The error is a decoy for another problem.
I found out that I was targeting a slightly different version of .NET and this was flagged as a warning by the compiler, but it was causing building to fail.
This should have been flagged as an error and not a warning.

Well, my answer is not just the summary of all the solutions, but it offers more than that.
Section (1):
In general solutions:
I had four errors of this kind (‘metadata file could not be found’) along with one error saying 'Source File Could Not Be Opened (‘Unspecified error ‘)'.
I tried to get rid of ‘metadata file could not be found’ error. For that, I read many posts, blogs, etc. and found these solutions may be effective (summarizing them over here):
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.

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.

Visual Studio 2019 this worked for me:
Close Visual Studio
Delete the hidden .vs folder
Reopen Visual Studio and rebuild the solution.

Closing and reopening Visual Studio 2013 worked for me!

Well, nothing in the previous answers worked for me, so it got me thinking about why am I clicking and hoping when as developers we should really try to understand what is going on here.
It seemed obvious to me that this incorrect meta data file reference must be held somewhere.
A quick search of the .csproj file showed the guilty lines. I had a section called <itemGroup> that seemed to be hanging onto the old incorrect filepath.
<ItemGroup>
<ProjectReference Include="..\..\..\MySiteOld\MySite.Entities\MySite.Entities.csproj">
<Project>{5b0a347e-cd9a-4746-a3b6-99d6d010a6c2}</Project>
<Name>Beeyp.Entities</Name>
</ProjectReference>
...
So a simple fix really:
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.

In my case, I have my installed directory in mistaken ways.
If your solution path is something like "My Project%2c Very Popular%2c Unit Testing%2c Software and Hardware.zip", it cannot resolve the metadata file, perhaps we should prevent some invalid words like %2c.
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 a normal name resolved my issue.

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

In my case, the problem was caused by a simple build error,
error CS0067: The event 'XYZ' is never used
that, for any reason, did not show up in the error window.
Because of that, the Visual Studio build system seemed to miss the error and tried to build dependent projects, which in turn failed with the annoying metadata message.
The recommendation is -as stupid as it may sound-:
First look at your Output Window!
It took me half an hour before this idea hit me...

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

I added a new project to my solution and started getting this.
The reason? The project I brought in was targeting a different .NET framework (4.6 and my other two were 4.5.2).

For me, it was trying to find a DLL in a path that used to contain the Project, but we'd moved it to a new directory. The Solution had the correct path to the Project, but Visual Studio somehow kept looking in the old location.
Solution: Rename each problem Project - just add a character or whatever - then rename it back to its original name.
This must reset some global cache of some kind in Visual Studio, because this clears both this issue up and several like it, while things like Clean do not.

It looks like such kind of errors related to the fact that Visual Studio doesn't provide correct information about an error. The developer doesn't even understand the reason for the failed build. It can be a syntax error or something else. In common, to solve such problems you should find the root of the problem (for example, look at the build log).
In my case the problem was in fact that the Error List window didn't show any errors. But really there were syntax errors; I found these errors in the Output window, and after fixing them, the problem was solved.

For me it occurred when I included a new project to a solution.
Visual Studio automatically selects .NET framework 4.5.
I changed to version .NET 4.5.2 like the other libraries, and it worked.

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.

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

For me the following steps worked:
Find the project that is not building
Remove/add references to projects within the solution.

I was pulling my hair out with this problem also, but after trying the previous answers the only thing that worked for me was to open each project in my solution 1 by 1 and build them individually.
Then I closed Visual Studio 2013, reopened my solution and it compiled fine.
It's strange, because if I clicked each project in my Solution Explorer and tried to build them that way, they all failed. I had to open them alone in their own solutions.

In my case the issue was that I'd manually deleted a non-compilation file which was marked as "missing". Once I deleted the reference to the now-missing file and recompiled - all was well.

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

I got this problem in Visual Studio 2012 in a solution that had many projects. Rebuilding each project in the solution manually in the same order as the Project Build Order (right-click and rebuild in Solution Explorer) fixed it for me.
Eventually I got to one that gave me a compile error. I fixed the error, and the solution would build correctly after that.

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

Most of the methods explained here did not solved the problem for me.
Finally, I fixed the problem by applying the following steps:
1. Close Visual Studio.
2. Delete all the contents in the bin folders of each project.
3. Open solution and rebuild.

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

Based on the error message I don't believe the file path is being truncated. It looks to just be incorrect. If I'm reading the message correctly it appears to be looking for the DLL file at ...
WORK=-\Tools\VersionManagementSystem\BusinessLogicLayer\bin\Debug\BusinessLogicLayer.dll
This is not a valid path. Is it possible that you have a macro definition in the build process set to an invalid value?

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

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

I had this error when I was trying to publish a web application. Turned out that one of a class properties was wrapped into
#if DEBUG
public int SomeProperty { get; set; }
#endif
but the property usage was not. The publishing was done in Release configuration without the DEBUG symbol, obviously.