Visual Studio retrieving an incorrect path to a project from somewhere

101
votes

Visual Studio (and possibly TFS) has somehow (I think perhaps during a source control merge) become confused about the path of a project within my solution.

It thinks it is here (example paths for simplicity):

C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj

whereas actually, the project file is located here:

C:\My Projects\ExampleSolution\ExampleProjectCorrect\ExampleProjectCorrect.csproj

I cannot for the life of me get it to recognize the correct location. I have tried:

  • Removing and re-adding the project from the correct location. An error message comes up saying The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.

  • Manually editing the .sln file to ensure all references to ExampleProjectCorrect.csproj have the correct paths.

  • Doing a find in files on the solution directory for both the correct and incorrect paths, to try and track down where studio is hiding the incorrect path.

  • Deleting the cache directories for VS and TFS

I'm tearing my hair out because I can't recreate the solution as it has near as makes no difference 100 projects in and is tied in to source control with several other developers working on it.

Can anyone point me in the right direction as to where it is storing this incorrect path and/or how to reset it so the damn thing will load correctly?

15
visual-studiocachingtfs
So, what happens if you move the project to the ExampleProjectWrong directory? – Hans Passant
Ok, some progress.. Moving it to the wrong folder allows me to load it in visual studio. I can't keep it there however as the 'ExampleProjectWrong' directory is home to another project, containing much the same folder structure. So, any ideas how to go about changing the path of the project now I have it loaded? The path field in unloaded project properties is unavailable, even when the project is unloaded? – Charlie Drewitt
I got this problem for the second time now, but this time I was able to figure out that the branched project targeted the original folder because I use different connectionstrings. This was very weird the first time, causing visualstudio to debug in files from the source folder, and mixing it with files from the branch, and even Log4net logged to the original folder! Did delete the solution suo file and it is now correctly accessing only the branched files. – Binke
I had the exact same problem. It wasn't quite as easy as just deleting the suo file. I had to: 1. Remove the offending project from the solution. 2. Save the solution. 3. Delete the .suo 4. Open the solution and re-add the project. – SeanLAllen
Deleting the SUO file worked for me. – DanielV

15 Answers

98
votes
  1. Go to Manage Workspaces (either through the File/Source Control menu or the workspace drop down in Source Control Explorer)
  2. select edit for your workspace.
  3. You should see, under working folders, a mapping for the source control directory to the old/wrong project directory.
  4. Select it and click remove.
  5. Close VS and delete the suo file.

It still references the wrong directory. Maybe rebinding might work at this point but I didn't try that. Reload your project and you should be good to go.

33
votes

Simply deleting the solutions .suo file worked for me.

13
votes

I was facing this issue after performing a migration from Visual Source Safe 2005 to TFS 2012. I couldn't wait for the "Conversion Wizard" due out in the next couple weeks so I just ran VSSConvert.exe. This took 6 or so years of history and moved it into TFS.. while I didn't get the actual timeline history.. I got a bunch of entries on the same day with the comments indicating the actual check-ins of the history.. not bad.

So after it ran all night (Successfully, yay!), I was having trouble loading my projects just as this question stated. For some reason, a few projects were being referenced to an incorrect directory. I checked the .sln, the .vsproj files, and getting latest, deleting re-getting, adding removing, etc.. I tried everything noted here... even upgrading my workspace, which I'm not sure what that even did.

FINALLY... I deleted the *.suo files and viola. It worked.

I spent a couple hours on this one.

5
votes

A slightly different solution.

TFS was displaying a non-existing path for a particular Solution. Previously, I had a laptop with a separate D: drive, but now, I just have a C: drive. TFS still thought my project was stored on D:\Project\MikesProject

I didn't have a .suo file to delete, the D: path wasn't mentioned anywhere in my Workspaces (buried away under the File\Source Control\Advanced\Workspaces menu), TFS showed that I did have the latest files in my (no-longer-existant) D: directory, and TFS in VS2013 didn't have a "Remove Mappings" option for this project.

But what did work was to simply do a "Get latest version" on the project.

After doing so, a fresh copy of the code was written to my C: drive, and (interestingly), now the Local Path was shown underlined.

Previously, the D: path wasn't shown like this.

Odd. Very odd.

2
votes

We've had similar issues with moves and renames. Deleting the local directories and then getting again solved it.

2
votes

Even after deleting the .suo file and .vs folders, I had to edit the .sln file and remove the old relative url from SccProjectName# despite the SccLocalPath# being correct. Apparently VS also uses the name as a hint path.

1
votes

Try to delete or rename .suo file (including extension). This file is at the same location where your solution file is. It worked for me.

0
votes

Just guessing, but perhaps some of your other projects references your project from the wrong location? In this case, you have not just to delete and re-insert the project into your solution, you will also have to delete and recreate the references from the referencing projects (stored in their .csproj files).

0
votes

After trying many recommendations I deleted the suo file ( again ). The last time worked. Why it did not work earlier I do not know. In general I find deleting the suo file one of the first steps I do.

0
votes

I had my asp.net website solution opened from my Dev Branch. Then for some other purpose I opened same solution from Main branch.

I made a change to one of my .ascx.cs file in the dev branch and set breakpoint. When I ran the debugger, all my break points were hit in the Dev Branch except for the .ascx.cs which was hitting the Main branch. Have not idea.

Tried cleaning the Temporary folder but didn't work.

What worked:

Closed all instances of Visual Studio

Opened the solution from Dev branch again.

Run again and the break points started hitting.

0
votes

In my case i copied the *.sln file into the project folder and changed the path to project into the *.sln file. Only this resolved the problem (vs 2015 sp1, winservise project).

Delete *.suo does not helps for me.

0
votes

Yet another solution worked for us - after trying the delete of suo and almost everything mentioned in this thread. We had a project in the solution which was showing a ghost version of the csproj file. We deleted that file and our paths fixed on another project we were trying to add.

-1
votes

If you are running your web app under Local IIS instead of IISExpress make sure you HIT the "Create Virtual Directory" button by going in the project properties. Once that's done, perform "Clean Solution" and "Rebuild Solution".

-1
votes

Deleting obj and bin files would solve the problem...

-3
votes

I know it is an old line. I just went through the same problem. We recently migrate the TFS, so I created a new workspace to map to new server and kept the old one. Every time when I open a solution which is supposed to target to my new workspace, VS always tried to load projects from my old mapping directory, till I removed my old workspace.