2009-01-09 17 views
9

Estoy construyendo un programa que usa complementos. Lamentablemente, el enlace dinámico del marco de plugins fuerza a RTL y VCL a salir de mi EXE de proyecto y a las versiones de BPL, y no tienen habilitada la información de depuración.¿Por qué mis unidades están "compiladas con una versión diferente" de mis propios archivos?

Así que construí un marco de prueba que enlaza a mis complementos estáticamente para que realmente pueda ver lo que estoy haciendo mientras rastreo el código. Pero ahora, cada vez que intento recompilar, aparece un error: "unit turbu_skills se compiló con una versión diferente de turbu_database.GDatabase"

He visto este error antes, pero solo cuando he estado cambiando las cosas Probablemente no debería haberlo sido, como las bibliotecas RTL o VCL. No entiendo por qué está haciendo eso con mi propio código. Las unidades turbu_skills y turbu_database son unidades que yo misma escribí. GDatabase es una variable singleton global, cuya definición de clase no he cambiado en semanas. Cualquier cambio que desencadena una recompilación causa este error, incluso si no he tocado nada en ninguna de las unidades.

Hacer una compilación completa (SHIFT-F9) hace que se compile correctamente. Pero si luego presiono SPACE en una unidad (cualquier unidad) y presiono F9, aparece el error nuevamente. ¿Qué está pasando y cómo lo detengo? Esto no ocurre en la aplicación principal, solo en el marco de prueba.

EDITAR: Tengo la fuente para todas mis unidades. Eliminar DCU y archivos similares no ayuda. Copiar el proyecto completo a una computadora diferente, eliminar todas las DCU y construir allí no ayuda. Existe un conflicto objetivo y reproducible entre el diseño de mi programa y el compilador, y quiero deshacerme de él.

La fuente se puede encontrar en http://www.turbu-rpg.com/downloads/Turbu_source_setup.exe si alguien quiere probarla. Requiere Delphi 2009 con el JVCL ya instalado; el paquete de instalación se encargará del resto. Tal vez tener el código fuente disponible ayudará a alguien a rastrearlo. Realmente lo espero, porque donde sea que esté el problema, me supera. El problema se puede encontrar en testing.exe y también en turbu.exe en turbu.groupproj.

EDIT 2: Resulta que esta fue otra cuestión de genéricos cruzados. Grr. Logré codificar una solución. Solo espero que solucionen pronto los problemas con los genéricos.

+2

Probablemente deberías escribir una respuesta con el trabajo. Ayudaría a otros que tropezaran con el mismo problema. –

+0

Gracias por el EDIT 2, me gustaría poder venir unas horas antes ... – Wodzu

+1

@Mason Wheeler - ¡12 respuestas diferentes! SIMPLEMENTE ES INCREÍBLE cuántas personas tienen (todo tipo de) problemas relacionados con la búsqueda/ruta de la biblioteca. ¡Embarcadero hizo un trabajo muy, muy pobre explicando esto! – Ampere

Respuesta

16

El error "la unidad está compilada con una versión diferente de ..." es molesto. Se produce en una situación como a continuación:

 +--------+ 
    | unit A | 
    +--------+ 
     |  | 
     |  | 
     V  | 
    +--------+ | 
    | unit B | | 
    +--------+ | 
     |  | 
     |  | 
     V  V 
    +--------+ 
    | unit C | 
    +--------+ 

Tanto unidad A y B uso unidad C y la unidad B utiliza C. Unidad B y C se compilan y por alguna razón la fuente de la unidad B no está disponible. Ahora la Unidad C se cambia (cualquier cambio se hará y se recompila) Y el dcu de la unidad C difiere de la unidad C utilizada por la unidad B, por lo que la unidad B necesita ser recompilada también. Pero desafortunadamente, la fuente no está disponible, por lo que el compilador se da por vencido.

No está del todo claro cuál es el problema con su situación.

Tiene un marco de prueba que enlaza con los complementos. Entonces, ¿dónde encajan las unidades X e Y y reconoces el patrón que se muestra arriba?

Pero el hecho de que una compilación completa resuelva el problema es una pista en esta dirección. Y esta no es la primera vez que veo problemas con recompilaciones parciales. Así que siempre uso la versión completa.

+0

Bueno, no utiliza ningún archivo que se ajuste al patrón "unidad B" y no está en el DPR para el marco de prueba, aunque "unidad B" puede ser una cadena de dependencia de más de un archivo. Voy a investigar eso. –

1

Comprueba que no tienes un viejo archivo dcu filtrado en algún lugar en el directorio de origen.

+0

No. Eliminar todas las DCU no ayudó. –

4

me gusta este problema. Me parece que aparece de vez en cuando y aunque suene en su caso para estar directamente relacionado con lo que está haciendo con los plugins, he resuelto esto en el pasado mediante la búsqueda y eliminación de todos los DCU, BPLS y dcps de los paquetes que hemos escrito y luego reconstruido los paquetes.

+1

¡Odio esto también! ¡Gracias por la pista! –

0

