Estoy trabajando en un proyecto web en Visual Studio 2008. Cuando presiono F12 (o hago clic con el botón derecho y selecciono Ir a definición) Visual Studio va constantemente al archivo de metadatos en lugar de ir a la fuente.

Algunos puntos:

• Todo el código fuente es C #, no hay VB.Net
• Todos los proyectos están en la misma solución.
• Todo es una referencia de proyecto en lugar de una referencia de archivo (verificado y doblemente verificado)
• He intentado el enfoque de solución de limpieza / reconstrucción (incluso hasta el punto de borrar el directorio temporal, el directorio temporal de archivos ASP.NET, etc.).

¿Alguien más ha visto este comportamiento y / o sabe cómo solucionarlo?

Bueno, otro desarrollador encontró la respuesta. El proyecto específico con el que tuvimos un problema se agregó originalmente como referencia de archivo, luego se eliminó y se agregó como referencia de proyecto. Visual Studio, sin embargo, mantuvo ambos en el archivo csproj para el sitio web, causando el problema. Entró y editó manualmente el archivo csproj para eliminar la referencia del archivo al proyecto problemático y todo está solucionado ahora

Ocurre cuando no agrega referencia como proyecto, sino que apunta a un archivo dll o exe mediante la pestaña Examinar en el cuadro de diálogo Agregar referencia. Si agrega referencia usando la pestaña Proyectos, debe ir directamente al código fuente cuando seleccione Ir a definición.

Sin embargo, si instala ReSharper , irá al código fuente incluso si agregó su referencia a un dll / exe usando la pestaña Examinar.

Parece que también debe configurarse en Resharper. Mi Visual Studio no navega al código fuente de .NET Framework hasta que lo habilite en Resharper.

1. cierra tu solución.

2. elimine el <name of the solution>archivo .suo oculto en la carpeta donde <name of the solution>existe el archivo .sln de su solución .

3. abre tu solución.

4. reconstruya su solución.

Para aquellos que usan VS 2017 (estoy en la versión 15.3.4 en este momento), estos son los pasos simples:

1. Abra su solución en el Explorador de Windows y cierre Visual Studio
2. En el menú del explorador, seleccione Ver y asegúrese de que la casilla de verificación "Elementos ocultos" esté marcada
3. Navega a la subcarpeta .vs\[your solution name]\v15
4. Borrar el .suo archivo
5. Reinicie VS y cree su solución

Eso lo arregló para mí: F12 abrió el archivo fuente real, no la versión "de metadatos".

Visual Studio a menudo sufre un problema de ir a metadatos en lugar de a su proyecto si cambia la ubicación donde está construyendo el proyecto, es decir, puede tener varias versiones para probar las cosas.

Simplemente elimine la referencia e inmediatamente agréguela de nuevo y todo se resolverá.

La solución marcada no siempre funciona. Debe asegurarse de que el GUID del proyecto al que se hace referencia en los archivos del proyecto sea el GUID correcto para el proyecto al que está intentando hacer referencia. Visual Studio les permite salir de la sincronización en algunas circunstancias. Puede obtener el GUID del proyecto desde el archivo del proyecto con un editor de texto. Entonces, si el proyecto A hace referencia al proyecto B. Abra el proyecto B.csproj en el editor de texto, copie el GUID del proyecto de la etiqueta. Luego abra el proyecto A.csproj en el editor de texto y asegúrese de estar utilizando el GUID correcto. Busque el nombre del proyecto "B" en este caso. Debería ser a las. Reemplace el GUID en la etiqueta con el correcto. Guardar y recargar. Por supuesto, también asegúrese de eliminar las referencias basadas en archivos a sus proyectos. Solo quieres referencias de proyectos.

Eliminé todas las instancias de VS, eliminé el SUO, lancé sln y funcionó para mí ...

Elimine el dll de referencia, Build (obtendrá errores), AGREGUE la referencia (que eliminó) y luego vuelva a compilar ... F12 en su función debería funcionar (funcionó para mí).

De esta publicación descubrí cómo resolver mi problema , tal vez también funcione para algunos de ustedes.

Seguí estos pasos:

1. Cierra la solución.
2. Elimine el archivo de base de datos intellisense para la solución: .ncb
3. Abre la solución.
4. Reconstruir la solución.

(Creo que el paso 3 o 4 regenera el archivo de base de datos intellisense cuando falta)

