mvc - Dependencia de ensamblaje persistente en C#.NET

inyeccion de dependencias c#

Question

Mi proyecto C # - lo llamaremos SuperUI - se utiliza para hacer uso de una clase de un ensamblaje externo. Ahora no es así, pero el compilador no me permitirá construir el proyecto sin la referencia de ensamblaje en su lugar. Déjame elaborar.

Este proyecto solía arrojar y atrapar una clase de excepción personalizada, la SuperException , que se derivó de System.Exception estándar y se vivió en un ensamblado precompilado separado, SuperAssembly.DLL , al que hice referencia.

Eventualmente, decidí que se trataba de un ejercicio sin sentido y reemplacé todas las SuperExceptions con una SuperExceptions System.SuitableStandardException en cada caso. SuperException.DLL la referencia a SuperException.DLL , pero ahora me encuentro con lo siguiente al intentar compilar el proyecto:

El tipo ''SuperException'' se define en un ensamblaje al que no se hace referencia. Debe agregar una referencia al ensamblado ''SuperException, Version = 1.1.0.0 (...)''

El archivo de origen al que hace referencia el error no parece relevante; es el espacio de nombres del proyecto que se resalta en el IDE.

Ahora, aquí está la cosa:

1. Todos los usos de SuperException han sido eliminados del código del proyecto.
2. En comparación con otro proyecto que compila bien sin una referencia a SuperException.DLL , solo hago referencia a un ensamblaje más, y that no hace referencia a nada que mi proyecto no haga referencia a sí mismo. Si bien es posible que cualquiera de estas dependencias pueda lanzar SuperExceptions , solo estoy atrapando la clase Exception base y en cualquier caso ... ¡el otro proyecto funciona bien!
3. He hecho la "Solución limpia" de Visual Studio y borré todo a mano, muchas veces.

No es el fin del mundo incluir esta referencia, simplemente no veo por qué es necesario más. Nrrrgg. ¡Cualquier sugerencia bienvenida!

Answer 1

Si hace referencia a cualquier tipo que herede de SuperException (incluso si el tipo está definido en otro ensamblaje), necesita una referencia al ensamblaje en el que se define SuperException.

Secundado en eso.

Puede que no esté SuperException referencia a SuperException , pero podría estar haciendo referencia a SpecializedSuperException , que se deriva de, o de alguna manera usa SuperException , SuperException su grep del proyecto de SuperException no lo SuperException .

Intenta tener un truco con la versión de prueba de NDepend

Answer 2

1. Salga de Visual Studio
2. Elimine las carpetas bin y obj en su directorio de soluciones
3. Reinicia y mira lo que sucede

Answer 3

Como es un error del compilador, debe haber una referencia o uso de SuperException en algún lugar del proyecto.

1. Haga una búsqueda / reemplazo en todo el proyecto o solución para ese tipo y elimine todas las referencias (es posible que ya haya hecho esto).
2. Si hace referencia a cualquier tipo que herede de SuperException (incluso si el tipo está definido en otro ensamblaje), necesita una referencia al ensamblaje en el que se define SuperException.

Tome la línea en la que el compilador muestra el error y comience a rastrear el árbol de herencia de los objetos utilizados en esa línea, puede encontrar el origen de esa manera.

Answer 4

Esto suena bastante extraño. Esto es lo que verificaría a continuación:

1. Compruebe que no haya nada persistente en su archivo Properties / AssemblyInfo.cs.
2. Compruebe que no haya nada persistente en su archivo SuperUI.csproj.
3. Borre todas las referencias y vuelva a agregarlas.

Answer 5

Estoy de acuerdo con los otros comentarios aquí. ¡Hay una referencia, en texto plano en alguna parte ! He tenido problemas similares en el pasado donde la búsqueda a través de los archivos del proyecto no arrojó nada, resulta que estaba en algún otro archivo que no fue recogido automáticamente en la búsqueda.

No creo que la creación de un nuevo proyecto sea la solución aquí. Debe tener en cuenta que NINGUNA de las referencias en su árbol de dependencias usa SuperException. NINGUNO

Nunca he experimentado esto hasta el punto en que he necesitado literalmente borrar el proyecto, siempre he encontrado la referencia en alguna parte. Asegúrese de que está buscando cada archivo.

EDITAR:

Solo un punto para agregar, si la ubicación señalada por el error parece aleatoria, eso a menudo puede significar que hay una falta de coincidencia entre el origen compilado y el archivo de código fuente ... ¿Es esta una aplicación ASP.NET? Lo he tenido antes donde las DLL compiladas no han sido reemplazadas en una reconstrucción en la carpeta temporal ASP.NET haciendo que las cosas se pongan .. Interesante cuando se depura :)

Answer 6

Gracias por tus respuestas hasta ahora. Probé todas las sugerencias (excepto una) en vano.

