¿Por qué aparece un ícono de advertencia cuando agrego una referencia a un proyecto de complemento MEF?

Deseo probar la clase principal de un complemento al hacer referencia directa al proyecto de complemento y crear una instancia de la clase de complemento. Cuando creo un proyecto de aplicación de consola de prueba y agrego una referencia de proyecto al proyecto de complemento, aparece un icono de advertencia (triángulo amarillo con signo de exclamación) junto a la referencia en la lista de Referencias.

Cuando, en cambio, agrego una referencia al dll, el resultado de comstackción de ensamblaje del complemento, no recibo tal advertencia. ¿Qué podría estar tratando de decirme esta advertencia?

Como se menciona en los comentarios de la pregunta, las diferentes versiones de .NET Framework entre los proyectos pueden causar esto. Compruebe las propiedades de su nuevo proyecto para asegurarse de que no se esté utilizando una versión predeterminada diferente.

Encontré el mismo problema con una aplicación web ASP.Net y dos proyectos de clase de biblioteca a los que se debe hacer referencia en la aplicación web. No se proporcionó información sobre por qué falló la comstackción y las referencias no eran válidas.

La solución era garantizar que todos los proyectos tuvieran el mismo Marco de objectives:

En Visual Studio 2015- Haga clic derecho en el proyecto> Propiedades> Aplicación> Marco de destino

Guarde, limpie y reconstruya la solución. Las referencias del proyecto ya no deberían aparecer como advertencias amarillas y la solución se comstackrá.

Mi aplicación web estaba orientada a .Net 4.5 mientras que los otros dos proyectos de clase de biblioteca dependientes apuntaban a .Net v4.5.2

Para ambos (o todos) los proyectos que desea usar juntos:

Haga clic derecho en el proyecto> Propiedades> Aplicación> Target .NET framework

Asegúrese de que ambos (o todos) sus proyectos estén usando la misma versión de .NET framework.

  1. Asegúrese de que todas las versiones sean las mismas para cada proyecto, haga clic en cada proyecto y vea la versión aquí. Proyecto> Propiedades> Aplicación> Marco .NET de destino.
  2. a. Vaya a Herramientas> Administrador de paquetes Nuget> Administrador de paquetes Consola Escriba Update-Package -Reinstall (si no funciona proceda a 2.b )

    segundo. Quite Maybe with multiple lines que generalmente se encuentra en la parte inferior de .csproj.

  3. Guarde, cargue y cree la solución.

Reinstale todos los paquetes en todos los proyectos de la solución actual:

Update-Package -Reinstall 

Verifique NETFramework del dll referido y el Proyecto donde está agregando el DLL. Ejemplo: DLL ==> supportedRuntime version = “v4.0” Proyecto ==> supportedRuntime version = “v3.0”

Obtendrá un ícono de advertencia. Solución: hacer una consistencia de versión dll.

Ha pasado mucho tiempo desde que se hizo esta pregunta, pero si alguien todavía está interesado, recientemente me encontré con íconos similares. Estaba comstackndo un proyecto de C # .net utilizando VS 2008. Encontré que VS no pudo ubicar los ensamblajes para esas referencias. Cuando hice doble clic en VS actualicé las referencias y eliminé los íconos en algunos de esos [EDITAR: que AHORA podría ubicar]. Para las referencias restantes, tuve que comstackr las asambleas respectivas.

Agregando mis 2 centavos a la respuesta @ kad81,

Ir a Visual Studio -> BUILD -> Configuration Manager

En la lista desplegable “Plataforma de solución activa” en la esquina superior derecha (la mía es VS 2012), si se trata de “Plataformas mixtas”, cámbiela a la plataforma adecuada en función de los ensamblajes de terceros de referencia.

Luego, en cada uno de los proyectos de la lista, asegúrese de seleccionar la misma plataforma para todo el proyecto. (Si x86 no existe, entonces seleccione “”, luego puede seleccionar “x86”).

Reconstruya primero los proyectos de la biblioteca y luego haga referencia a los proyectos. Espero que esto ayude.

Tenía estos icons por una razón diferente. Tenemos una gran solución para todos nuestros proyectos (casi 100). Hice una subselección de los proyectos en los que estaba interesado e hice una nueva solución. Sin embargo, las referencias donde el proyecto hace referencia en lugar de las referencias a los dll comstackdos …

Después de algunas investigaciones encontré este enlace en GitHub que explica que este es un nuevo comportamiento en VS2015.

En la página de GitHub explican una solución alternativa para convertir referencias de proyectos a referencias binarias.

Para arreglar algunas cosas que no funcionan, tiene sentido eliminar algunas bibliotecas a veces, ¿cómo no suena raro?

De todos modos, creo que el problema es demasiado amplio y podría ser causado por diferentes factores , por lo que quiero compartir mi situación / solución.

Tuve un proyecto (traído por el cliente) con las bibliotecas Xamarin Forms y Telerik. La cosa estaba en general relacionada con los componentes, qué bibliotecas no están incluidas en la carpeta de paquetes, ni disponibles a través de Nuget (pagas).

Las referencias del proyecto fueron “amarillas”, parecían horribles y atemorizantes.

La solución fue simplemente eliminar esas referencias de Telerik (incluidos algunos controles en el código que estaban usando eso). Inmediatamente después, todas las referencias mágicamente obtuvieron su color gris normal común y los errores (la mayoría) desaparecieron.

“Principalmente” – porque los mensajes de error “todo rojo alrededor” sobre “el elemento no está definido en ningún lado” a veces suceden. Es extraño y trae inconvenientes, pero aún puedo comstackr y ejecutar los proyectos: solo necesito limpiar la solución, reiniciar Visual Studio, rezar un poco, volver a limpiar, eliminar las carpetas obj / bin, reiniciar de nuevo, y funciona bien.

La clave es eliminar referencias de bibliotecas no disponibles , ya que los mensajes de error dicen absolutamente otra cosa. (Por ejemplo, algo como “Xamarin.Build.Download.XamarinDownloadArchives no encontrado o no se puede encontrar algo”, etc., pero eso podría significar que no tiene algunas referencias disponibles.

A continuación, elimine la carpeta de paquetes, vuelva a cargar / volver a abrir el proyecto / solución, vaya a “Administrar paquetes Nuget” y haga clic en el botón “Restaurar”.

Asegúrese de tener los proyectos orientados a la misma versión de marco . La mayoría de las veces, la razón sería que el proyecto actual (donde está agregando referencia de otro proyecto) apunta a una versión diferente de .NET Framework que los demás .

En el núcleo de Asp.net alguna vez muestra alerta si cambia el nombre del espacio o nombre del proyecto. Para eliminar este tipo de alertas, solo descarga Unload Project y vuelve a cargarlo. Si el problema persiste, significa que no puede encontrar la referencia de su Asamblea.

En mi caso, me encontré con este problema al hacer referencia a una biblioteca de clases .NET Standard 2.0 en una aplicación de consola .NET Framework 4.7.1. Sí, los frameworks son diferentes, pero son compatibles (se supone que .NET Standard interactúa con .NET Core y .NET Framework). Intenté limpiar, reconstruir, eliminar y leer la referencia del proyecto, etc … sin éxito . Finalmente, salir de Visual Studio y volver a abrir resolvió el problema.