Intellisense, "ir a la definición" y "encontrar todas las referencias" debería estar funcionando nuevamente.

En mi caso, (usando Visual Studio Professional 2015), cuando había deshabilitado el diseñador XAML, el F12 dejó de funcionar. Tan pronto como revierto los cambios y reinicio Visual Studio, el F12 funcionó nuevamente.

Verificó el patrón varias veces para confirmar y luego lo publicó. Espero que ayude a alguien.

Síntoma:

Visual Studio 2010 Ultimate fallaba repetidamente en encontrar referencias a funciones, #defines, incluye, etc.

Reparar:

1. Cerrar Visual Studio
2. Elimine (cambie el nombre si desea ser conservador) el archivo .sdf de la solución
3. Reabrir Visual Studio

El archivo .sdf se reconstruirá automáticamente al analizar los archivos de inclusión en su solución

Para mí, la solución GUID no funcionó y no pude encontrar mi archivo .ncb. (O tal vez soy flojo y no me vi lo suficientemente bien, pero eso no es importante). Reconstruir y reiniciar Visual Studio tampoco ayudó.

Lo que hice fue cerrar Visual Studio y eliminar el .dll y .pdb al que se hace referencia en la parte superior del archivo Meta Data al que mi intellisense seguía vinculándose. En mi caso, significaba que eliminé mi .dll y su archivo .pdb de Utilities / bin / Release. (Utilidades es el nombre del proyecto .dll con el que estaba teniendo problemas). Luego reinicié Visual Studio y reconstruí el .dll y luego toda la solución. ¡No más problemas!

Acabo de encontrar otra causa. Actualicé mi proyecto web a 4.0 pero dejé las bibliotecas de clases en 2.0. En ese momento, todas las bibliotecas de clases en mi solución fueron tratadas como referencias de archivo de mi proyecto web. Podría ayudar a alguien más ...

Me enfrenté al mismo problema y uno de mis colegas me dio la siguiente solución y funcionó. Si nada de lo anterior funciona para usted,

1. Elimine todas las referencias y agréguelas de nuevo (asegúrese de que la ruta sea correcta)
2. Vaya a Propiedades de la solución y vuelva a comprobar las dependencias del proyecto de todos los proyectos. Asegúrese de que el proyecto que utilizará se agregue como dependiente en el proyecto en el que está trabajando.

Hice todos los pasos sugeridos, pero nada ha cambiado, luego
finalmente haga clic derecho y agregue el menú de referencia, pestaña proyecto

1. simplemente no seleccionó el proyecto de referencia.
2. Guarda la solución.
3. seleccione el mismo proyecto
4. Reconstruir la solución.

Problema resuelto. Espero que esto ayude a alguien.

Los siguientes pasos funcionaron para mí.

1. Ir al archivo .csproj
2. Ábralo en el Bloc de notas Vaya a la línea donde se hace referencia a dll.<Reference Include="">

3. Eliminar la linea

   <SpecificVersion>False</SpecificVersion> 
   or 
   <SpecificVersion>True</SpecificVersion>
   

Después de eliminar primero los archivos dll de Visual Studio y volver a agregarlos manualmente desde el Explorador de soluciones -> Sitio web -> Agregar -> Referencia y habilitar las aplicaciones de 32 bits en IIS, me lo arregló.

# 1

Marque "Ver - Explorador de objetos" y si ve más de un ensamblaje con el mismo nombre, es por eso que obtiene este error.

Para nosotros fue un error en VS 2019:

Si tiene ASP.NET "Razor helpers" en App_Code carpeta, Visual Studio 2019 lo interpreta como un ensamblaje diferente pero con el mismo nombre, que oculta el ensamblaje real.

No hay otra solución para eso que reescribir esos ayudantes en vistas parciales o ayudantes HTML (tendrá que hacerlo de todos modos si planea migrar a .NET Core).

Vea esta solución en el sitio de MS y por favor vote el error allí para que MS lo corrija

https://developercommunity.visualstudio.com/solutions/1008795/view.html (favor de votar)

# 2

Otra razón por la que se puede cargar el mismo ensamblaje dos veces en el navegador de objetos es si tiene un proyecto de prueba unitaria que inicia el proceso iis-express y nunca lo mata correctamente.

