Visual Studio recuperando um caminho incorreto para um projeto de algum lugar

98

O Visual Studio (e possivelmente o TFS) de alguma forma (acho que talvez durante uma mesclagem de controle de origem) ficou confuso sobre o caminho de um projeto em minha solução.

Ele pensa que está aqui (caminhos de exemplo para simplicidade):

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

enquanto, na verdade, o arquivo do projeto está localizado aqui:

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

Não consigo por nada fazer com que ele reconheça o local correto. Eu tentei:

  • Removendo e adicionando novamente o projeto do local correto. Uma mensagem de erro aparece dizendo The project file at C:\My Projects\ExampleSolution\ExampleProjectWrong\ExampleProjectCorrect.csproj could not be found.

  • Editar manualmente o arquivo .sln para garantir que todas as referências ExampleProjectCorrect.csprojtenham os caminhos corretos.

  • Fazer uma busca em arquivos no diretório da solução para os caminhos corretos e incorretos, para tentar rastrear onde o Studio está escondendo o caminho incorreto.

  • Excluindo os diretórios de cache para VS e TFS

Estou arrancando os cabelos porque não posso recriar a solução, pois ela tem quase 100 projetos e está ligada ao controle de origem com vários outros desenvolvedores trabalhando nisso.

Alguém pode me indicar a direção certa de onde está armazenando este caminho incorreto e / ou como reiniciá-lo para que a maldita coisa carregue corretamente?

visual-studio caching tfs Charlie Drewitt
fonte
Portanto, o que acontece se você mover o projeto para o diretório ExampleProjectWrong?
Hans Passant
Ok, algum progresso ... Movê-lo para a pasta errada me permite carregá-lo no Visual Studio. Não posso mantê-lo lá, entretanto, porque o diretório 'ExampleProjectWrong' é o lar de outro projeto, contendo praticamente a mesma estrutura de pastas. Então, alguma ideia de como fazer para mudar o caminho do projeto agora que o carreguei? O campo de caminho nas propriedades do projeto descarregado está indisponível, mesmo quando o projeto é descarregado?
Charlie Drewitt,
3
Tive esse problema pela segunda vez, mas dessa vez consegui descobrir que o projeto ramificado visava a pasta original porque uso diferentes strings de conexão. Isso foi muito estranho na primeira vez, fazendo com que o visualstudio depure em arquivos da pasta de origem, e os misture com arquivos do branch, e até mesmo Log4net logado na pasta original! Será que apagar o arquivo suo solução e é agora corretamente acessando apenas os arquivos do ramificadas.
Binke
2
Eu tive o mesmo problema. Não foi tão fácil quanto excluir o arquivo suo. Tive que: 1. Remover o projeto problemático da solução. 2. Salve a solução. 3. Exclua o .suo 4. Abra a solução e adicione novamente o projeto.
SeanLAllen
1
Excluir o arquivo SUO funcionou para mim.
DanielV

Respostas:

96
  1. Vá para Gerenciar Espaços de Trabalho (por meio do menu Arquivo / Controle de Origem ou na lista suspensa de Espaço de Trabalho no Explorador de Controle de Origem)
  2. selecione editar para sua área de trabalho.
  3. Você deve ver, nas pastas de trabalho, um mapeamento do diretório de controle de origem para o diretório de projeto antigo / errado.
  4. Selecione-o e clique em remover .
  5. Feche o VS e exclua o arquivo suo.

Ainda faz referência ao diretório errado. Talvez a religação possa funcionar neste ponto, mas não tentei fazer isso. Recarregue seu projeto e você estará pronto para prosseguir.

