quitar - ¿Por qué todas mis referencias tienen signos de exclamación amarillos en mi biblioteca de clases.NET?

cuadro azul autocad

Question

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

Nada había cambiado desde la última vez que había abierto 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 causaría 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 clases 2.0. (?)

¿Qué causaría esto y cómo puedo solucionarlo? He mirado alrededor de la web, pero solo veo que la gente ha sugerido eliminar las referencias y volver a agregarlas; Lo que he hecho, en vano.

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

¡Gracias por adelantado!

Answer 1

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

Answer 2

Compruebe si el marco .NET del proyecto es igual o mayor que el marco .Net de referencia

Answer 3

Con el Explorador de soluciones, 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.

Bajo uno de los nodos <ItemGroup> encontrará subnodos etiquetados como Reference . Asegúrese de que el valor del nodo HintPath apunta a una ruta válida. También verifique dos veces los valores SpecificVersion los nodos Versión SpecificVersion y Private .

Esperamos que la evaluación de estos valores le ayude a resolver su problema.

Answer 4

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

Answer 5

En mi caso, resulta que la dll tenía una versión diferente a la del paquete nuget. Aunque se descargó 1.1.14 y se llamó a la carpeta 1.1.14, luego de inspeccionar las propiedades 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 1.1.13 dll. Cambié el archivo csproj para indicar esto.

Answer 6

Mi problema fue la diferencia en las versiones de framework .NET de destino establecidas en los proyectos. el primero fue configurado en .NET 4.0 y el segundo fue .NET 4.5 cambiándolo resolvió mi problema

Answer 7

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

El error se produjo cuando me mudé varias veces a la ubicación física de los repositorios de paquetes predeterminados de las soluciones y cambié deliberadamente el valor de repositoryPath en el NuGet.Config

En mi caso, necesitaba eliminar un elemento cuya ruta señalada por el atributo de condición no es válida y está 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 reubica en otro lugar. A continuación, se debe actualizar este valor junto con los ItemGroups.

Answer 8

Sólo para añadir a esto. Hace poco tuve un problema en el que estaba agregando referencias que tenían TargetFramework configurado a .NET 4.0 a 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 9

Si sus archivos .dll están presentes en el control de código fuente, todo lo que debe hacer es hacer clic con el botón derecho en la carpeta Dependencias y paquetes de la solución (que se encuentra en el Explorador de control de origen) y obtener la versión más reciente.

Encontrará archivos .dll en su sistema.

Answer 10

También tengo estos errores. Estoy usando las 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 11

Tuve el mismo problema con los signos de exclamación amarillos en una pila de archivos de código fuente de una solución que está registrada / mantenida por el TFS. No había regularidad en cuanto a qué archivos tenían un signo de exclamación amarillo y cuáles no. Al investigar 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. Revisé HintPath, etc. en los archivos .csproj y todo se veía bien allí, y además, ningún otro consejo de este hilo podría ayudarme a resolver el problema.

Lo que finalmente me ayudó fue hacer lo siguiente: En explorador de soluciones, haga clic con el botón derecho en Proyecto -> Obtener versión específica ... -> (''Tipo de versión: la última versión ya está seleccionada'') -> + activar casilla de verificación ''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 que hice que todos los archivos de código fuente pudieran recuperarse con éxito del TFS y los signos de exclamación amarillos desaparecieron! Espero que esto ayude a alguien que está teniendo el mismo problema!

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 hicieron referencia a este signo de exclamación amarillo, incluso las referencias a los ensamblajes de marcos.

Lo que finalmente ayudó fue asegurar que la carpeta ".nuget" (incluyendo Nuget.Config, NuGet.exe, NuGet.targets) estuviera en la carpeta de mi solución. Luego hice "Restaurar paquetes de Nuget" en el menú contextual de la solución. Ahora todos los signos de exclamación se han ido!

Answer 13

Problema: esto es lo que sucedió conmigo, estaba asignando mi repositorio de 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 las dlls referenciadas en el La solución fue obtener el triángulo amarillo y cada vez que intentaba volver a hacer referencia a todas las DLL, seguían obteniendo la misma marca de triángulo amarillo. Solución: Reubiqué mi repositorio de TFS en una carpeta normal en C: / y así resolví el problema. Espero que esto ayude a alguien ..

PS Esto sucedió en VS 2015.