Esta división ha sido aprobado por nuestros expertos para que tengas la seguridad de la veracidad de este escrito.
Solución:
Una dependencia circular es donde el Proyecto A depende de algo en el Proyecto B y el proyecto B depende de algo en el Proyecto A. Esto significa que para compilar el Proyecto A primero debe compilar el Proyecto B, pero no puede hacer eso ya que B requiere que A sea compilado . Este es el problema que causan las dependencias circulares.
Si introduce una dependencia circular en un proyecto que ya ha creado, puede ser difícil de detectar, ya que las opciones de construcción estándar no eliminan los archivos de objetos existentes, lo que le permite construir A (o B) primero. Solo lo detectará cuando pruebe en una máquina diferente que nunca haya creado la solución antes o si realiza una limpieza y compilación.
rediseñar en mi caso significará definir el mismo tipo en ambos proyectos, lo que tampoco creo que pueda ser una buena práctica.
En este caso, debe crear un tercer proyecto “C” que contenga las clases de las que dependen tanto A como B para que ya no dependan entre sí. Puede salirse con la suya simplemente dividiendo las clases para que las dependencias se puedan ordenar de esa manera sin crear el tercer proyecto.
¿Qué es una dependencia?
Para comprender qué es la dependencia circular, es mejor comprender qué es una dependencia y qué significa para el compilador.
Digamos que tiene un proyecto y, en una clase, tiene definido lo siguiente:
Public Class MyClass
'Some code here
Private MyString As String
'Some code there
End Class
Al compilar su proyecto, el compilador se ejecuta en la clase String, que se define en un archivo DLL llamado System. Luego vinculará esa DLL a su proyecto, por lo que en tiempo de ejecución, al definir o realizar operaciones en el stringSystem.dll se cargará para realizarlos.
Ahora, supongamos que tiene, más adelante en su clase, la siguiente definición
'Some code here
Private MyObjet as CustomClass1
'Some code there
y digamos CustomClass1 se define en otro proyecto suyo, llamado Project2.DLL:
Public Class CustomClass1
'Your customr class code
End Class
Entonces, al compilar su primer proyecto, el compilador se encontrará con CustomClass1 definición, sabe que se encuentra en Project2.dll y, por lo tanto, compilará Project2 antes, para poder agregar esa referencia en su primer proyecto.
Eso es una dependencia, es jerárquica, debe haber un punto de partida. Incluso la clase String depende de otras clases y, al final, todas dependen de bytes o bits para hacer el trabajo, porque eso es lo único que puede hacer una computadora, jugar con 1 y 0.
Entonces la parte circular
Entonces, si tiene, en Project2, una referencia (una definición de campo, o algo así) que se vincula a su primer proyecto, ¿qué sucede?
- El compilador lee su primer proyecto, luego se ejecuta en
CustomClass1 - Luego intenta compilar Project2, ya que CustomClass1 está definido allí.
- Luego se ejecuta en una clase definida en su primer proyecto
- Intenta compilar tu primer proyecto para vincularlo al segundo.
- Luego corre hacia
CustomClass1 - Luego trató de compilar Project2
- Supongo que lo tienes…
Entonces, en algún momento, el compilador muestra un error, diciendo que no puede compilar, ya que no entiende lo que está tratando de hacer…
Sí, las computadoras son así de estúpidas.
Cómo resolverlo ?
Resolver este tipo de problemas a veces es difícil, pero la idea básica es construir una estructura jerárquica, juntar la clase base (aquellos que no necesitan dependencias) y luego construir sobre ellos.
Tome todas las clases que dependen unas de otras y júntelas, forman una capa para algo que intenta hacer en su aplicación.
Si estás contento con lo expuesto, puedes dejar un escrito acerca de qué le añadirías a esta crónica.