Кто-нибудь когда-либо имел эту ошибку при попытке создать решение в Visual Studio 2008?
Это заставило меня МАД! Я удалил все содержащиеся проекты и повторно добавил их, и это все еще не позволяет мне создавать или запускать решение.
Любые предложения?
Если вы откроете файл решения (SolutionName.sln) в текстовом редакторе, вы должны создать пару строк, подобных этим для каждого проекта:
Project("{FAE04EC0-301F-11D3-BF4B-00C04F89EFBC}") = "ProjectName", "ProjectName\ProjectName.csproj", "{6B887D8C-D874-4AB2-B2CC-3551DEA2CC83}"
EndProject
Между этими линиями может быть больше материала, или в этом случае они могут каким-то образом порвать. Если вы можете изолировать запись о проблеме и удалить ее, вы сможете воскресить решение.
Я потратил пару часов на эту ошибку вчера и, к счастью, дошел до нее.
У нас был файл проекта, просто назовите его ProblemProj.vcxproj, который изначально был включен в SolutionA.sln и скомпилирован отлично. Затем проект был добавлен в другое решение SolutionB.sln и скомпилирован в этом решении. Однако, вернувшись в SolutionA, "файл проекта" был переименован, произошла ошибка.
Это произошло потому, что VS2010 решил изменить ProjectGUID проблемыProj.vcxproj. SolutionB.sln ссылается на правильный GUID, но у SolutionA.sln все еще есть ссылка на старый GUID.
Вы можете найти его в файле .sln, который выглядит примерно так:
<ProjectGuid> {271F161A-F26F-41D1-BDC8-FCF912A2F4FB} </ProjectGuid>
Проблема может быть устранена следующими способами:
1) Вручную отредактируйте GUID внутри SolutionA.sln, открыв его в текстовом редакторе и просмотрев вышеуказанную разметку.
2) Удалите проект из SolutionA.sln и повторно добавьте его; это заставило его подобрать правильный GUID и, к счастью, не решило снова его изменить.
3) Отмените изменение GUID в ProblemProj.vcxproj(что затем приведет к тому, что одна и та же ошибка произойдет в SolutionB, поэтому я бы не рекомендовал это, если SolutionB больше не имеет для вас значения).
Надеюсь, что это поможет.
Принятое решение здесь не решило его для нас. Файл .sln имел правильный путь к проекту. Вместо этого выясняется, что кто-то нажал файл .sln.cache в git, и у него был неправильный путь к проекту. Мы удалили файл .sln.cache с компьютера, и сборка работала нормально. Чтобы предотвратить это в будущем, мы удалили файл .sln.cache из git, добавили *.sln.cache в файл .gitignore.
Я просто столкнулся с той же ошибкой в VS 2012 с немного другой причиной, после загрузки решения, которое VS 2010 показалось ему довольным.
Оказывается, один проект на С++ в решении имел ссылку на неназванный проект (просто Guid, no name, no path). Хотя этот проект был загружен, было невозможно построить, очистить или показать ссылки для ЛЮБОГО из проектов в решении. Я обнаружил, что проект имел плохую ссылку, выгружая проекты из решения до тех пор, пока он не перестанет жаловаться.
Перейдите в свои Референции проектов и проверьте, нет ли одного из этих проектов с меткой (недоступен).
Удалите эту ссылку и добавьте ее снова.
Мне это показалось, и именно так я нашел решение для решения этой проблемы.
Nuke SDF. Я пробовал проверять все GUID и ссылки без успеха. Я удалил SDF файл решения, и он очистился. (SDF - это автоматически созданный файл базы данных.)