The project file '' has been renamed or is no longer in the solution

Question

Anyone ever had this error when trying to build a solution in Visual Studio 2008?

It's driving me MAD! I've removed all the containing projects and re-added them, and it's still not letting me build or run the solution.

Any suggestions?

Answer 1

If you open the solution file (SolutionName.sln) in a text editor you should a couple of lines something like these for each project:

Project("{FAE04EC0-301F-11D3-BF4B-00C04F89EFBC}") = "ProjectName", "ProjectName\ProjectName.csproj", "{6B887D8C-D874-4AB2-B2CC-3551DEA2CC83}"
EndProject

There may be more stuff in between those lines, or in this case they may corrupt in some way. If you can isolate the problem entry and remove it you may be able to resurrect the solution.

Answer 2

I spent a couple of hours on this error yesterday and fortunately got to the bottom of it.

We had a project file, let's just call it ProblemProj.vcxproj that was originally included in SolutionA.sln and compiled fine. The project was then added to a different solution, SolutionB.sln, and compiled fine in that solution. However, after returning to SolutionA, the "project file '' has been renamed" error started happening.

This happened because VS2010 decided to change the ProjectGUID of ProblemProj.vcxproj. The SolutionB.sln referenced the correct GUID, but SolutionA.sln still had a reference to the old GUID.

You can find it in the .sln file looking something like this:

< ProjectGuid >{271F161A-F26F-41D1-BDC8-FCF912A2F4FB}< /ProjectGuid >

The problem can be fixed in the following ways:

1) Manually edit the GUID inside SolutionA.sln by opening it up in a text editor and looking for the above markup.

2) Remove the project from SolutionA.sln and re-add it; this caused it to pick up the correct GUID and fortunately didn't decide to change it again.

3) Revert the GUID change in ProblemProj.vcxproj (which will then cause the exact same error to happen in SolutionB, so I wouldn't recommend this unless SolutionB doesn't matter to you anymore).

Hope this helps.

Answer 3

The accepted solution here did not solve it for us. The .sln file had the correct path to the project. Instead, it turns out someone had pushed the .sln.cache file into git and it had the wrong path to the project. We deleted the .sln.cache file from the computer and the build worked fine. To prevent it in the future, we removed the .sln.cache file from git, added *.sln.cache to the .gitignore file.