Benjamin Potts
fonte
1
Além disso, se deixe enganar pelo link do caminho local no explorador de controle de origem. Eu tinha mais de um mapeamento para o meu espaço de trabalho e ele estava mostrando o que eu esperava lá, mas quando tentou carregar o projeto estava usando o outro caminho.
Benjamin Potts
1
O arquivo .suo está oculto, então você precisa habilitar a opção "mostrar todos os arquivos e pastas"
ANIL MANE
8
No Visual Studio 2015, encontrei o mesmo erro. O que funcionou para mim foi excluir o diretório oculto .vs e o arquivo .suo também.
Daniel Leiszen
5
Para VS2015, seu .suoarquivo pode não estar onde você pensa. Exclua aquele que está ao lado do seu .slnarquivo (não se esqueça de "mostrar arquivos ocultos") e também há um escondido em um subdiretório em .\.vs\[solution_name]\v14\.suo. Assim que tivesse os dois, poderia adicionar o projeto novamente. Ops - crédito parcial para @DanielLeiszen (acabei de notar que ele comentou a mesma coisa)
Richard Hauer
1
Tive que deletar o arquivo .suo e reiniciar o VS para que a sanidade prevalecesse
Appulus
33

Simplesmente excluir o .suoarquivo de soluções funcionou para mim.

Lloyd Powell
fonte
5
No VS2015, precisei fechar todas as instâncias do Visual Studio antes de excluir <SolutionDir>\.vs\<SolutionName>\<VsVersion>\.suofuncionou para mim.
GraehamF
12

Eu estava enfrentando esse problema depois de executar uma migração do Visual Source Safe 2005 para o TFS 2012. Eu não podia esperar pelo "Assistente de conversão" nas próximas semanas, então apenas executei VSSConvert.exe. Isso levou cerca de 6 anos de história e foi movido para o TFS .. enquanto eu não obtive o histórico real da linha do tempo .. Recebi um monte de entradas no mesmo dia com comentários indicando os check-ins reais do histórico. . não é ruim.

Então, depois de rodar a noite toda (com sucesso, yay!), Eu estava tendo problemas para carregar meus projetos exatamente como esta pergunta dizia. Por alguma razão, alguns projetos estavam sendo referenciados a um diretório incorreto. Eu verifiquei os arquivos .sln, .vsproj e obtendo o mais recente, excluindo, readquirindo, adicionando, removendo, etc. Eu tentei tudo o que foi mencionado aqui ... até mesmo atualizando meu espaço de trabalho, que eu não tenho certeza do que isso fez.

FINALMENTE ... apaguei os arquivos * .suo e o viola. Funcionou.

Passei algumas horas com este.

Hanzolo
fonte
2
Antes de excluir o arquivo * .suo, certifique-se de fechar todas as instâncias do Visual Studio e, em seguida, abra a solução novamente.
Mas
5

Uma solução ligeiramente diferente.

O TFS estava exibindo um caminho não existente para uma solução específica. Anteriormente, eu tinha um laptop com uma unidade D: separada, mas agora tenho apenas uma unidade C :. O TFS ainda achava que meu projeto estava armazenado em D: \ Project \ MikesProject

Eu não tinha um .suoarquivo para excluir, o caminho D: não foi mencionado em nenhum lugar em meus espaços de trabalho (escondido sob o File\Source Control\Advanced\Workspacesmenu), o TFS mostrou que eu tinha os arquivos mais recentes em meu (não mais existente) D: diretório e o TFS no VS2013 não tinha uma opção "Remover mapeamentos" para este projeto.

Mas o que funcionou foi simplesmente "Obter a versão mais recente" do projeto.

Depois de fazer isso, uma nova cópia do código foi gravada em minha unidade C: e (curiosamente), agora o caminho local foi mostrado sublinhado .

Anteriormente, o caminho D: não era mostrado assim.

Ímpar. Muito estranho.

Mike Gledhill
fonte
2
Exatamente a mesma situação para mim. Eu estava hesitante em puxar o gatilho e "Get Latest" por causa do caminho incorreto, mas @Mike me deu coragem!
Jonathan de
2

Tivemos problemas semelhantes com movimentos e renomeações. Excluindo os diretórios locais e, em seguida, resolvendo novamente.

Tony Hopkinson
fonte
2

Mesmo depois de excluir os .suoarquivos e .vspastas, tive que editar o .slnarquivo e remover o url relativo antigo SccProjectName#apesar de SccLocalPath#estar correto. Aparentemente, o VS também usa o nome como um caminho de dica.

Adão
fonte
1

Tente excluir ou renomear o arquivo .suo (incluindo a extensão). Este arquivo está no mesmo local onde está seu arquivo de solução. Funcionou para mim

