[ACCEPTED]-Why are my units "compiled with a different version" of my own files?-delphi-units

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 4 the dll files the "was compiled with a different 3 version" problem occurred

the problem was 2 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 1 from the dll project's search path.

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