¿Está utilizando un VCL modificado? Las unidades a las que hace referencia en su sección de interfaz también determinan su interfaz. Sugeriría que no tenga dos versiones diferentes de cualquiera de sus unidades con el mismo nombre (incluyendo VCL/RTL) a las que pueda hacer referencia desde su proyecto. Tal vez es algo tonto ya que la compilación de fondo está usando una versión diferente de las unidades y luego la compilación del disco. Así que al editarlo se desencadena el compilador de fondo, lo que daña la sincronización.

+0

Esa es una muy buena idea, pero no es un problema aquí. –

1
  1. Su archivo .dpr actual contiene una referencia a una versión incorrecta de un archivo .pas.

    Ver> Administrador de Proyectos> expandir el árbol y examinar el camino de todas las unidades.

  2. Hay un archivo duplicado en la lista de rutas de búsqueda, y la versión es incorrecta, se encontró por primera vez

+0

Lamentablemente, no. Eso fue lo primero que revisé. Este caso específico resultó ser un error en el compilador, uno de los muchos errores cuando se trabaja con genéricos. Encontré una manera de evitarlo. –

+0

Bien entonces. Lo siento compañero:) –

1

Para referencia futura, simplemente apuntando el compilador para las versiones de código fuente de las "unidades de problemas" Me arreglé esto (es decir, agregué las carpetas que contenían el código fuente a la ruta de búsqueda).

1

Definitivamente algo buggy con el compilador. He encontrado que alterar el orden de las unidades en la cláusula uses le permitirá obtener "una compilación libre". Después de eso, el error volverá a ocurrir y su recuperación volverá. :-(

0

Para mí, el problema fue que instalé Delphi con los componentes mínimos requeridos. Y cuando abrí un proyecto que se compiló con la instalación completa de Delphi, me pasó a mí. Copia de los archivos en la carpeta "Fuente" en Delphi La carpeta de instalación de otra máquina con instalación completa de Delphi resolvió mi problema.

1

En mi caso, agregué las ubicaciones de las unidades "problemáticas" a la ruta de búsqueda de mi proyecto. Mientras lo encuentre, se compilará. , si tiene varias versiones del archivo en cuestión, podría complicar las cosas ...

1

La unidad ppParameter se compiló con una versión diferente de ppRelatv. TppRelative:

Borrar todos .dcu en la carpeta de programa/el ordenador, a continuación, volver a compilar o volver a construir de nuevo. Entonces su programa funcionará bien nuevamente.

2

Esto me pasa muy a menudo cuando me olvido de cambiar el control de DPK Construir de Reconstruir según sea necesario a EXPLICT reconstruir en Opciones ... | Descripción.

0

mi caso y la solución:

  • tuvimos una aplicación principal que construye un archivo exe y
  • algunos proyectos de plugin que se acumulan archivos dll para este exe
    (el proyecto DLL también necesita un poco de la Aplicaciones archivos de origen)

veces al compilar el archivo DLL archivos que el "se compiló con una versión diferente" problema ocurrió

el problema era el siguiente:

  • el proyecto exe fue instalado para crear todos sus archivos DCU en un directorio independiente: por ejemplo, App\DCUs
  • el proyecto dll tenía este directorio de DCU en la ruta de búsqueda, pero también algunos de los directorios de origen de la aplicación: p. App\Utils, App\Core, etc.
  • por lo tanto, al compilar el proyecto DLL, algunos de los archivos de origen de aplicaciones fueron compilados de nuevo (ahora posiblemente con una versión diferente de otras dependencias):
    y terminamos con 2 diferentes de la DCU de el mismo archivo *.pas

la solución es fácil: eliminar el directorio App\DCUs de ruta de búsqueda del proyecto DLL.

3

Cómo solucionar el 'camino de la locura' en Delphi XE7:

Rule1: Always separate the DCU from the PAS files 

    Tools -> Option -> Library path: 
       Path to global (3rd party) libraries (DCU folder) that never change. 

        c:\Delphi\Tools\FastMM\ 
        c:\MyProjects\Packages\Third party packages\$(Platform) 
        c:\MyProjects\Packages\DragDrop\$(Platform) 
        c:\MyProjects\Packages\Graphics32\$(Platform) 

    Project -> Options -> Search path: 
       Path to personal libraries, that changes often. 
       Enter the path to the DCU folder first, then path to PAS file. 
       This way, the compiler will use the DCU files first, instead of recomilin every time from PAS files. 
       It will recompile anyway if you do a Build. 

        c:\MyProjects\Packages\cCommonControls\$(Platform)_$(Config) 
        c:\MyProjects\Packages\cCommonControls\ 

    Project -> Options -> Output directory: 
       Leave it empty so the exe file is generated in project's folder 

    Project -> Options -> DCU output directory: 
       Use .\$(Platform)_$(Config) in order to enforce Rule1 
0

yo sólo tenían el mismo mensaje de error en Delphi XE. El mío se resolvió después de cerrar Delphi, abrirlo de nuevo y volver a compilar mi proyecto.

Cuestiones relacionadas