Mandeep Janjua
fonte
0

Apenas adivinhando, mas talvez alguns de seus outros projetos façam referência ao seu projeto do local errado? Nesse caso, você não precisa apenas excluir e reinserir o projeto em sua solução, mas também excluir e recriar as referências dos projetos de referência (armazenados em seus arquivos .csproj).

Doc Brown
fonte
Obrigado pela resposta. o projeto não é referenciado por nenhum outro projeto na solução. você pode explicar por que localizar em arquivos não funcionaria? em minha experiência, se você fornecer a ele um caminho de diretório para 'Examinar', em vez de selecionar 'Solução inteira', ele pesquisará todos os tipos de arquivo, a menos que seja especificamente instruído a pesquisar apenas certos tipos de arquivo?
Charlie Drewitt,
Desculpe, você está certo, pensei que você estava usando "Localizar em arquivos" apenas para arquivos na solução, não para o diretório da solução, não entendi. Portanto, deve funcionar. Você pode dar uma descrição mais elaborada quando exatamente a mensagem de erro aparece? Isso ocorre durante a compilação, para que você possa ver qual projeto falhou?
Doc Brown,
0

Depois de tentar muitas recomendações, apaguei o arquivo suo (de novo). A última vez funcionou. Por que não funcionou antes, eu não sei. Em geral, acho que excluir o arquivo suo é uma das primeiras etapas que faço.

user3097514
fonte
0

Tive minha solução de site asp.net aberta em meu Dev Branch. Então, para algum outro propósito, abri a mesma solução na filial principal.

Fiz uma alteração em um dos meus arquivos .ascx.cs no branch dev e defini o ponto de interrupção. Quando eu executei o depurador, todos os meus pontos de interrupção foram atingidos no Dev Branch, exceto o .ascx.cs que estava atingindo o branch principal. Não tenho ideia.

Tentei limpar a pasta temporária, mas não funcionou.

O que funcionou:

Todas as instâncias fechadas do Visual Studio

Abriu a solução da filial Dev novamente.

Execute novamente e os pontos de quebra começaram a bater.

gbs
fonte
0

No meu caso, copiei o arquivo * .sln para a pasta do projeto e alterei o caminho do projeto para o arquivo * .sln. Somente isso resolveu o problema (vs 2015 sp1, projeto winservise).

Excluir * .suo não ajuda para mim.

Kamerton
fonte
0

Ainda outra solução funcionou para nós - depois de tentar deletar o suo e quase tudo mencionado neste tópico. Tínhamos um projeto na solução que mostrava uma versão fantasma do arquivo csproj. Excluímos esse arquivo e nossos caminhos corrigidos em outro projeto que estávamos tentando adicionar.

Rondakay
fonte
-1

Se você estiver executando seu aplicativo da web no IIS local em vez do IISExpress, certifique-se de clicar no botão "Criar diretório virtual" acessando as propriedades do projeto. Uma vez feito isso, execute "Solução de limpeza" e "Solução de reconstrução".

Ajinkya Surve
fonte
-1

Excluir arquivos obj e bin resolveria o problema ...

Mohanad Shamsneh
fonte
-3

Eu sei que é uma linha antiga. Eu simplesmente passei pelo mesmo problema. Recentemente, migramos o TFS, então criei um novo espaço de trabalho para mapear para o novo servidor e mantive o antigo. Sempre que abro uma solução que deveria ser direcionada para meu novo espaço de trabalho, o VS sempre tentou carregar projetos do meu antigo diretório de mapeamento, até que removi meu antigo espaço de trabalho.

BackToSorrento
fonte
isso realmente não ajuda em nada a questão inicial
vlad_tepesch
Achei que meu problema tivesse a mesma natureza. Tive dois espaços de trabalho, um dos quais é antigo. Trabalhei em um novo, criei soluções, adicionei projetos. está tudo bem somente se eu não fechei a solução. Mas se eu salvei a solução e tentasse abri-la, o VS sempre tentaria carregar projetos na solução a partir do diretório mapeado no meu antigo espaço de trabalho.
BackToSorrento