La sugerencia que no he intentado es crear un nuevo proyecto y agregar todas mis cosas, la idea de que realmente pone a prueba mi voluntad de vivir. ;) Puedo intentar esto mañana si puedo ser molestado. Gracias de nuevo.

Answer 7

Intenta crear un nuevo proyecto y agrega todas tus clases a él.

Answer 8

Realmente no hay nada muy misterioso sobre los proyectos de VS hoy en día, son todos los archivos de texto, etc. ALGO debe hacer referencia a esa clase / dll, y ese algo debe ser parte de su proyecto.

¿Realmente has desarrollado o encontrado el árbol de la solución completa, cada archivo , para una referencia a esa excepción?

Answer 9

grep su carpeta de proyecto. Podría ser una referencia oculta en su proyecto o un proyecto al que hace referencia su proyecto. Limpiar con el Bloc de notas si es necesario.

Answer 10

Aquí es donde las herramientas como Resharper realmente dan sus frutos: un simple Find Usages usualmente me habla de tales "dependencias fantasmas" varias veces.

Tal vez podría ir a su definición de la clase SuperException e intentar encontrar todas las referencias (). También es posible que desee investigar si el ensamblaje SuperException tiene una dependencia circular en su ensamblaje principal (por ejemplo, el ensamblaje principal depende del ensamblaje de excepción, depende del ensamblaje principal ...).

Answer 11

grep -R SuperException * en la base de su proyecto (obtenga grep desde algún lugar primero) solo para estar seguro.

Answer 12

No creo que esto sea un problema de código. Lo que puedo ver que sucede es que una de sus referencias existentes probablemente dependa de ese tipo en sus propios tipos que probablemente esté creando en su aplicación.

Si ese es el caso, necesita esa referencia incluso si no usa explícitamente el tipo y aunque el otro ensamblado al que se hace referencia tenga su propia referencia. A veces obtienes ese problema con componentes de terceros que necesitan referencias a tipos a los que no has hecho referencia. El compilador obviamente está viendo algo en uno de sus ensamblajes referenciados existentes y espera que haga referencia al dependiente.

Answer 13

Es probable que sea una referencia transitiva, donde una llamada de método tipo devuelve una instancia de SuperException en caja ("downcast") como, por ejemplo, Exception, pero al inspeccionar el código en el código incluido transitivamente, es decir, el código de las llamadas a métodos externos, el compilador sabe que necesita poder tener información sobre ese tipo en algún momento.

Resharper le diría dónde es el caso que necesita agregar una referencia, y podría usar el Reflector de RedGate de Lütz Roeder para escanear IL compilados para una referencia a este tipo de dos maneras: 1) use la función de búsqueda, 2) abra cada tipo público que está utilizando y para aquel que requiere el ensamblado "fantasma", le pedirá que especifique su ubicación.

Esto me sucede con mayor frecuencia cuando hago referencia a Castle.Windsor pero no a Castle.MicroKernel. :pag

Answer 14

Tuve un problema de referencia de ensamblaje muy similar que estaba sucediendo cuando mi biblioteca de C # tenía un ensamblado C ++ / CLI dependiente. El problema era que heredaba una clase pública de ese ensamblado C ++ / CLI en mi biblioteca de ensamblaje C #. Eso significaba que la cadena de herencia abarcaba múltiples ensamblajes.

Esperaba que cualquier cliente fuera lo suficientemente inteligente como para cargar indirectamente el ensamblado C ++ / CLI cada vez que la biblioteca C # lo necesitara, pero ese no era el caso incluso en tiempo de compilación.

Me deshice de este problema al romper la herencia entre las clases que se extendían a través de esas dos librerías de ensamblado y el uso de la agregación en su lugar. Mi cliente finalmente estaba contento y ya no necesitaba el ensamblado C ++ / CLI como una dependencia.

En su palabra, probablemente tenga que asegurarse de que la SuperException de SuperException no herede de SuperException para eliminar la SuperException.DLL como referencia.

Use encapsulación en lugar de herencia y cree un miembro de datos SuperException en su nueva SuitableStandardException .

Si eso no lo resuelve, puede tener más clases que abarquen la herencia en algunos ensamblados, en su caso SuperAssembly.DLL y superException.dll .

Si no puede encontrarlos, pruebe este truco:

1. Haga que todos sus miembros públicos y clases en SuperAssembly.DLL internos.

2. En el SuperAssembly.DLL, hazte amigo de SuperException.DLL :

   [assembly:InternalsVisibleTo("SuperException, PublicKey=0024000004800000....)]

3. Asegúrese de que SuperAssembly.DLL y eliminan la referencia SuperAssembly.DLL de cualquier cliente que ya SuperException.DLL referencia a SuperException.DLL .