c# - El tipo se define en un ensamblaje al que no se hace referencia, ¿cómo encontrar la causa?
asp.net .net (16)
El tipo ''Domain.tblUser'' se define en un conjunto al que no se hace referencia. Debe agregar una referencia al ensamblado ''Domain, Version = 1.0.0.0, Culture = 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 según su contenedor DI
Sé que el mensaje de error es común y hay muchas preguntas sobre SO sobre este error, pero ninguna solución me ha ayudado hasta ahora, así que decidí hacer la pregunta. La diferencia con la mayoría de las preguntas similares es que yo use 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 here y here , he eliminado todas las instancias de Project.Rights.dll dentro de C: / Windows / Microsoft.NET /*.* De acuerdo con this , verifiqué si los archivos .cs en cuestión tenían una 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" se implementa en el directorio App_Code.
Por algún motivo, 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é ensamblado está mencionando el mensaje de error.
Compruebe el marco de destino en los proyectos.
En mi caso, "Debes agregar una referencia al ensamblado", en realidad significaba que el llamador y los proyectos de referencia no tenían el mismo marco de destino. El proyecto de llamante tenía .Net 4.5, pero la biblioteca a la que se hacía referencia 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. He agregado una sugerencia a https://github.com/dotnet/roslyn/issues/14756
Cuando obtiene 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 lo suficientemente simple y probablemente haya hecho referencia a "MyObjectType" correctamente. Pero digamos que una de las sobrecargas para el constructor "MyObjectType" toma un tipo que no tiene 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 donde ha hecho referencia al tipo pero no a todos los tipos de propiedades o parámetros de método que son posibles para las funciones a las que se llama en ese tipo.
¡Espero que esto al menos te lleve en la dirección correcta!
Cuando obtiene este error, significa que el código que está utilizando hace referencia a un tipo que está en un ensamblaje, pero el ensamblaje no es parte de su proyecto, por lo que no puede usarlo.
La eliminación de Project.Rights.dll es lo contrario de lo que desea. Debe asegurarse de que su proyecto pueda hacer referencia al ensamblaje. Por lo tanto, debe colocarse en Global Assembly Cache o en el directorio ~ / Bin de su aplicación web.
Editar: si no desea usar el ensamblaje, eliminarlo tampoco es la solución adecuada. En su lugar, debe eliminar todas las referencias a él en su código. Como el ensamblado no es necesario directamente por el código que ha escrito, sino por otra cosa a la que hace referencia, deberá reemplazar ese ensamblaje al que se hace referencia por algo que no tenga Project.Rights.dll como dependencia.
En mi caso esto fue porque utilicé
Operador implícito
entre BLL y DAL classes.When quiero utilizar BLL Layer In Application Layer Obtuve este error. Cambié
operador implícito
a
operador explícito
esta bien Gracias
En mi caso, esto se debía a que al hacer una actualización del paquete NuGet solo había actualizado las referencias a una dependencia dll en algunos, pero no en todos los proyectos de mi solución, lo que daba como resultado versiones contradictorias. Utilizando una herramienta de estilo grep para buscar texto dentro de los archivos * .csproj en mi solución, fue fácil ver los proyectos que aún necesitaban ser actualizados.
En mi caso, la versión del dll al que se hizo referencia era en realidad más nueva que la que tenía antes.
Solo necesitaba retroceder a la versión anterior y eso lo solucionó.
En mi caso, me estaba refiriendo a una biblioteca que se estaba construyendo en la Plataforma / Configuración incorrecta (yo 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 sección ProjectConfigurationPlatforms del archivo .sln para ese proyecto. Todas sus permutaciones estaban configuradas en Debug|Any CPU (no estoy seguro de cómo lo hice). Sobreescribí las entradas del proyecto roto con las de un proyecto en funcionamiento y cambié el GUID para cada entrada.
Entradas para el proyecto de funcionamiento
{9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.ActiveCfg = Release|x64 {9E93345C-7A51-4E9A-ACB0-DAAB8F1A1267}.Release|x64.Build.0 = Release|x64
Entradas para el 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 corruptas ahora corregidas
{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.
Esto también puede significar que usa una biblioteca, que expone tipos (públicos) definidos en una biblioteca. Incluso cuando no los usa específicamente en su biblioteca (la que no se compila).
Lo que probablemente evite es escribir código que utiliza una clase (que en su firma tiene los tipos de una biblioteca no referenciada) que no puede usar.
Limpiar su solución y reconstruir funcionó para mí (en Visual Studio, estas son las opciones que obtiene cuando hace clic derecho en su explorador de soluciones), el error se ha ido en mi proyecto.
Para mí, el motivo por el cual apareció el error fue que el WebForm donde se informó el error se movió desde otra carpeta, pero el nombre de su clase del archivo de código permaneció sin cambios 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 Folder1_Subfolder1_MyWebForm código Folder1_Subfolder1_MyWebForm
a uno correspondiente a la nueva ruta : Folder1_MyWebForm
Todo a la vez - problema resuelto, sin errores de informe ..
Para mí, esto fue causado por el proyecto, tanto directa como indirectamente (a través de otra dependencia) haciendo referencia a dos construcciones diferentes de Bouncy Castle que tenían diferentes nombres de ensamblado. Una de las compilaciones de Bouncy Castle era el paquete NuGet, la otra era 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 GitHub estableció el nombre del ensamblado en BouncyCastle, mientras que el paquete NuGet tenía el nombre de conjunto BouncyCastle.Crypto. Al cambiar la configuración del proyecto, alineando así los nombres de los ensamblajes, se solucionó el problema.
Simplemente me sucedió que diferentes proyectos se referían a diferentes copias del mismo dll. Me aseguré de que todos hicieran referencia al mismo archivo en el disco, y el error desapareció como esperaba.
Tal vez una biblioteca (archivo DLL) que está utilizando requiere otra biblioteca. En mi caso, me referí a una biblioteca que contenía un modelo de entidad de base de datos, pero me olvidé de hacer referencia a la biblioteca del marco de la entidad.
Tengo un problema similar y elimino RuntimeFrameworkVersion, y el problema se solucionó.
Intenta eliminar 1.1.1 o
uno de los principales motivos puede ser la propiedad de DLL que debe antes de hacer algo para verificar la specific version property si es verdad hacerla falsa
Motivo: tal vez el código fuente se unió con otra versión (anterior) cuando lo compila, pero esta Biblioteca actualizó con la nueva actualización la versión ahora diferente en el Ensamble Efectivo y su aplicación prohíbe obtener una nueva DLL, y luego de deshabilitar la specific version property su applacaten será libre de obtener la nueva versión de las referencias de DLL