Collectives™ on Stack Overflow

Find centralized, trusted content and collaborate around the technologies you use most.

Teams

Q&A for work

Connect and share knowledge within a single location that is structured and easy to search.

The referenced component 'System' could not be found. (or any other component for that matter)

Issue: Just started today, all references to any assembly outside of the solution fail to resolve, with The referenced component 'SomeComponent' could not be found. when trying to build. This happens for both 3rd party components (all 15 or so of them) as well as all .NET Framework assemblies - basically anything that isn't another project in the same solution.

Trying to load some other solutions produced the same issue. Creating a new WinForms project worked without a problem, however. (Scratch that, it worked before reinstalling VS, now that doesn't work either. I created a new WinForms app as well as a WPF app, and the designer can't load the assemblies either. I tried targetting 3.5 and 2.0 and no luck.)

Things I've tried:

Does anyone have any experience with this and know of a way to get this working again? My strongest Google-fu has failed me, so I'm asking here. Can mark community wiki if requested.

Update: I tried "upgrading" Windows (to the same version) since I didn't see a repair option for Vista and it's still a no-go. I reinstalled everything that seemed relevant. So far, it's looking like I'm just gonna have to back up and reformat I guess unless a solution comes up sometime before tomorrow.

Update2: I just backed up data and reformatted, so I'm no longer able to verify any ideas that I haven't tried yet, so I'll just leave the bounty to expire on its own to the top voted answer and as a reference to anyone else who may have this problem later.

I had the same problem. It turns out that something was wrong with NuGet. I removed the following part of the *.csproj -File (opened in a text editor). This has solved the issue for me:

<Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
    <PropertyGroup>
        <ErrorText>This project references NuGet package(s) that are missing on this computer. Enable NuGet Package Restore to download them.  For more information, see http://go.microsoft.com/fwlink/?LinkID=322105. The missing file is {0}.</ErrorText>
    </PropertyGroup>
    <Error Condition="!Exists('$(SolutionDir)\.nuget\NuGet.targets')" Text="$([System.String]::Format('$(ErrorText)', '$(SolutionDir)\.nuget\NuGet.targets'))" />
</Target>
                This worked for me.  However, if you do have some nuget packages in your project, it would be wise to reinstall them after doing this to get this line back in properly.  In package manager console, type Update-Package –reinstall <package_name>, and the <Target> should return with the proper directory location for the error condition.
– helios456
                Jan 5, 2017 at 13:52
                I had this, it was related to the fact that the project was used as an external in SVN, so was included in different solutions with different relative paths to the packages folder. In my case it was xunit.runner which is Imported directly into the project rather than being an Include. Adding an Import (with Condition) for each possible relative path, and ANDing the conditions in the Error definition seems to have fixed it for me.
– Benjol
                Jan 30, 2018 at 9:21
                This works for me,  VS should display a more meaningful error,  I would never have found the problem without this answer!
– shelbypereira
                Oct 16, 2018 at 9:04
                is that a bug, why doesnt microsoft  do something about this its so annoying to face errors like these.
– user734028
                Jan 20, 2019 at 20:07
