Visual Studio recupera una ruta incorrecta a un proyecto desde algún lugar

Simplemente eliminar el archivo solutions .suo funcionó para mí.

Me enfrenté a este problema después de realizar una migración de Visual Source Safe 2005 a TFS 2012. No podía esperar para el "Asistente de conversión" debido a cabo en las próximas semanas, así que acabo de ejecutar VSSConvert.exe. Esto tomó unos 6 años de historia y lo trasladó a TFS.. mientras que no tengo la historia real de la línea de tiempo.. Recibí un montón de entradas el mismo día con los comentarios que indican los registros reales del historial.. No está mal.

Así que después de que se ejecutó toda la noche (Con éxito, yay!), yo era tener problemas para cargar mis proyectos tal como se indica en esta pregunta. Por alguna razón, algunos proyectos estaban siendo referenciados a un directorio incorrecto. Revisé el .sln, el .archivos vsproj, y obtener la última, eliminar volver a obtener, agregar la eliminación, etc.. He intentado todo lo que he anotado aquí... incluso actualizar mi espacio de trabajo, que no estoy seguro de lo que hizo.

FINALMENTE... He suprimido el *.suo archivos y viola. Funcionó.

Una solución ligeramente diferente.

TFS estaba mostrando una ruta no existente para una solución en particular. Anteriormente, tenía una computadora portátil con una unidad D: separada, pero ahora, solo tengo una unidad C:. TFS todavía pensaba que mi proyecto estaba almacenado en D:\Project\MikesProject

No tenía un archivo .suo para eliminar, la ruta D: no se mencionó en ningún lugar de mis espacios de trabajo( enterrada en el menú File\Source Control\Advanced\Workspaces), TFS mostró que tenía los últimos archivos en mi (ya no existente) D: directorio, y TFS en VS2013 no tenían una opción" Eliminar asignaciones " para este proyecto.

Pero lo que hizo fue simplemente hacer un "Obtener la última versión" en el proyecto.

Después de hacerlo, se escribió una nueva copia del código en mi unidad C:, y (curiosamente), ahora se mostró la Ruta Local subrayada.

Anteriormente, la ruta D: no se mostraba así.

Impar. Muy extraño.

Hemos tenido problemas similares con movimientos y cambios de nombre. Eliminar los directorios locales y luego volver a resolverlo.

Incluso después de eliminar el archivo .suo y las carpetas .vs, tuve que editar el archivo .sln y eliminar la antigua url relativa de SccProjectName# a pesar de que SccLocalPath# era correcta. Aparentemente VS también usa el nombre como una ruta de pista.

Intenta borrar o renombrar .archivo suo (incluida la extensión). Este archivo está en la misma ubicación donde se encuentra su archivo de solución. Funcionó para mí.

Solo adivinando, pero tal vez algunos de sus otros proyectos hace referencia a su proyecto desde la ubicación equivocada? En este caso, no solo tiene que eliminar y volver a insertar el proyecto en su solución, también tendrá que eliminar y volver a crear las referencias de los proyectos de referencia (almacenados en su .archivos csproj).

Después de probar muchas recomendaciones borré el archivo suo ( de nuevo ). La última vez funcionó. Por qué no funcionó antes no lo sé. En general, me parece eliminar el archivo suo uno de los primeros pasos que hago.

Tenía mi asp.net solución de sitio web abierta desde mi sucursal Dev. Entonces para algún otro propósito abrí la misma solución de la rama principal.

Hice un cambio en uno de mis .ascx.archivo cs en la rama dev y establecer punto de interrupción. Cuando ejecuté el depurador, todos mis puntos de interrupción fueron golpeados en la rama Dev a excepción de la .ascx.cs que estaba golpeando la rama Principal. No tengo idea.

Intentó limpiar la carpeta temporal pero no funcionó.

Lo que funcionó:

Cerrado todo instancias de Visual Studio

Volvió a abrir la solución desde la rama Dev.

Corre de nuevo y los puntos de interrupción comenzaron a golpear.

En mi caso copié el *.archivo sln en la carpeta del proyecto y cambió la ruta al proyecto en el *.archivo sln. Solo esto resolvió el problema (vs 2015 sp1, proyecto winservise).

Borrar *.suo no me ayuda.

Si está ejecutando su aplicación web bajo IIS local en lugar de IISExpress, asegúrese de PRESIONAR el botón "Crear directorio virtual" yendo a las propiedades del proyecto. Una vez hecho esto, realice "Clean Solution" y "Rebuild Solution".

Sé que es una vieja línea. Acabo de pasar por el mismo problema. Recientemente migramos el TFS, por lo que creé un nuevo espacio de trabajo para asignar al nuevo servidor y mantuve el antiguo. Cada vez que abro una solución que se supone que debe dirigirse a mi nuevo espacio de trabajo, VS siempre trató de cargar proyectos de mi antiguo directorio de asignación, hasta que eliminé mi antiguo espacio de trabajo.