1. haga clic en el menú del sitio web de VS.
2. Añadir referencia...
3. Haga clic en la pestaña del proyecto desde el cuadro de diálogo
4. Seleccione ddl
5. Haga clic en el botón ok

En mi caso, recientemente había cambiado

<mvcBuildViews>

a "verdadero" en el archivo .csproj de mi sitio (para encontrar errores de compilación en mis archivos de vista Razor: http://forums.asp.net/t/1909113.aspx?How+to+have+Visual+Studio+2012+returned + compilar + errores + on + razor + sintaxis + error + in + asp + net + web + page + 2 + ), y cuando construí estaba recibiendo errores de mi dentro del directorio / obj / Debug / de mi sitio. Desde cualquiera de esos archivos (que estaban desactualizados), hacer clic derecho y seleccionar "Ir a la definición" me daría la versión [metadata].

Entonces, para mí, ninguna de las soluciones aquí funcionó, porque no estaba comenzando desde un archivo que estaba realmente en mi proyecto. Eliminé todo ese directorio / obj / Debug /, los errores desaparecieron, y desde cualquier archivo normal puedo usar correctamente Ir a definición.

Me encontré con este problema en VS 2013. Algo que no pude (¿no?) Aislar fue cambiar el GUID en el archivo CSPROJ. Como los archivos CSPROJ se registran en SVN, no pude simplemente cambiar el GUID en mi desarrollador local. En cambio, estaba constantemente SVN revertiendo el cambio local cada vez que sucedía.

Primero, tuve que resolver el problema cambiante de GUID.

1. Revierta el CSPROJ a la versión registrada.
2. Abra el CSPROJ a través de un editor de texto, NO VS.

3. Extraiga el valor del prístino archivo CSPROJ.

   {B1234567-5123-4AAE-FE43-8465767788ED}

4. Abra el archivo SLN a través de un editor de texto, NO VS.

5. Localice la referencia del proyecto en la solución.

   Project ("{FAE12345-3210-1357-B3EB-00CA4F396F7C}") = "Some.Project", ".... \ assemblies \ Some.Project \ Some.Project.csproj", "{B7654321-5321-4AAE- FE3D-ED20900088ED} "Proyecto final

6. El primer GUID de la lista es el GUID de la solución. Para cada proyecto referenciado en su SLN, debería ver este valor repetido en el primer argumento. El GUID que sigue al .csproj es el que desea reemplazar con el GUID prístino.

Esto debería resolver el primer problema, pero el aterrizaje "Ir a definición" en metadatos no está resuelto. En nuestro archivo SLN, hay un proyecto maestro (nuestro sitio web), por lo que su entrada en el archivo SLN debe contener una entrada ProjectSection con múltiples valores GUID. Aquí hay un ejemplo:

ProjectSection(ProjectDependencies) = postProject
{AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD} = {AC50D230-24C4-4DCA-BAAD-355E6AF5EFBD}
EndProjectSection

Observe que el GUID que falta en esta colección es el de mi proyecto original.

1. Agregue el GUID que falta como la última entrada entre ProjectSection y EndProjectSection. El formato parece ser por línea, y es {GUID} = {GUID}.
2. Guarda el archivo.
3. Abre tu solución.
4. Haga clic con el botón derecho en una referencia en el proyecto recién agregado y en "Ir a definición".

Tenía una referencia circular entre los dos proyectos involucrados (que es un no-no). Tuve que reestructurar un poco mi código para resolverlo, ya que ambos proyectos realmente dependían el uno del otro. Eliminar una de las referencias resolvió el problema intellisense. ¡Era lógicamente defectuoso y probablemente no me habría dado cuenta sin este error!

Este me funcionó:

1. Haga clic derecho en el dll en la carpeta de referencia en su explorador de soluciones
2. Eliminar el archivo dll
3. Haga clic derecho en la carpeta Referencia, luego
4. Agregue referencia al archivo dll nuevamente

Esto puede suceder si está intentando saltar a la definición en un proyecto que se ha descargado (No disponible). Haga clic derecho en el proyecto descargado y seleccione "Recargar proyecto".

La mejor suposición es que no tiene información de depuración. Tal vez tenga varias copias de su ensamblado en el disco y no tenga el archivo .pdb.

Realice una búsqueda de los nombres de ensamblaje de sus proyectos y elimínelos todos y vuelva a generarlos.