Why are my units “compiled with a different version” of my own files?

Question

I'm building a program that uses plugins. Unfortunately, the plugin framework's dynamic linking forces the RTL and VCL out of my project EXE and into the BPL versions, and they don't have debug info enabled.

So I built a testing framework that links to my plugins statically so I can actually see what I'm doing while tracing through the code. But now, every time I try to recompile, I get an error: "unit turbu_skills was compiled with a different version of turbu_database.GDatabase"

I've seen this error before, but only when I've been changing things I probably shouldn't have been, like the RTL or VCL libraries. I don't understand why it's doing that with my own code. The turbu_skills and turbu_database units are both units I wrote myself. GDatabase is a global singleton variable, whose class definition I haven't changed in weeks. Any change that triggers a recompile causes this error, even if I haven't touched anything in either of the units.

Doing a full build (SHIFT-F9) causes it to compile correctly. But if I then press SPACE in a unit (any unit) and hit F9, I get the error again. What's going on and how do I stop it? This doesn't happen in the main app, only the testing framework.

EDIT: I have the source to all of my units. Deleting DCUs and similar files doesn't help. Copying the entire project to a different computer, deleting all DCUs, and building there doesn't help. There's an objective, reproducible conflict between the layout of my program and the compiler, and I want to be rid of it.

The source can be found at http://www.turbu-rpg.com/downloads/Turbu_source_setup.exe if anyone wants to test it. It requires Delphi 2009 with the JVCL already installed; the installer package will take care of the rest. Maybe having the source code available will help someone track this down. I certainly hope so, because wherever the issue is, it's beyond me. The problem can be found in testing.exe and also in turbu.exe in turbu.groupproj.

EDIT 2: Turns out this was another cross-unit generics issue. Grr. I managed to code a workaround. I just hope they get the generics problems fixed soon.

Answer 1

The error "unit is compiled with a different version of..." is an annoying one. It occurs in a situation like below:

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

Both unit A and B use unit C and unit B uses C. Unit B and C are compiled and for some reason the source of unit B is not available. Now Unit C is changed (any change will do and is recompiled) And the dcu of unit C differs from the unit C used by unit B, so unit B needs to be recompiled too. But unfortunately, the source is not available so the compiler gives up.

It is not entirely clear what's wrong with your situation.

You have a test framework that links to the plugins. So where do unit X and Y fit in and do you recognize the pattern shown above?

But the fact that a complete build solves the problem is hint in this direction. And this is not the first time I saw problems with partial recompiles. So I always use the complete version.

Answer 2

I hate this problem. I find it pops up every now and then and although it sounds in your case to be directly related to what you are doing with plugins, I've solved this in the past by finding and deleting all the dcus, bpls and dcps of the packages that we've written and then rebuilding the packages.

Answer 3

How I solved the 'path madness' in 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

Answer 4

This happens to me very often when I forget to change the DPK Build control from Rebuild as needed to Explict rebuild in Options...|Description.

Answer 5

Check that you don't have an strained old dcu file somewhere in source dir.

Answer 6

For future reference, simply pointing the compiler to source-code versions of the "problem units" fixed this for me (i.e. adding the folders containing the source code to the search path).

Answer 7

Definitely something buggy with the compiler. I have found that altering the order of the units in the uses clause will allow you to get "one free compilation" in. After that, the error re-occurs and your back to rebuilding. :-(

Answer 8

In my case, I added the locations of the "problem" units to my project's search path. As long as it could find it, it compiled. Of course, if you have several versions of the file in question, it could complicate matters...

Answer 9

1. Your actual .dpr file contains a reference to an incorrect version of a .pas file.

   View > Project Manager > expand tree and examine the path of all the units.

2. There is a duplicate file in the list of search paths, and the incorrect version is found first

Answer 10

Unit ppParameter was compiled with a different version of ppRelatv. TppRelative :

Delete all .dcu in your program folder / your computer, then re-compile or re-build again. Then your program will running well again.

Answer 11

Are you using a modified VCL? The units you reference in your interface section also determine your interface. I would suggest making sure you do not have two different versions of any of your units with the same name (including VCL/RTL) that may be referenced from your project. Maybe it is something a silly as the background compilation is using a different version of the units then the disk compilation. So editing it triggers the background compiler, which then messes up the synchronization.

Answer 12

For me the problem was that I installed Delphi with minimum required components. And when I opened a project that was compiled with full Delphi installation it happened to me. Coping the files in the "Source" folder in Delphi installation folder from another machine with full Delphi installation solved my problem.

Answer 13

my case and solution:

• we had a main application that builds an exe file and
• some plugin projects that build dll files for this exe
  (the dll project also needs some of the applications source files)

sometimes when compiling the dll files the "was compiled with a different version" problem occurred

the problem was this:

• the exe project was setup to create all it's dcu files in a separate directory: e.g. App\DCUs
• the dll project had this DCUs directory in the search path, but also some of the application's source directories: e.g. App\Utils, App\Core, etc.
• thus, when you compiled the dll project, some of the applications source files were compiled again (now possibly with a different version of other dependencies):
  and we ended up with 2 different dcu's of the same *.pas file

the solution is easy: remove the App\DCUs directory from the dll project's search path.

Answer 14

I just had the same error message in Delphi XE. Mine was solved after closing Delphi, opening it again and recompiling my project.