Файл проекта '' был переименован или больше не находится в решении - PullRequest
13 голосов
/ 07 мая 2010

Кто-нибудь когда-либо имел эту ошибку при попытке построить решение в Visual Studio 2008?

Это сводит меня с ума!Я удалил все содержащиеся в нем проекты и повторно добавил их, и он все еще не позволяет мне собрать или запустить решение.

Есть предложения?

Ответы [ 6 ]

8 голосов
/ 10 апреля 2012

Вчера я потратил пару часов на эту ошибку и, к счастью, дошел до ее основания.

У нас был файл проекта, давайте просто назовем его ProblemProj.vcxproj, который изначально был включен в SolutionA.sln и скомпилирован нормально. Затем проект был добавлен в другое решение SolutionB.sln и прекрасно скомпилирован в этом решении. Однако после возврата в SolutionA ошибка «файл проекта» была переименована.

Это произошло из-за того, что VS2010 решил изменить ProjectGUID для ProblemProj.vcxproj. SolutionB.sln ссылался на правильный GUID, но SolutionA.sln все еще имел ссылку на старый GUID.

Вы можете найти его в файле .sln, который выглядит примерно так:

{271F161A-F26F-41D1-BDC8-FCF912A2F4FB}

Проблема может быть решена следующими способами:

1) Отредактируйте GUID вручную в SolutionA.sln, открыв его в текстовом редакторе и выполнив поиск вышеупомянутой разметки.

2) Удалить проект из SolutionA.sln и заново добавить его; это заставило его выбрать правильный GUID и, к счастью, не решило изменить его снова.

3) Отменить изменение GUID в ProblemProj.vcxproj (которое затем вызовет точно такую ​​же ошибку в SolutionB, поэтому я не рекомендую это, если SolutionB больше не имеет для вас значения).

Надеюсь, это поможет.

8 голосов
/ 07 мая 2010

Если вы откроете файл решения (SolutionName.sln) в текстовом редакторе, вы должны добавить несколько строк примерно для каждого проекта:

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

Возможно, между этими строками может быть больше вещей, или в этом случае они могут каким-то образом испортиться. Если вы можете изолировать запись проблемы и удалить ее, вы сможете воскресить решение.

5 голосов
/ 26 апреля 2011

Принятое здесь решение не решило его для нас.Файл .sln имел правильный путь к проекту.Вместо этого выясняется, что кто-то вставил файл .sln.cache в git и у него был неверный путь к проекту.Мы удалили файл .sln.cache с компьютера, и сборка работала нормально.Чтобы предотвратить это в будущем, мы удалили файл .sln.cache из git, добавили * .sln.cache в файл .gitignore.

2 голосов
/ 08 февраля 2013

Я только что столкнулся с той же ошибкой в ​​VS 2012 с немного другой причиной после загрузки решения, которое VS 2010 показалось довольным.

Оказывается, что один проект C ++ в решении имел ссылку на неназванный проект (просто Guid; без имени, без пути). Несмотря на то, что этот проект был загружен, невозможно было создать, очистить или показать ссылки для ЛЮБОГО из проектов в решении. Я обнаружил, на какой проект была плохая ссылка, выгружая проекты из решения, пока он не перестал жаловаться.

1 голос
/ 21 января 2013

Перейдите к ссылкам на свои проекты и проверьте, имеет ли один из этих проектов ссылки с меткой (недоступно).

Удалите эту ссылку и добавьте ее снова.

Это произошло со мной, и вот как я нашел решение, чтобы решить эту проблему.

0 голосов
/ 06 октября 2016

Ядерная бомба SDF.Я попытался проверить все GUID и ссылки безуспешно.Я удалил файл SDF решения, и он очистился.(SDF - это автоматически сгенерированный файл базы данных.)

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...