Dependencia persistente del ensamblado en C# .NET

StackOverflow https://stackoverflow.com/questions/9173

  •  08-06-2019
  •  | 
  •  

Pregunta

Mi proyecto C#, lo llamaremos SuperUI, solía hacer uso de una clase de un ensamblado externo.Ahora no es así, pero el compilador no me deja construir el proyecto sin la referencia del ensamblado en su lugar.Déjame explicarte.

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

Finalmente, decidí que era un ejercicio inútil y reemplacé todos SuperExceptions con una System.SuitableStandardException en cada caso.Eliminé la referencia a SuperException.DLL, pero ahora me encuentro con lo siguiente al intentar compilar el proyecto:

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

El archivo fuente al que hace referencia el error no parece relevante;es el espacio de nombres del proyecto el 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. Comparado con otro proyecto que se 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 generar SuperExceptions, sólo estoy capturando la clase Exception base y en cualquier caso...¡El otro proyecto funciona bien!
  3. Hice la "Solución limpia" de Visual Studio y limpié todo a mano, muchas veces.

No es el fin del mundo incluir esta referencia, simplemente ya no veo por qué es necesaria.Nrrgg.¡Cualquier sugerencia es bienvenida!

¿Fue útil?

Solución

Probablemente sea una referencia transitiva, donde alguna llamada a un método de tipo devuelve una instancia de SuperException encuadrada ("abatida") como, por ejemplo,Excepción, pero de inspeccionar el código en el código incluido transitivamente, es decircódigo de sus llamadas a métodos externos, el compilador sabe que necesita poder tener información sobre ese tipo en algún momento.

Resharper le indicaría dónde es necesario agregar una referencia, y podría usar el Reflector de Lütz Roeder, también conocido como RedGate, para escanear IL compilado en busca de una referencia a este tipo de dos maneras:1) use la función de búsqueda, 2) abra cada tipo público que esté usando y para aquel que requiera el ensamblaje "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

Otros consejos

  1. Salir de Visual Studio
  2. Elimine las carpetas bin y obj en el directorio de su solución
  3. Reinicie y vea qué sucede

Estoy de acuerdo con los otros comentarios aquí.Hay una referencia, en texto plano. en algún lugar !He tenido problemas similares en el pasado donde la búsqueda en los archivos del proyecto no arrojó nada, resulta que estaba en algún otro archivo que no se recogió automáticamente en la búsqueda.

No creo que crear un nuevo proyecto sea la solución aquí.Tienes que estar seguro de que NINGUNO de las referencias en su árbol de dependencia utilizan SuperException. NINGUNO

Nunca he experimentado esto hasta el punto de necesitar literalmente borrar el proyecto, siempre he encontrado la referencia en alguna parte.Asegúrate de estar 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 la fuente compilada 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 de ASP.NET, lo que hace que las cosas se pongan...Interesante a la hora de depurar :)

No creo que esto sea una cuestión de código.Lo que veo 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 tiene su propia referencia.A veces tienes ese problema con componentes de terceros que necesitan referencias a tipos a los que no has hecho referencia.Obviamente, el compilador ve algo en uno de sus ensamblados referenciados existentes y espera que usted haga referencia al dependiente.

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

  1. Realice una búsqueda/reemplazo en todo el proyecto o solución para ese tipo y elimine todas las referencias (es posible que ya lo haya hecho).
  2. Si hace referencia a algún tipo que hereda de SuperException (incluso si el tipo se define en otro ensamblado), necesita una referencia al ensamblado 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; es posible que encuentre la fuente de esa manera.

Gracias por sus respuestas hasta ahora.Probé todas las sugerencias (excepto una) sin éxito.

La sugerencia que no he probado es crear un nuevo proyecto y agregarle todas mis cosas, cuya idea realmente pone a prueba mis ganas de vivir.;) Puedo probar esto mañana si me molesta.Gracias de nuevo.

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

¿Realmente has buscado o encontrado todo el árbol de soluciones? cada archivo, para una referencia a esa excepción?

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

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

Intente crear un nuevo proyecto y agregarle todas sus clases.

grep la carpeta de su 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.

Si hace referencia a algún tipo que hereda de SuperException (incluso si el tipo se define en otro ensamblado), necesita una referencia al ensamblado en el que se define SuperException.

Secundado en eso.

Puede que no estés haciendo referencia SuperException, pero es posible que estés haciendo referencia SpecializedSuperException, que se deriva de, o de alguna otra manera utiliza SuperException - tu grep del proyecto para SuperException Aunque no lo captaré.

Intenta hackear con la versión de prueba de NDepende

Aquí es donde herramientas como Reafilador realmente vale la pena: una simple búsqueda de usos generalmente me informa de tales "dependencias fantasma" varias veces.

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

Tuve un problema de referencia de ensamblado muy similar que ocurría cuando mi biblioteca de C# tenía un ensamblado C++/CLI dependiente.El problema era que estaba heredando una clase pública de ese ensamblado C++/CLI en mi biblioteca de ensamblados C#.Eso significaba que la cadena de herencia se extendía a través de múltiples asambleas.

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 fue el caso ni siquiera en el momento de la compilación.

Me deshice de este problema rompiendo la herencia entre las clases que abarcaban esas dos bibliotecas de ensamblaje y usando la agregación en su lugar.Mi cliente finalmente quedó satisfecho y ya no necesitaba el ensamblado C++/CLI como dependencia.

En tu palabra, probablemente tendrías que asegurarte de que SuitableStandardException no hereda de SuperException para eliminar el SuperException.DLL como una referencia.

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

Si eso no lo resuelve, es posible que tenga más clases que abarquen la herencia en algunos ensamblajes, en su caso SuperAssembly.DLL y superException.dll.

Si no puedes encontrarlos todos, prueba este truco:

  1. Haz que todos tus miembros públicos y clases estén en SuperAssembly.DLL interno.

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

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

  3. Asegúrese de que construyan y retiren el SuperAssembly.DLL referencia de cualquier cliente que ya haga referencia SuperException.DLL.

grep -R SuperException * en la base de tu proyecto (obtén grep desde algún lugar primero) sólo para estar seguro.

Licenciado bajo: CC-BY-SA con atribución
No afiliado a StackOverflow
scroll top