¿Por qué todas mis referencias tendrán un signo de exclamación amarillo en mi biblioteca de clases .NET?

Question

He estado desarrollando una biblioteca de clases durante bastante tiempo y de repente, en algún momento la semana pasada, abrí mi proyecto y todas mis referencias tienen signos de exclamación amarillos sobre ellos ahora (System.dll, System.Drawing.dll, etc.). Intenté eliminar las referencias y volver a agregarlas para corregir las rutas de referencia rotas, pero continúan mostrando signos de exclamación amarillos en ellas.

Nada había cambiado desde la última vez que abrí el proyecto. Lo único diferente de la última vez que abrí el proyecto fue que esta vez lo abrí directamente desde .NET desde otro proyecto. Por ejemplo, estaba trabajando en un proyecto web .NET 3.5, luego hice clic en Archivo -> Abrir archivos recientes -> Mi Otra Solución. Esto cerró mi actual solución web 3.5 actual y abrió la solución de biblioteca de clase 2.0 y el problema apareció por primera vez. No estoy seguro de cómo (o por qué) esto podría causar un problema, pero me inclino por el hecho de que Visual Studio se confundió o algo así y ahora mis ensamblajes no son válidos en este proyecto de biblioteca de clase 2.0. (?)

¿Qué podría causar esto y cómo puedo solucionarlo? He buscado en la web, pero solo veo que las personas han sugerido eliminar las referencias y volver a agregarlas; lo cual hice, fue en vano.

Estoy considerando comenzar un nuevo proyecto y copiar todos mis archivos fuente uno por uno, pero realmente me gustaría evitar todo esto si es posible.

¡Gracias de antemano!

Answer 1

Usando Solution Explorer, haga clic con el botón derecho del mouse y seleccione Descargar proyecto y luego seleccione Editar (nombre de su archivo csproj) para poder editar el archivo .csproj directamente en VS.

Debajo de uno de los nodos <ItemGroup> se encuentran los subnodos etiquetados Reference. Asegúrese de que el valor del nodo HintPath apunta a una ruta válida. También verifique dos veces los nodos SpecificVersion y Private para obtener valores válidos.

Afortunadamente la evaluación de estos valores le ayudará a resolver su problema.

Answer 2

Solo para agregar a esto. Recientemente tuve un problema en el que estaba agregando referencias que tenían TargetFramework establecido en .NET 4.0 para un proyecto de Visual Studio 2008. Todo lo que obtienes es un signo de exclamación amarillo y una explicación.

¡Una vez que me di cuenta de que elegí los binarios de lanzamiento incorrectos parecía obvio!

Answer 3

Si sus archivos .dll están presentes en el control de código fuente, todo lo que necesita hacer es hacer clic derecho en la carpeta Dependencias y paquetes desde la solución (que está bajo el Control Explorer) y obtener la última versión del mismo.

Encontrará archivos .dll en su sistema.

Answer 4

Tuve el mismo problema con los signos de exclamación amarillos en un bounch de archivos de código fuente de una solución que está registrada/mantenida por el TFS. No hubo regularidad en cuanto a qué archivos tenían realmente un signo de exclamación amarillo y cuáles no. Investigando la causa de este problema, pude ver que esos archivos con signos de exclamación amarillos en realidad ni siquiera se recuperaron del TFS en mi disco duro. Comprobé HintPath, etc. en archivos .csproj y todo parecía estar bien allí, y tampoco ningún otro consejo de este hilo me podría ayudar a resolver el problema.

LO QUE FINALMENTE ME AYUDÓ fue hacer lo siguiente: En el explorador de soluciones, haga clic derecho en Proyecto -> Obtener versión específica ... -> ('Tipo de versión: la última versión ya seleccionada') -> habilitar casilla ' Sobrescribir todos los archivos, incluso si la versión local coincide con la versión especificada '-> haga clic en el botón' Obtener '