In my case, the solution was completely different. It looked like it was an issue with NuGet paths (caused by my moving the project to a different solution and then back again.
I edited the .csproj and removed all references to NuGet and associated packages. I also removed the packages folder from the solution folder. 
The system components then magically reappeared. 
                I started having this problem after installing a NuGet package. Doing this worked to fix it.
– MiffTheFox
                Nov 9, 2014 at 16:03
                This fixed my issue as well. It's bizarre, since I was doing active development on the project yesterday. Reopen the solution and suddenly can't build anything....
– Zhais
                May 20, 2015 at 18:12
                Yeah, that might be bad.  Try adding paths to where your components live (presumably starting with the current one reported, since that'll tell you whether it works in principle).
– chaos
                Apr 6, 2009 at 18:26
                Still doesn't work.  Deleted the references and re-added them.  In the reference property the path isn't listed even though I added the reference to the dll file.
– Davy8
                Apr 6, 2009 at 18:30
                You want to add a path to the directory containing the DLL, not the DLL itself; sorry, I didn't make that clear.
– chaos
                Apr 6, 2009 at 18:39
                Right, under Reference Paths I added the path to the directory containing the DLLs (well 2 of them) it doesn't let you select anything other than a directory.  I was referring to in addition to that I also tried re-adding the reference itself and that path isn't listed there either.
– Davy8
                Apr 6, 2009 at 18:45
                Ah, gotcha.  It sounds like something isn't right there, but I don't know what to tell you to do about it.  Sorry.
– chaos
                Apr 6, 2009 at 18:48
Try running VS after turing on Assembly load logging with fuslogvw. You'll be able to see additional errors captured by the runtime when it tries to locate and load the assemblies.
In Vista, you'll have to run fuslogvw as an administrator and somtimes specify an explicit path to save the logs.
You can also try debugging Visual Studio by attaching to it from another instance, or with the basic debugger included with the .NET SDK.
                Would attaching VS debugger to another instance work even though it's not crashing, just refusing to compile?
– Davy8
                Apr 10, 2009 at 15:48
                Yep you'll see diagnostic info dumped to the Output window. Chances are there's some exception thrown deep down that gets swallowed and translated to something elese. Ctrl+Alt+E to bring up exceptions and turn them all on. That will get you the exception as soon as it happens.
– Paul Alexander
                Apr 10, 2009 at 23:08
I had this similar issue not too long ago.  
I found that the issue was caused by git not properly creating .exe's when jumping from branch to branch(we have nuget.exe in a path and it was getting deleted/added when jumping branches).  When you would try to run nuget, windows would throw a fit over the exe.  
After reseting the branch many times, I finaly got the exe to run properly.  Then I noticed that the security on all the directories in the repo had been reset, so I had to deal with that.  
After all of that, visual studio then started to play nice.
Hoped this helps someone!
It may also be a problem with references of other projects in the same solution.  I only wanted to build one project, but got this message about references in another project. Although the problem in the other project was correct, I think the message was not correct:
I did not expect the message about another project (the other project was no dependency, so it did not 'need' to be built)
I could not 'interpret' it, because it did not mention the project it was about).
                VS Community 2019.  This is still getting around.  Not sure this is the same error described in this answer but certainly, it was "a problem with references of other projects in the same solution".  I am pretty new to VS.  I was trying to use code from one project in another project within the same solution so, I thought I could add a reference to one project, into another project.  This caused the issue.  Removing the reference to the other project got rid of the issue.
– B5A7
                Apr 27, 2021 at 0:10
I know that this is an old question but it is still happening in the latest version of Visual Studio (2015). I fixed it in a different way that might not have been available back when the question was asked. Basically, it is related to the fact that VS can't find the .Net Library package. To fix in the latest version of Visual Studio (2015):
Right Click on your solution in the Solution Manager. Choose "Manage NuGet Packages for Solution..."
in the NuGet Window, go to "Installed". 
If you have something related to Microsoft.Net such as "Microsoft.NetCore.UniversalWindowsPlatform", remember the name and uninstall the package.
Now go to the browse tab and find the package and install it again. Don't forget to select the correct needed project.
Everything should be ok now.
I hope this helps somebody!
I hate to say it, but it sounds like the system is pretty borked. There has to be a point when it is quicker to reinstall the OS than it is to continue trying to fix the current install.
I just hope you take this in the right spirit... sorry.
                I wish you the best of luck, but I expect you'll end up doing an OS re-install. In which case: sooner = less time lost.
– Marc Gravell
                Apr 8, 2009 at 13:59
Shot in the dark here, but I've run into the same (similar) problem. The issue I ran into was related to having a 64bit machine and running a project that had a mixture of 64bit and 32bit 3rd party dll's. The solution was to ensure I had the correct bits (32v64) and then to have the project build in 32 bit mode: project properties > build > platform target: x86.
Another time this occurred I had to remove all the 64bit dll's and reinstall with the 32bit dll's
HTH's
.nuget folder was missing. add the .nuget folder with nuget files (usually 3 files). open the solution and no warnings on references. My submodule has nuget references and when I pulled the latest version, the solution needs .nuget folder in the project folder.
 project
   /.nuget
   /submodule
     /.nuget
Visual Studio was unable to find any of my references.
What i did, and following some solutions above, was:
Right click solution entry in Solution Manager window;
In the newly opened NuGet window go to installed, select all entries and update.
The problem gets solved!
                Unless I'm misunderstanding how ILDASM work (I've never used it before) there is no assembly, it can't even start the compile process.  They show up as compiler warnings not errors, but the build process won't start
– Davy8
                Apr 10, 2009 at 15:45
                No, you're right -- I must have misread your post.  I thought you were having runtime problems.  Never mind.
– Coderer
                Apr 13, 2009 at 13:25
I once encountered a problem, which is in the *.csproj file. It defines an Error node in the Target node, that if one reference/nuget-library doesn't exist, it throws the error while building. The problem is VS do not show correct status for other libraries, thus all the referenced libraries looks like non-loaded, that the local file path cannot be found in the property window.
Here is a sample.
    <Target Name="EnsureNuGetPackageBuildImports" BeforeTargets="PrepareForBuild">
<PropertyGroup>
  <ErrorText>This project references NuGet package(s) that are missing on this computer. Use NuGet Package Restore to download them.  xxx.</ErrorText>
</PropertyGroup>
<Error Condition="!Exists('..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\...\Microsoft.CodeDom.Providers.DotNetCompilerPlatform.props'))" />
<Error Condition="!Exists('..\packages\NOT-Exist.targets')" Text="$([System.String]::Format('$(ErrorText)', '..\packages\NOT-Exist.targets'))" />
    </Target>
        
Thanks for contributing an answer to Stack Overflow!
Please be sure to answer the question. Provide details and share your research!
But avoid …
Asking for help, clarification, or responding to other answers.
Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.