El tipo se define en un ensamblado al que no se hace referencia, ¿cómo encontrar la causa?

Sé que el mensaje de error es común y hay muchas preguntas en SO sobre este error, pero hasta ahora ninguna solución me ha ayudado, así que decidí hacer la pregunta. La diferencia con la mayoría de preguntas similares es que uso el directorio App_Code.

Mensaje de error:

CS0012: The type 'Project.Rights.OperationsProvider' is defined in an
assembly that is not referenced. You must add a reference to assembly
'Project.Rights, version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.

Archivo fuente:

c:\inetpub\wwwroot\Test\Website\App_Code\Company\Project\BusinessLogic\Manager.cs

Siguiendo las sugerencias aquí y aquí , he eliminado todas las instancias de Project.Rights.dll dentro de C: \ Windows \ Microsoft.NET /*.* De acuerdo con esto , verifiqué si los archivos .cs en cuestión tienen la acción de compilación establecida en "Compilar" . Ellas hacen. También he comprobado dos veces que el archivo .cs que contiene el tipo "Project.Rights.OperationsProvider" esté implementado en el directorio App_Code.

Por alguna razón, la aplicación no busca el tipo en el directorio App_Code. Como eliminé todas las instancias de Project.Rights.dll (que yo sepa), no sé qué ensamblaje menciona el mensaje de error.

Cuando recibe este error, no siempre es obvio lo que está sucediendo, pero como dice el error, le falta una referencia. Tome la siguiente línea de código como ejemplo:

MyObjectType a = new MyObjectType("parameter");

Parece bastante simple y probablemente haya hecho referencia a "MyObjectType" correctamente. Pero digamos que una de las sobrecargas del constructor "MyObjectType" toma un tipo al que no se ha hecho referencia. Por ejemplo, hay una sobrecarga definida como:

public MyObjectType(TypeFromOtherAssembly parameter) {
    // ... normal constructor code ...
}

Ese es al menos un caso en el que obtendrá este error. Por lo tanto, busque este tipo de patrón en el que haya hecho referencia al tipo, pero no a todos los tipos de propiedades o parámetros de método que son posibles para las funciones que se llaman en ese tipo.

¡Espero que esto al menos te ayude a ir en la dirección correcta!

Verifique el marco objetivo en los proyectos.

En mi caso, "Debe agregar una referencia al ensamblaje" significaba en realidad que los proyectos de referencia y de llamada no tenían el mismo marco de destino. El proyecto de la persona que llama tenía .Net 4.5, pero la biblioteca referenciada tenía el objetivo 4.6.1.

Estoy seguro de que el compilador de MS puede ser más inteligente y registrar un mensaje de error más significativo. Agregué una sugerencia a https://github.com/dotnet/roslyn/issues/14756

En mi caso, esto se debió a que al realizar una actualización del paquete NuGet solo se actualizaron las referencias a una dependencia de dll en algunos proyectos de mi solución, pero no en todos , lo que resultó en versiones en conflicto. Usando una herramienta de estilo grep para buscar texto dentro de archivos * .csproj en mi solución, fue fácil ver los proyectos que aún necesitaban actualizarse.

Cuando recibe este error, significa que el código que está usando hace una referencia a un tipo que está en un ensamblado, pero el ensamblado no es parte de su proyecto, por lo que no puede usarlo.

Eliminar Project.Rights.dll es lo opuesto a lo que desea. Debe asegurarse de que su proyecto pueda hacer referencia al ensamblaje. Por lo tanto, debe colocarse en la caché de ensamblados global o en el directorio ~ / Bin de su aplicación web.

Editar: si no desea utilizar el ensamblado, eliminarlo tampoco es la solución adecuada. En su lugar, debe eliminar todas las referencias a él en su código. Dado que el ensamblado no es necesario directamente por el código que ha escrito, sino por otra cosa a la que hace referencia, tendrá que reemplazar ese ensamblado al que se hace referencia con algo que no tenga Project.Rights.dll como dependencia.

En mi caso, estaba haciendo referencia a una biblioteca que se estaba construyendo con la plataforma / configuración incorrecta (acababa de crear la biblioteca referenciada).

Además, no pude solucionar el problema en Visual Studio Configuration Manager, no pude cambiar y crear nuevas plataformas y configuraciones para esta biblioteca. Lo arreglé corrigiendo las entradas en la ProjectConfigurationPlatformssección del .slnarchivo para ese proyecto. Todas sus permutaciones se establecieron en Debug|Any CPU(no estoy seguro de cómo lo hice). Sobrescribí las entradas del proyecto roto con las de un proyecto en funcionamiento y cambié el GUID de cada entrada.

Entradas para proyecto en funcionamiento

{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64 {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64

Entradas para proyecto dañado

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Debug|Any CPU {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Debug|Any CPU

Entradas dañadas ahora arregladas

{94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.ActiveCfg = Release|x64 {94562215-903C-47F3-BF64-8B90EF43FD27}.Release|x64.Build.0 = Release|x64

Espero que esto ayude a alguien.

Me acaba de ocurrir que diferentes proyectos hacían referencia a diferentes copias de la misma dll. Me aseguré de que todos hicieran referencia al mismo archivo en el disco y el error desapareció como esperaba.

No funcionó para mí cuando intenté agregar la referencia desde la pestaña .NET Assemblies. Sin embargo, funcionó cuando agregué la referencia con BROWSE a C: \ Windows \ Microsoft.NET \ Framework \ v4.0.30319

una de las razones principales puede ser la propiedad de DLL, antes de hacer cualquier cosa para verificar specific version propertysi es verdadero, hacerlo falso

Razón: tal vez el código fuente se unió a otra versión (antigua) cuando la compila, pero esta biblioteca se actualizó con una nueva actualización, la versión ahora es diferente en Assembly Cash y su aplicación no puede obtener una nueva DLL, y después de deshabilitarla, specific version propertysu applacaten será gratuita. para obtener la nueva versión de referencias DLL

Quizás una biblioteca (archivo DLL) que está utilizando requiera otra biblioteca. En mi caso, hice referencia a una biblioteca que contenía un modelo de entidad de base de datos, pero olvidé hacer referencia a la biblioteca del marco de la entidad.

Esto también puede significar que usa una biblioteca, que expone tipos (públicos) que están definidos en una biblioteca. Incluso cuando no los use específicamente en su biblioteca (la que no construye).

Lo que esto probablemente evita es que escriba código que use una clase (que en su firma tiene los tipos de una biblioteca sin referencia) que no puede usar.

Para mí, la razón por la que apareció el error fue que el WebForm donde se informó el error se movió de otra carpeta, pero el nombre de su clase de archivo de código no se modificó y no se correspondía con la ruta real.

Estado inicial
: Ruta del archivo original: /Folder1/Subfolder1/MyWebForm.aspx.cs Nombre de clase del archivo de código
original: Folder1_Subfolder1_MyWebForm

Después de mover el
archivo: Ruta del archivo: /Folder1/MyWebForm.aspx.cs Nombre de la clase del archivo de
código (sin cambios, con el error mostrado): Folder1_Subfolder1_MyWebForm

La solución: cambie el
nombre de su clase de archivo de código Folder1_Subfolder1_MyWebForm
a una que corresponda con la nueva ruta :Folder1_MyWebForm

Todo a la vez: problema resuelto, sin informes de errores.

El tipo 'Domain.tblUser' se define en un ensamblado al que no se hace referencia. Debe agregar una referencia al ensamblado 'Dominio, Versión = 1.0.0.0, Cultura = neutral, PublicKeyToken = null'.

**Solved:**
 Add reference of my domain library layer to my web app libary layer

Nota: asegúrese de que sus referencias sean correctas de acuerdo con su contenedor DI

En mi caso esto fue porque usé

Operador implícito

entre BLLy DALclases. Cuando quiero usar la BLLcapa en la capa de aplicación, aparece este error. Cambié

operador implícito

a

operador explícito

estará bien. Gracias

En mi caso, la versión de la dll a la que se hace referencia era en realidad más nueva que la que tenía antes.

Solo necesitaba volver a la versión anterior y eso lo solucionó.

Para mí, esto se debió a que el proyecto tanto directa como indirectamente (a través de otra dependencia) hacía referencia a dos compilaciones diferentes de Bouncy Castle que tenían diferentes nombres de ensamblado. Una de las compilaciones de Bouncy Castle fue el paquete NuGet, la otra fue una compilación de depuración de la fuente descargada de GitHub. Ambos eran nominalmente la versión 1.8.1, pero la configuración del proyecto del código de GitHub establece el nombre del ensamblado en BouncyCastle mientras que el paquete NuGet tenía el nombre del ensamblado BouncyCastle.Crypto. Cambiar la configuración del proyecto, alineando así los nombres de ensamblaje, solucionó el problema.

Tengo un problema similar, elimino RuntimeFrameworkVersion y el problema se solucionó.

Intente eliminar 1.1.1 o

Tuve este problema en una solución recién creada que usaba proyectos existentes. Por alguna razón, un proyecto no podía "ver" otro proyecto, a pesar de que tenía la misma referencia que todos los demás proyectos, y el proyecto referenciado también se estaba construyendo. Sospecho que no pudo detectar algo que tenga que ver con múltiples marcos de destino, porque se estaba construyendo en un marco pero no en el otro.

La limpieza y la reconstrucción no funcionaron y reiniciar VS no funcionó.

Lo que terminó funcionando fue abrir un "Símbolo del sistema de desarrollador para VS 2019" y luego emitir un msbuild MySolution.slncomando. Esto se completó con éxito, y luego VS comenzó a construir con éxito también.

Limpiar su solución y reconstruir funcionó para mí (en Visual Studio, estas son opciones que obtiene cuando hace clic derecho en el explorador de soluciones), el error desapareció en mi proyecto.