¡Después de hacerlo todos los archivos de código fuente pudieron ser recuperados correctamente del TFS y los signos de admiración desaparecieron! ¡Espero que esto ayude a alguien que está teniendo el mismo problema!

Answer 5

También recibí estos errores. Estoy usando bibliotecas de Nuget en mi proyecto. Después de tomar una actualización del paquete Microsoft.Bcl, todos los errores de referencia se resolvieron.

Answer 6

En mi caso, la solución mencionada anteriormente no funcionó. No estoy seguro de cómo mi plataforma se cambió a AnyCPU. Estaba usando sqlite en el proyecto. Luego acabo de cambiar la plataforma a x86/arm para el emulador/dispositivo. Funcionó de nuevo como un encanto. Espero, ayuda a alguien.

Answer 7

mi problema era la diferencia en las versiones de .NET Framework objetivo establecidas en los proyectos. el primero se estableció en .NET 4.0 y el segundo fue .NET 4.5 al cambiarlo resolvió mi problema

Answer 8

Cambie el marco DotNet de destino para que sea el mismo entre los dos proyectos y todo funcionará bien. (Especialmente si "actualiza")

Answer 9

Tengo el mismo problema con un proyecto abierto recientemente en Visual Studio 2015.

El error salió cuando he reubicado un par de veces la ubicación física de los repositorios de paquetes de soluciones predeterminadas y cambiado deliberadamente el valor de la repositoryPath en el NuGet.Config

En mi caso, necesitaba para eliminar un elemento cuya ruta apuntada por el atributo de condición no es válida que se encuentra dentro de la sección Destino del archivo csproj.

<Error Condition="!Exists('..\..\..\..\..\Packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets')" 
     Text="$([System.String]::Format('$(ErrorText)', '..\..\..\..\..\Packages\Microsoft.Bcl.Build.1.0.21\build\Microsoft.Bcl.Build.targets'))" /> 

Además, este error se reproduce cuando la carpeta del paquete habitual se elimina o se traslada a otro lugar. Uno debería entonces actualizar este valor junto con el ItemGroups.

Answer 10

tiempo del cheque el marco del proyecto .NET es igual o mayor que la referencia de .NET Framework

Answer 11

Problema: Esto es lo que pasó conmigo, me mapeo mi repositorio TFS a una carpeta en C: \ Users \ myUserNameFolder \ El "myUserNameFolder" tiene permisos especiales por el hecho de que es una carpeta del sistema, debido a que los dlls referenciados en la solución obtenían el triángulo amarillo y cada vez que intentaba volver a referenciar todos los dlls, seguían recibiendo el misma marca de triángulo amarillo. Solución: Remapeé mi repositorio de TFS a una carpeta normal en C: \ y eso fue suficiente. Espero que esto ayude a alguien ..

P.S. Esto sucedió en VS 2015.

Answer 12

Tuve el mismo problema, después de copiar las carpetas de proyectos de otro proyecto como punto de partida para una nueva solución.

Todos los proyectos hacen referencia a este signo de exclamación amarillo, incluso a las referencias a ensamblajes de estructura.

Lo que finalmente ayudó a era garantizar, que el carpeta ".nuget" (Incluyendo Nuget.Config, NuGet.exe, NuGet.targets) estaba en mi carpeta de soluciones. Luego hice "Restaurar paquetes Nuget" en el menú contextual de la solución. ¡Ahora todas las exclamaciones se han ido!

Answer 13

En mi caso resulta que el dll tenía una versión diferente que el paquete nuget. Aunque se descargó 1.1.14 y la carpeta se llamó 1.1.14, al inspeccionar las propiedades de dll (en la pestaña de detalles), noté que era la versión 1.1.13.

Por lo tanto, mi csproj tuvo que hacer referencia a una carpeta 1.1.14, pero a una 1.1.13 dll. Cambié el archivo csproj para indicar esto.