EDN Admin
Well-known member
Ive recently migrated some code for a client from VC 6.0 to VS2010. After giving the updated code back to them, they are getting the dreaded "The project file has has been renamed or is no longer in the solution" error message. This is only
happening on the solution they had that has about 14 projects in it. At the same time, I also migrated a VS2003 solution that contained C# and Managed C++ projects, but that solution doesnt have the problem - only the one migrated from VC 6.0 does.
The solution contains several DLLs and executables with project dependencies between them.
If I remove all the dependencies and re-add them again, everything is good and the solution compiles - unless the directory is renamed or placed in a new directory. For instance, if the solution is at D
evCodeFoo and I move it to DevCodeBar,
I get the error again until I re-add all the dependencies. If I move it to a new machine, all is good as long as the directory exactly matches the original location, but the same problem exists if it was placed in a new location. This is obviously
problematic as there are many developers on the team and for the build machine.
Using BeyondCompare, Ive found that when I copy to a new directory and refix the issue, the only difference between the original location and the new location are the GUIDs of the projects in the vcxproj and sln files - everything else is identical, so
its not like I have a hard-coded path in there somewhere. Ive cleaned out the solutions completely (all suo, debug, build, etc. files), but the problem still is happening. I just dont get whats going on, why it keeps wanting to change the project
GUIDs. I did find a comment on a connect issue https://connect.microsoft.com/VisualStudio/feedback/details/111698/the-project-file-has-been-renamed-or-is-no-longer-in-the-solution (the top comment of issue 111698) that indicated
the same problem as Im seeing, but there was no fix or workaround provided and MS closed it as could not recreate. Ive also tried to recreate it both with a VS2010 solution directly and a VC 6.0 converted solution, but I cant seem to repro it either
- seems somehow related to this solution, but I cant seem to figure out why it keeps happening.
View the full article
happening on the solution they had that has about 14 projects in it. At the same time, I also migrated a VS2003 solution that contained C# and Managed C++ projects, but that solution doesnt have the problem - only the one migrated from VC 6.0 does.
The solution contains several DLLs and executables with project dependencies between them.
If I remove all the dependencies and re-add them again, everything is good and the solution compiles - unless the directory is renamed or placed in a new directory. For instance, if the solution is at D
evCodeFoo and I move it to DevCodeBar,I get the error again until I re-add all the dependencies. If I move it to a new machine, all is good as long as the directory exactly matches the original location, but the same problem exists if it was placed in a new location. This is obviously
problematic as there are many developers on the team and for the build machine.
Using BeyondCompare, Ive found that when I copy to a new directory and refix the issue, the only difference between the original location and the new location are the GUIDs of the projects in the vcxproj and sln files - everything else is identical, so
its not like I have a hard-coded path in there somewhere. Ive cleaned out the solutions completely (all suo, debug, build, etc. files), but the problem still is happening. I just dont get whats going on, why it keeps wanting to change the project
GUIDs. I did find a comment on a connect issue https://connect.microsoft.com/VisualStudio/feedback/details/111698/the-project-file-has-been-renamed-or-is-no-longer-in-the-solution (the top comment of issue 111698) that indicated
the same problem as Im seeing, but there was no fix or workaround provided and MS closed it as could not recreate. Ive also tried to recreate it both with a VS2010 solution directly and a VC 6.0 converted solution, but I cant seem to repro it either
- seems somehow related to this solution, but I cant seem to figure out why it keeps happening.
View the full article