I have a problem with Visual Studio on a C# solution. It displays totally random errors, but the projects build. Right now, I have 33 files with errors, and I can see red squiggly lines in all of them.
I tried cleaning / rebuilding the solution, closing Visual Studio and even restarting my computer. I can modify .cs files and I see the changes in the solution.
Does anyone have an idea about why it does that?
If you have ReSharper, try emptying the ReSharper cache:
In menu, ReSharper > Options > Environment > General > Clear Caches
and disabling and re-enabling ReSharper:
In menu, Tools > Options > ReSharper > General > Suspend / Restore
Clearing Resharper's cache did not help in my case, tried suspend/restore, and also Repair Resharper, using latest download off JetBrains' website - neither of these helped. This is after I tried close/reopen VS, restart my machine, repeat, Build/Rebuild and combination thereof.
It's interesting that suspending Resharper seemed to solve the problem after the 2nd restart of VS, but it was back after I enabled Resharper <-- I tried to do this sequence 2-3 times to ensure the pattern.
Anyway, I was still having issues when I found this article:
Quick tip: What to do when Visual Studio freaks out and everything is red
So I deleted the hidden .SUO file on the same folder level with solution, and it magically solved all reds.
Note - for Visual Studio 2015, the .SUO file is in .vs/[solution_name]/v14 hidden folder.
tldr; Unload and reload the problem project.
When this happens to me I (used to) try closing VS and reopen it. That probably worked about half of the time. When it didn't work I would close the solution, delete the .suo file (or the entire .vs folder) and re-open the solution. So far this has always worked for me (more than 10 times in the last 6 months), but it is slightly tedious because some things get reset such as your build mode, startup project, etc.
Since it's usually just one project that's having the problem, I just tried unloading that project and reloading it, and this worked. My sample size is only 1 but it's much faster than the other two options so perhaps worth the attempt. (Update: some of my co-workers have now tried this too, and so far it's worked every time.) I suspect this works because it writes to the .suo file, and perhaps fixes the corrupted part of it that was causing the issue to begin with.
Note: this appears to work for VS 2022, 2019, 2017, and 2015.
I cleaned solution, closed VS, reopened it, build solution, and red unresolved lines were cleaned and build succeeded.
I found that happens frequently when using Git in Visual Studio 2017, switching branches where there is dependent code changes. Even though the project will build successfully, there will remain errors in the error list.
These errors are often namespace issues and missing references, even when the library reference exists.
To resolve:
Close Visual Studio
Delete the {sln-root}.vs\SlnName\v15.suo file (hidden)
Restart Visual Studio
I have tried all the 6 options, nothing worked for me. Below solution resolved my issue.
Close VS.
Delete the hidden ".vs" folder next to your solution file.
Restart VS and load the solution.
Here's a collection of popular answers. Upvote the OP of the answer if it helped you:
Option 1: Clean, Build and Refresh (#Mike Fuchs option)
As #Mike Fuchs mentioned, try the following operations:
In menu, Build > Clean Solution
And
In menu, Build > Build Solution
and select the project in question, and click on the refresh button:
Option 2: Clean, Close, Restart and Build (#Pixel option)
As #Pixel mentioned, try the following sequence of operations:
Clean the solution
Close Visual Studio
Open Visual Studio
Build solution
Option 3: Clear ReSharper cache (#GammaOmega option)
If you have ReSharper, try emptying the ReSharper cache:
In menu, ReSharper > Options > Environment > General > Clear Caches
and disabling and re-enabling ReSharper:
In menu, Tools > Options > ReSharper > General > Suspend / Restore
Option 4: Delete the .suo file (#Neolisk option)
As #Neolisk mentioned, deleting the .suo file might solve your problem. For Visual Studio 2015, the file is located in:
[Path of Solution]/.vs/[Solution Name]/v14/.suo
And for Visual Studio 2017:
[Path of Solution]/.vs/[Solution Name]/v15/.suo
Note that the .vs directory is hidden.
Option 5: Unload and Reload Project (#TTT option)
As #TTT mentioned, try unloading the project that causes problems:
In Solution Explorer, right-click on project, Unload Project.
And re-loading it
In Solution Explorer, right-click on project, Reload Project.
Option 6: Remove and add Microsoft.CSharp reference (#Guilherme option)
As #Guilherme mentioned, try removing and adding the reference to "Microsoft.CSharp" from the projects that have problems.
In Solution Explorer, expand the project, expand "References", right-click on "Microsoft.CSharp" and Remove.
Then, right-click on References > Add Reference, select "Microsoft.CSharp" from the list and click OK
Delete the hidden file path = your solution\ .vs\ your solution Name \v15\ .suo
I had a problem like this where Intellisense didn't seem to recognise the existence of one project (lots of "can't find this type", "this namespace doesn't exist", etc. errors).
Removing and re-adding the project reference in all the referencing projects would fix the issue, but the underlying cause could be fixed by editing the .proj file of the problem project.
Near the top of the "missing" project' .csproj file is an element:
<ProjectGuid>{GUID}</ProjectGuid>
and in all of the referencing projects .csproj files were project references:
<ProjectReference Include="..\OffendingProject\OffendingProject.csproj">
<Project>{ANOTHER-GUID}</Project>
<Name>Offending Project</Name>
</ProjectReference>
The referencing GUID didn't match the project's GUID. Replacing {GUID} above with {ANOTHER-GUID} fixed the problem without having to go through every referencing project.
So many things that could cause it, as evidenced by the long list of answers here. Here's what fixed it for me, having tried pretty much everything else first.
Build your sulution in DEBUG mode. Then build it in RELEASE mode (it shouldn't build when it has red wavy lines, but in my case it was just warnings that should have had green wavy lines but it was getting in a muddle and giving them red wavy lines, and it built anyway even in release mode). Then build in in DEBUG mode. Spitting on your hands and turning around three times optional.
Worked for me, when nothing else did.
for VS-2017, deleting .vs folder worked for me.
Following solution worked for me
1 - Close VS
2 - Delete .vs folder
3 - Open VS
4 - Build solution
I've noticed that sometimes when switching git branches, Visual Studio (2017) will not recognize types from some files that had been added in the second branch. Deleting the .vs folder solves it, but it also trashes all your workspace settings. This trick seems to work well for me:
Solution Explorer -> Find the file with the unrecognized class in it.
Click Show All Files at the top of the Solution Explorer.
Right-click the file -> Exclude from project.
Right-click the file again -> Include in project.
This causes Intellisense to parse the file that it missed when switching branches.
Occasionally I have to do a custom clean by going through all of the projects and manually deleting the "bin" and "obj" folders. To see them in Visual Studio, you'll have to enable hidden files and folders for each project. After this is done, rebuild the solution.
My symptoms in VS2019 were that I would build with some errors. Then I'd fix the errors, and the build would work, as shown in the Output window. But the Errors windows still showed the old errors. I could run it just fine. Closing VS2019 and reopneing fixed the issue, but only for a little while. This started happening on version 16.4.3
This solution seems to work for me:
Uncheck Tools->Option->Projects and Solutions->General->Allow parallel project initialization
I found this fix buried way down in the comments here: https://developercommunity.visualstudio.com/content/problem/483450/vs-2019-intellisense-reports-compile-errors-when-r.html
Perhaps you try to reset your intellisense cache. I've had a similar issue in visual studio 2012 when working in a large project with many partial class definitions.
Reducing the partials solved the problem partially, clearing the intellisense cache also - for a while.
Deleting .vs folder solved my problem.
But it also reset my solution's current settings in VS. Like, my unloaded projects in the solution were re-loaded and all the pinned and opened documents were also closed when I restarted the VS.
0 - Right click on the Solution and clean solution
1 - Close VS
2 - Delete project's .suo file
3 - Open VS
4 - Build solution
A colleague of mine experienced this issue today. We tried many of the recommendations here and none worked except the solution described below.
Problem:
Project builds fine but Intellisense fails to recognize certain types and marks particular using statements as invalid.
Solution:
Change the 'Solutions Platform' (in VS 2017 this is the dropdown next to the Solution Configuration dropdown and has values such as x86, x64, AnyCPU, Mixed Platforms, etc.) to AnyCPU.
The platform for your project may vary, but it seems as though some references may not be valid for all platforms.
In my case helped a combination of things:
deleting all old not needed files which were previously excluded from the project
closing VS
deleting all the bin folder contents
deleting .vs folder
Clean/Rebuild
after that I still had some spurious errors, however the amount was significantly lower (from 200 to around 8) and the errors referred only to a resource dictionary path in Generic.xaml e.g. <ResourceDicitonary Source="example/path/somefile.xaml"> when I played around with the path trying to change it to a wrong one re-building then correcting it and rebuilding again, then this finally cleared all errors. It was specifically WPF project if that's relevant.
For my specific case it was a service reference another developer merged into the main branch. Which was perfectly fine except syntax highlight failed to resolve the generated service class and source was all red underlined. Cleaning, rebuilding, restarting did nothing.
All I had to do was refresh the service reference and VS managed to put the pieces together behind the scenes. No changes in the source code or generated files.
I've just ran into this issue after reverting a git commit that added files back into my project.
Cleaning and rebuilding the project didn't work, even if I closed VS inbetween each step.
What eventually worked, was renaming the file to something else and changing it back again. :facepalm:
After trying all of the options listed I discovered yet another reason why this can happen. If somebody sent you the source code as a zip, or you downloaded a zip, Windows may have blocked all files. 2 ways to solve this:
Method 1:
Right click on the original Zip file -> Check 'Unblock' -> Click apply
Method 2:
If that's not an option, rather than opening properties on every file in the solution folder simply open power shell and unblock recursively using the following:
Get-ChildItem -Path 'C:\<ROOT FOLDER OF SOLUTION>\' -Recurse | Unblock-File
first close the solution.
then solution cache file delete( in location C:\Users\Documents\Visual Studio\Backup Files/project cache file)
then .suo file delete
then solution open and build.
I hope solve your problem
Had this issue at work (running VS2017). Tried all of the answers here. No joy.
The project would build just fine, but was complaining that namespaces / types couldn't be found. Red squiggles all over the place. Lots of errors in the Error List window.
My solution contained 3 projects.
Discovered that 3 of the NuGet library references for one of the projects was out of line.
Consolidated the referenced library versions, and Bingo.
Hope this helps someone.
Brett.
Unload & reload the project fixed this problem.
I've been struggling with this issue for over a year and none of these solutions helped me:
Delete .suo
Delete .vs folder
Delete any or all cache / temp folders
Delete obj / bin folders
Unload / reload project
I finally fixed this issue - I opened the vbproj/csproj file in notepad and noticed that in the ItemGroup section, there was a reference back to my main project dll. I deleted this reference, reopened my solution and the problem was fixed.
Sometimes if you just clean solution the errors are disappearing, but they may eventualy come back afer a while or at the next build.
Ran into this issue with a single type not being recognized by Visual Studio which showed the red squiggle even though the solution built successfully. I noticed in the Solution Explorer the file did not have the expand arrow on the left which shows classes and properties on expansion.
The fix was to Exclude the file from the project and save/build which produced an expected error and then Include the file in the project and save and build.
After performing these steps Visual Studio started to recognize my type again. Looking at the diff in git it appears the issue was due to line endings not matching on the <Compile Include="..." /> line of my .csproj file.
in my case vs was never retaining the imported namespaces in the project properties > references
when I tried to add/check them again I couldn't and vs threw an error and when saved project vs crashed. When I reopened all the standard imported namespaces (system.data etc...) were all ticked again and it then was recognising everything without error
Related
My Visual Studio is not showing a lot of the available classes in the IntelliSense auto-complete. For example, a project I'm working on has a reference to the Microsoft.Xna.Framework namespace, yet even after adding the using statement using Microsoft.Xna.Framework in a file, IntelliSense is unable to recognize classes like Texture2D and Rectangle. I can still type them in, however, without getting a compiler error. Any idea what's happening?
The IntelliSense detects standard libraries like System.Diagnostics but not any external ones.
It is not a NameSpace conflict issue because classes within the current namespace are also missing from the IntelliSense.
I have tried:
Restarting Visual Studio (With and without closing tabs)
Deleting the contents of %LocalAppData%\Microsoft\VisualStudio\14.0\ComponentCacheModel folder
Resetting import and export settings
What worked for me is unloading and reloading the project
If unloading/reloading the project doesn't work, try deleting the .suo file found in the SolutionName/.vs/ folder. The .vs folder is an auto-created, hidden folder so you will have to show hidden folders in order to see it.
I am using ReSharper. What worked for me:
Unload project.
ReSharper > Options > Environment > General > Clear caches
Close solution.
Exit Visual Studio.
Restart Visual Studio.
Reload project.
Do you have ReSharper or any other plugins installed? There sounds like a similar issue/solution here. It may be third-party plugins at play depending on what add-ons you have.
Try saving and reloading the files.
I don't know why it happens, but it happens to my work laptop occasionally, typically reopening the source file resolves it.
OK so probably not the best solution but it works. I reinstalled Visual Studio and the problem was fixed. Also, it hasn't shown up since (this happened about 3 months ago).
another dumb solution))) Determine which classes/namespaces are not showing up. Then go to that project where they are. In that project pick any .cs file copy its contents, then delete that file and create again))
Click on the class not showing and Change Build Action -> to Compile
it happens sometimes when you add class as content or other resources
I've got this error while compiling a big c# solution in Visual Studio 2010.
Each time after compilation I had to delete obj folder of one the projects used by this solution. Otherwise I got the following error:
Could not write to output file '...\obj\Debug\Foo.Bar.dll'
The process cannot access the file because it is being used by another process
I've was looking for a solution all over the Internet and actually found/tried few of them.
For example : a lot of people on dev forums were suggesting not to start the compilation while UserControl (in some other sources From) designer is opened.
Some other people used pre-build scripts for obj folder removal, this particular solution is acceptable, but if the issued project is a widely used library its recompilation will cause recompilation of "parent" projects.
Finally I've discovered a solution for this VS2010 (SP1 too) "bug" and I want to share it with stackoverflow users.
In my case the problem was that csproj file was SELF-REFERENCING the locked '...\obj\Debug\Foo.Bar.dll' file. Crazy I know.
So I solved this annoying issue by removing the following line from .csproj file:
<Reference Include="Foo.Bar">
<HintPath>obj\Debug\Foo.Bar.dll</HintPath>
</Reference>
I initially found another solution to the problem as VS seems to lock the assembly in the obj\debug folder. I added a pre-build script to the project which fixed my problem.
del "$(ProjectDir)obj\*.*" /S /F /Q
After seeing the answer given by Salaros, that was indeed the problem. I created a new usercontrol that uses a Server control from another project. For some reason VS sometimes creates a self-references to itself when you view the usercontrol in design mode. Even removing the self-reference fixes it until VS thinks its time to add the reference again. Haven't found an exact pattern for that part.
PS: I'm using vs2012
In my case for me somehow the exe file was missing from release. Not sure how this happened. I replace it with a copy from debug and all was fine. I should have checked this sooner but never thought that the file would just turn up missing.
This problem happened to me when I:
Opened Visual Studio
Ran debug
Went to C: and used system cleanup
If you try to build again, you will find this error.
Solution:
Close Visual Studio
Do system cleanup
Restart your computer
Open Visual Studio as administrator
Choose your project
Clean
Rebuild
I just upgraded a VS2010 project to VS2012 and am now having a problem where dependent projects are not building on demand. For instance, say I have the following projects in my solution:
Library A
ConsoleApp 1
Where ConsoleApp 1 references Library A. If I change the signature of a method in a class in Library A and run ConsoleApp 1, there will be a compiler error due to ConsoleApp 1 not seeing my changes because running ConsoleApp 1 did NOT cause Library A to build.
If I manually build Library A, then manually build ConsoleApp 1, it works fine. However, I would expect that running ConsoleApp 1 should cause any dependent projects to be rebuilt before launching.
Could I have something configured incorrectly? Or is this a bug in VS2012?
Your symptoms sound very similar to those I experienced a while ago. Ensure that the projects are set to build with your current active solution configuration and active solution platform under Build->Configuration Manager.
Try by removing project references and adding them again (path to follow: References -> (right click) Add reference -> Solution -> Project). Before giving another try Save All. This is how I solved it.
This happens when the .suo file for the solution becomes locked and Visual Studio is no longer able to write to it. Another symptom of this problem is that you will see temp suo files being created next to the solution when you open it. Try closing Visual Studio and deleting all *.suo files in your working area. Then reopen Visual Studio and rebuild all. No need to manually rebuild your solution. This will fix the issue when it is caused by a locked .suo, as happened to a colleague of mine today.
In his case, the cause seemed to be that he shutdown his laptop while Visual Studio was still open. Maybe the shutdown of Windows didn't complete cleanly? We can only speculate on how the .suo originally became locked.
I tried all the solutions above and that did not fix the issue for me. I found that it was because of the Active configuration in the ConfigurationManager was set to build only the Main (start up) project.
Go to Build > ConfigurationManager
Ensure that all the projects you want to build are checked as in the screenshot below
This is a similar issue on Asp.Net forum here and this is the details on MSDN
. Although it was weired, bcoz I never changed these settings and it was working properly last week
I've encountered a similar problem, the solution (or the probelem) were the Build and Run settings under Tools > Options... > Projects and Solutions > Build and Run where "Only build startup projects and dependencies on Run" was checked. The screenshot shows my currently working solution.
For me, I resolve the issue by right clicking on the project; Build Dependencies > Project Dependencies. Then manually setting the order for each project. very painful if you have a lot of projects.
make sure that the referencing project has same or higher .Net framework version than the referenced project.
Right Click solution in solution explorer then click "Clean Solution".
Just recently, my Visual Studio 2010 stopped displaying IntelliSense suggestions automatically while I am typing. I can still press ctrl+space to get it to work, but it doesn't automatically show a list of suggestions like it used to. I have already tried disabling all my extensions, restarting VS and the computer, and I have checked all the appropriate settings (Options -> Text Editor -> C# -> IntelliSense) to make sure that it is set to offer suggestions after a character is typed.
Has anyone seen this behavior before? Does anyone have any other suggestions for how I can get IntelliSense to go back to the way things were before? If not, I might just have to do a fresh reinstall of VS...
In prose, in case you can't see the above image:
Open Tools > Options > Text Editor. If you're only having this issue with one language, find that language; if it's for everything, click "All Languages". Right at the top, there'll be a few options labeled "Auto list members", "Hide advanced members", and "Parameter information". Make sure all of those are enabled (though the second may be disabled; if so, ignore it).
I have found that at times even verifying the settings under Options --> Statement Completion (the answer above) doesn't work. In this case, saving and restarting Visual Studio will re-enable Intellisense.
Finally, this link has a list of other ways to troubleshoot Intellisense, broken down by language (for more specific errors).
http://msdn.microsoft.com/en-us/library/vstudio/ecfczya1(v=vs.100).aspx
I'll start off my noting that this hasn't happened since I upgraded my RAM. I was at 4GB and would often have multiple instances of VS open along with SSMS. I have since gone to 8GB and then 16GB.
Here's the steps I go through when I lose intellisense.
If only one file/window appears to be affected, close/reopen that file. If that doesn't work, try below.
In Visual Studio:
Click Tools->Options->Text Editor->All Languages->General
Uncheck "Auto list members"
Uncheck "Parameter information"
Check "Auto list members" (yes, the one you just unchecked)
Check "Parameter information" (again, the one you just unchecked)
Click OK
If this doesn't work, here's a few more steps to try:
Close all VS documents and reopen
If still not working, close/reopen solution
If still not working, restart VS.
For C++ projects:
MSDN has a few things to try: MSDN suggestions
The corrupt .ncb file seems most likely.
From MSDN:
Close the solution.
Delete the .ncb file.
Reopen the solution. (This creates a new .ncb file.)
Notes:
This issue does not appear to be specific to C# as C++ and VB users
report the same issue
Tested in VS 2013/2015
Steps to fix are:
Tools
Import and Export Settings
Reset all settings
Back up your config
Select your environment settings and finish
I also faced the same issue but in VS2013.
I did the below way to fix, It was worked fine.
Close all the opened Visual studio instance.
Then, go to "Developer command prompt" from visual studio tools,
Type it as devenv.exe /resetuserdata
Restart the machine, Open the Visual studio then It will ask you to choose the development settings from initial onwards, thereafter open any solution/project. You'll be amazed.
Hope, it might helps you :)
Deleted the .suo file in solution folder to solve the problem.
Sometimes i've found Intellisense to be slow. Hit the . and wait for a minute and see if it appears after a delay. If so, then I believe there may be a cache that can be deleted to get it to rescan.
I hit this today after the following sequence:
Added a new class to my project.
Closed Visual Studio, but accidentally selected No when it asked if I wanted to save changes.
Reopened Visual Studio, and found that it reopened the new file automatically but without my previous changes (as expected). However, IntelliSense was no longer working in the new file.
The problem was in addition to not saving changes to the new file, it didn't save changes to the project, so after reopening Visual Studio the file was not part of the project. The Show All Files command in Solution Explorer, or Add → Existing Item..., resolved the problem.
I had the file excluded from the project so i was not able to debug and have intellisense on that file.
Including the file back into the project solved my problem! :)
A new cause for this in the .net core era is having a project loaded for an unsupported .net core version. For instance if you loaded a project from GitHub that was set to use:
<PropertyGroup>
<TargetFramework>netcoreapp2.2</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
But you only have 2.1 installed or find yourself using Visual Studio 2017 then the compiler wont be able to find the SDK code and thus provide intellisense.
The solution in that case might be to right click on your project and select Edit MyProject.csproj from the context menu and change the target framework as necessary:
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<AspNetCoreHostingModel>InProcess</AspNetCoreHostingModel>
</PropertyGroup>
This assumes whatever project you loaded can actually be run under a lesser target framework.
I simply closed all pages of visual studio and reopened ..it worked.
Deleting the .vs folder in the solution solved my issue. You have to exit from Visual Studio and then delete the .vs folder and start Visual Studio again.
Closed all my VS windows
Started the Visual Studio Installer and clicked 'Modify'.
Under 'Individual components' > 'Code Tools' > Deselected NuGet package manager and re-selected it.
After modifying and restarting VS, IntelliSense was working correctly again.
Found my answer on https://developercommunity.visualstudio.com/content/problem/130597/unity-intellisense-not-working-after-creating-new-1.html
[Tools -> Options -> Text Editor -> All Languages -> CodeLens]
Check if check box "Enable CodeLens" is checked
I have just come to about this problem while installing one of the extensions and its file was deleted by my anti virus so I just disabled my anti virus and reinstalled visual studio. Suggestions are working properly without any changes made after installation.
At the bottommost right look at the blue line where Ln, Col, Spaces, UTF, CRLF,..... here the language is specified.
Check that your language and the language specified there are the same.
In my case, it was Django Python while I was trying to use HTML.
This may be due to the solution configuration changed to Release Mode instead of debug. Right click on solution -> Properties -> Configuration Properties -> Set Configuration To Debug if it is in Release.
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.