The error I get is like this:
[DCC Fatal Error] myunit3.pas(244): E2411 Unit XBAT in package B_Dsgn refers to unit QBEE which is not found in any package. Packaged units must refer only to packaged units
I need to know what this error I am encountering really means, and if possible how to troubleshoot and solve such problems, especially when the facts stated in the error message are not correct (the units are in fact referring to other units in other valid packages).
Such problems involve package dependencies. I am having an interesting problem with a series of three designtime and three runtime packages related like this:
What is most odd about it is that each time I clean and rebuild, I get a different unit name in the error. (Shown above as Unit XBAT refers to unit QBEE).
The other odd thing is that it's referring to units that are in a top level dependency, and are part of a package that was already built.
Steps;
Compile A, it works.
Compile A_Dsgn, it works.
Compile B, it Works.
Compile B_Dsgn, it works.
Compile C, and it fails with this E2411 error.
Since I doubt anybody can tell me how to fix this exactly, I am looking for the steps to troubleshoot a complex dependency problem in a package. The literal meaning of the above error suggests for example, that I should have a corresponding message about an implicit linked unit, which I do not have. I have added all implicitly used units to the base packages A, and B, so that no implicit unit warnings are made.
My next idea was to separate the DCU output folders for each package, to prevent the DCU outputs from one from confusing the compiler. Now I can not even build the packages.
Update I tried playing with the Explicit Rebuild and Rebuild as Needed options. I have found that this error is related to having 'Rebuild as Needed' turned on. When it is turned off, the packages fail with other errors which are more to the point. I find it odd that the compiler emits weird errors that can be disabled by turning off Rebuild as needed. Any ideas what is going on?
Update 2 The basic underlying problem is not solved by turning on or off explicit rebuild. Instead of getting this error, I get annoying runtime/designtime package problems, which result in a set of packages, that can not be loaded at the same time. (Can not load package foo because it contains unit bar which is also in package bat. Do you want to attempt to load this package the next time a project is loaded?).
I suspect it is an obscure compiler bug.
The project I experienced it in had at least 4 levels of dependent runtime packages:
PackageA <- PackageB <- PackageC <- PackageD
E2411 Unit '%s' in package PackageD refers to unit '%s' which is not
found in any package. Packaged units must refer only to packaged units.
The only solution I found that worked was to make packages A, B and C never-build (i.e. Explicit Build) packages and use Project Dependencies to enforce build order instead. I had to make all three never-build or I would get
E2220 Never-build package '%s' requires always-build package '%s'
I know its probably not the answer you were looking for but there it is.
Btw, this happened to me in Delphi 2009.
It is quite simple: If a unit in C refers to a unit not in any package referred to by package C, that unit should be included in C, or the package in which it can be found should be referenced by C. If necessary, put the unit in a package of its own.
Where you put which unit depends on the dependencies. It makes sense to draw it out, like you did, but with a unit level resolution.
Update
Your update 1 and update 2 still make me think there is a unit one of your units uses (directly or indirectly) that is not properly referenced. Perhaps even an RTL or VCL unit. Since you have design packages, I assume you have components in them.
IME, the minimum set of packages to include is
requires
rtl,
designide,
vcl,
vclactnband,
vclx,
xmlrtl;
In the project that gives the error must be added as required the. dcp error.
In your case:
[DCC Fatal Error] myunit3.pas (244): E2411 Unit in package B_Dsgn XBAT Refers to unit QBEE Which is not found in Any package. Must Refer Packaged units only to packaged units
In the package where it myunit3.pas drive, add in required: QBEE
At least I managed to do so.
You are using the QBEE unit in the unit XBAT, in this case you have foure options:
1- you didn't add the QBEE to the contains list in the Package B_Dsgn.
2- If QBEE is already containd in another Package lets call it Original_Package then you should add the Package to the requires list in B_Dsgn and not contain the unit.
3- the Original_Package has
{$IMPLICITBUILD ON}
in it's dpk file so first what you have to do is to turn IMPLICITBUILD off and build Original_Package after that you can build your B_Dsgn package.
4-you probably didn't have XBAT in B_Dsgn but you have it in another middle package lets call it B_Run and you have B_Run in the requires list of B_Dsgn, in this case try first to fix B_Run with one of the upper three options and then build it, after that you can build B_Dsgn.
Note:
the last two cases could be reproduced with a long list of units and not just two or three packages that are requiring each other, in this case all of the packages should have IMPLICITBUILD off.
Clean the code for every single package of the packages that effect the issue before building them.
good luck
Related
Delphi 10 Seattle introduces Winapi.Security.pas. The project (a package) I'm trying to upgrade already has a Security.pas file. Short of removing Winapi from the list of scope names for the project (huge undesirable ripple effect), is there a way to tell the IDE and compiler to use the project's Security.pas file instead of Winapi.Security.pas?
I already tried renaming the projects Security.pas, but that caused even more problems with the compiler generating errors that have nothing to do with the code it was complaining about, so that's a rathole I'd rather not go down right now. This project builds just fine unchanged in XE7, FWIW, so this isn't due to any code changes in the project.
Updates:
Renaming the file and using a unit alias doesn't work.
The compiler behavior for a package differs from an application.
Looks like this might actually be related to the Winapi.Security unit rather than something as generic as you suggest in the question. For instance, the following package compiles just fine:
package Package1;
requires
rtl;
contains
Windows in 'Windows.pas'; // blank unit named Windows.pas in project folder
end.
Note that I have, like you, included Winapi in the project's list of unit scope names.
On the other hand, this package does not compile:
package Package1;
requires
rtl;
contains
Security in 'Security.pas'; // blank unit named Security.pas in project folder
end.
The compiler fails with:
[dcc32 Error] Package1.dpk(7): E2200 Package 'rtl' already contains unit 'Winapi.Security'
If the issue was purely related to unit scope names then either both packages would compile, or both would fail. Hence my conclusion that there is something out of whack with Winapi.Security.
I can find no source code for Winapi.Security. I wonder what it actually is. [Nicholas Ring located the source for me, inside the rtl\win\winrt directory.]
Anyway, I think it's time to submit a QP report. The package below that fails to compile is probably the starting point for that QP report. [Your submitted report is here RSP-12469.]
It seems clear to me that in the short term you must rename your unit if you wish to adopt Seattle.
FWIW, here are some other units that behave the same way as Winapi.Security:
Winapi.ApplicationModel
Winapi.CommonTypes
Winapi.Devices
Winapi.Foundation
Winapi.Gaming
Winapi.Globalization
Winapi.GraphicsRT
Winapi.Management
Winapi.Media
Winapi.Networking
Winapi.Storage
Winapi.UI
Winapi.WebRT
These are all newly added WinRT units which I expect is important.
If you put both Winapi.Security and your local Security in the same uses clause then you are able to access the members of both of them without issue. If you put them in separate uses clauses (Interface vs. Implementation) then you will get the error:
E2004 Identifier redeclared: 'Winapi.Security'
If I only include Security.pas in the uses clause (and it is included in the project) then it accesses its members just fine.
Perhaps I need more information about what error you are running into? I'll send you a sample project that shows this working.
I might well be wrong, but I believe that if Security.pas is in the uses clause of the dpr file, along with its full path, it will be preferred over whichever file can be found via the namespaces and search paths.
Open project settings, in the Delphi Compiler section remove "Winapi" from "Unit scope names".
This way, when you need the Security unit shipped with Delphi, you'll have to write Winapi.Security, and if you write Security, it will use your custom Security unit.
I am trying to resolve this compile error, occuring only in Debug config, and only in the case described below:
[dcc32 Fatal Error] MyIndyTCPChannel.pas(22): F2051 Unit IdIOHandlerSocket was compiled with a different version of IdGlobal.IdDisposeAndNil
I am working on a very large Delphi codebase, with 2.5 million lines of in-house code, and 3 million lines of component code, which includes several large commercial Delphi component suites (Developer Express, TeeChart, and others), and a large number of open source delphi components as well, plus a fairly large in-house developed set of components, numbering 252 packages, of which about 140 are designtime+runtime or designtime, and the others are runtime packages (which are also loaded, into the IDE at runtime, by DLL-dependencies in their associated designtime package).
Our main library path has been optimized down to be small as can be, and it contains the paths that Delphi ships with as standard, plus three more we added, the primary one is a single "OurCompanyLibraryDCU" folder, which contains underneath it folders for the two platforms and two configurations that we use:
c:\dev\OurCompanyLibraryDCU\Win32\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
c:\dev\OurCompanyLibraryDCU\Win64\Release
c:\dev\OurCompanyLibraryDCU\Win32\Debug
Each of the above folders contains the set of BPL, DCP, and DCU files in a single folder, for that platform/config combination.
A macro like the following, in the project options is used, so we can change platform, and config, and have the directories resolve correctly:
$(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config)
OURCOMPANYLIBRARYDCU is an environment variable and $(X) is the syntax to expand an environment variable, in the context of the Delphi IDE.
I am trying to get the most important and largest VCL Application project (call it BigApp.dproj) to build so that the project search directory only contains our APPLICATION source folders and does not need the project search path to contain all our third party component LIBRARY source code. To do that, we need to link against the debug DCUs, or release DCUs.
So far we have everything working except for the case where you have both Debug and Release DCUs available. The release DCUs are in the library path, and the debug DCUs are in the Debug DCU path, in the IDE settings. Confronted with the choice between these two libraries, Delphi's linker appears to fail, whenever both sets of DCUs exist, with errors in this form, when I click Build, and the Build Configuration is set to Release, I get F2051 errors. The ordinary cause of an F2051 error is that multiple incompatible binary DCUs exist and are both accessible, and the linker is failing to make it all work. However, when you want both Debug and Release DCUs both in the library path, I thought that this sort of thing would not occur, due to the Linker selecting the debug or release DCUs for you.
If I have not build the Debug DCUs, the above problem does not occur. I suspect that my Debug DCUs are subtly "invalid" or that the Debug-DCU-selection algorithm inside Delphi is not working, but have no idea why, or how to fix this.
Multi-part-Question:
A. Is having a single folder for each platform/config combination, containing the DCU, BPL, and DCP in a single folder, and then added to the IDE Library Path known to cause problems? Do I need three sub-folders, making a total of 12 folders for every platform+config+filetype, or can I keep them together by platform+config?
B. In a package compilation situation, is it okay to have the IDE Library path contain the OurCompanyLibraryDCU folder, and also have that folder configured as the DCP Output Directory, Package Output Directory, and Unit Output Directory? My concern is that by having input folder and output folders the same, there is a case where the compiler could be failing to rebuild a Unit from .pas source, and simply linking the prior compile's DCU.
C. If I'm going about this wrong, how instead, shall I prevent the over 2.5 million lines of component LIBRARY code from being compiled from source each time I build my BigApp, instead only link them via DCU, and still have the debug and release dcus work properly?
D. I can get past the original error if I go to the Win32\Debug folder and delete IdGlobal.dcu. This suggests to me that my package compilation (for debug config) is producing an INVALID IdGlobal.dcu. Is that even possible? Can delphi silently output garbled DCUs?
Notes: I'm not using, and can not use Runtime Packages, to deal with the application size problems.
Update: The first thing I should have done here is verify that ZERO additional DCU files are ANYWHERE on my harddrive, ANYWHERE. That's the standard F2051 error advice. I'll update this question after I've taken care of that. It appears possible that Delphi will itself COPY a DCU from one place to another, or that a bogus DCU that is NOT in the CURRENT search path might have been in some other project's search path. A kind of bucket-brigade of bad-DCU-copies can occur. I'll update the question once I'm sure what kind of bad-DCU-generations-or-copies are occuring.
Update 2: I have now guaranteed that no additional copies of IdGlobal.dcu exist before building, and the problem still reproduces. So the question then turns on the compiler options used when building the IdGlobal.dcu, versions the compiler options used when building BigApp.dproj in Debug build.
Update 3: Although all my package compiles appear to complete without error, it seems they were not using a correct library search path, during the time when the DCC32.exe or MSBUILD.exe is being launched to build the packages. This library path inconsistency issue appears to be the core issue, thanks to Sir Rufo for pointing that out.
Perhaps I can shed some light on the order of search paths presented to the compiler, which should make clear why the problem happens in the first place and can be cured (at least in your situation) by adding the Debug DCU path at that specific location. All these observations were made with XE7.
There are several places in the IDE where you can specify search paths:
Library path (Delphi-Options - Library)
Translated Library path (Delphi-Options - Library-Translated)
Debug DCU path (Delphi-Options - Library)
Translated Debug DCU path (Delphi-Options - Library-Translated)
Search path (via Project Options)
When the Library language is set to English, those pathes are given to the compiler in the order 5,1 or 3,5,1 depending of the setting of Use debug .dcus. This is already a bit weird as the debug dcu path takes precedence over the project search path.
So f.i. to make the compiler find our own dcu files of a newer Indy version, we have to place the corresponding paths in front of the paths under 1 and 3.
Now things get complicated when the Library language is set to something different than English. In this case the translated paths come into play resulting in the order 2,5,1 or 4,3,2,5,1 depending of the setting of Use debug .dcus.
To make the above example with a newer Indy version work, you have to tweak the translated paths, too.
The culprit lies in CodeGear.Delphi.Targets, which places the paths in this order. I was able to modify this file so that the natural order of paths is used: 5,2,1 or 5,4,3,2,1. If anyone can confirm that I am allowed to show these changes here I will do. Perhaps I can provide a patch only.
Update: Here are the changes of CodeGear.Delphi.Targets from XE7 as shown by Mercurial
## -122,20 +122,19 ##
<DcpFilename Condition="'$(DcpFilename)'!='' And !HasTrailingSlash('$(DcpFilename)')">$(DcpFilename)\</DcpFilename>
<DcpFilename Condition="'$(DcpFilename)'!=''">$(DcpFilename)$(MSBuildProjectName).dcp</DcpFilename>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(DelphiLibraryPath)</UnitSearchPath>
- <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' == ''">$(DelphiLibraryPath)</UnitSearchPath>
-
+ <UnitSearchPath>$(DelphiLibraryPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_TranslatedLibraryPath)' != ''">$(DCC_TranslatedLibraryPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DelphiDebugDCUPath)'!=''">$(DelphiDebugDCUPath);$(UnitSearchPath)</UnitSearchPath>
<UnitSearchPath Condition="'$(DCC_DebugDCUs)'=='true' And '$(DCC_TranslatedDebugLibraryPath)' != ''">$(DCC_TranslatedDebugLibraryPath);$(UnitSearchPath)</UnitSearchPath>
-
+ <UnitSearchPath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(UnitSearchPath)</UnitSearchPath>
+
<___ResourcePath Condition="'$(DCC_ResourcePath)' != ''">$(DCC_ResourcePath);$(DelphiLibraryPath)</___ResourcePath>
<___ResourcePath Condition="'$(DCC_ResourcePath)' == ''">$(DelphiLibraryPath)</___ResourcePath>
+ <___ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(___ResourcePath)</___ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' != ''">$(DCC_UnitSearchPath);$(___ResourcePath)</__ResourcePath>
<__ResourcePath Condition="'$(DCC_UnitSearchPath)' == ''">$(___ResourcePath)</__ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' != ''">$(BRCC_OutputDir);$(__ResourcePath)</ResourcePath>
<ResourcePath Condition="'$(BRCC_OutputDir)' == ''">$(__ResourcePath)</ResourcePath>
- <ResourcePath Condition="'$(DCC_TranslatedResourcePath)' != ''">$(DCC_TranslatedResourcePath);$(ResourcePath)</ResourcePath>
<NameSpace Condition="'DelphiNamespaceSearchPath'!=''">$(NameSpace);$(DelphiNamespaceSearchPath)</NameSpace>
Now I understand a source for this problem. Please upvote Sir Rufo as he put me in mind of the solution.
It is this: I was invoking DCC32.exe to compile packages (using .dpk, but no .dproj file, and not invoking msbuild to compile these packages). When I built these, I was not inserting the Debug DCU path to the head of the library path passed in via -I parameters to DCC32.exe.
Once the DCC32.exe package compilation Library Search path has the Debug DCU folders FIRST, it works.
If anyone is interested in such a package system, I am planning to open source this package build system, as part of a relaunch of the WANT project originally built by Juancarlo Anez, which I will probably call by a new name. I'll update this answer once a working demo of a component build system is available.
A brief outline of a working system to meet the requirements I asked in my question:
You will need a file (could be xml, ini, json file) that defines a list of packages to build.
You will need to invoke MSBUILD or DCC32.exe on each of these. You could write your own code, or you could use mine, which I will open source when I can.
You will need to include the Debug DCU DPROJ into the library path as the first items, ONLY when invoking the Debug item builds.
You will want to use the $(OURCOMPANYLIBRARYDCU)\$(Platform)\$(Config) macro in your project search paths and library paths.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Release as a path within the Library path.
In your Delphi IDE, you will want to hard-code $(OURCOMPANYLIBRARYDCU)\$(Platform)\Debug as a path within the Debug DCU path.
I'm currently involved in a Delphi XE5 project and I'm facing a problem that I could not solve. I have a Delphi project group that conists of one EXE; this EXE loads multiple runtime BPL's dynamically. These BPL's are also part of the project group. However, when I run the application, I got the error 'Project {MyProject.exe} raised exception class EPackageError with message 'Cannot load package 'PumpMethod'. It contains unit 'FlEdit', which is also contained in package 'eXtractionUnitMethod'.
I already searched on SO, and I've found the cause. Especially Is "implicitly imported" always a bad thing in Delphi packages? was of big help. During compilation, both BPL's of my project, emit the following message:
[dcc32 Warning] PumpMethod.dpk(46): W1033 Unit 'FlEdit' implicitly imported into package 'PumpMethod'
Other one as well:
[dcc32 Warning] eXtractionUnitMethod.dpk(46): W1033 Unit 'FlEdit' implicitly imported into package 'eXtractionUnitMethod'
But the point is that FlEdit, a textbox control that allows only the input of floats, is already part of an installed package. This package, 'Spark190.bpl', contains the control, and thus also the FlEdit unit. I've registered it and the control appears on the Tool palette. This is the project with the control:
There is also a project DclSpark190.bpl, but that is a design time package (contains the registering of the controls). When I close this project group and create a new one, I can drag/drop 'My float edit' on a form, and this runs all fine.
When I now open the project group with the EXE, and build the BPL's I got this message:
This again seems okay for me. The Spark package (with the FlEdit) is now included in the 'requires' list:
But when I compile again, the 'the following changes...' is shown again. That looks abnormal to me; the Spark BPL is already included in the requires list? So:
Q1: Why is that happening? Is it a bug in Delphi XE5? Do I something wrong here?
Also, the 'FlEdit' implicitly imported into package 'PumpMethod' is still not away:
So:
Q2: I think I've put FlEdit in a separate package 'Spark'. Both BPL's contain 'Spark' in the required package list, but still the warning (W1033) is shown. What else can I do?
I have a set of components in split runtime/designtime packages for Delphi XE2. I've had these for a long time and have had no problems like what I'm having now. I added a new basic control called TJDWebcam. All was fine until I decided to change the type name to TJDWebcamView. I did a find/replace in the main source unit where I have this class, and made some other changes, also in the design-time package's registration unit.
The problem is that now when I build the run-time package, I get a message saying that it requires its self (It requires a package JDComponents which is exactly the same package). I've uninstalled the package, and tried to re-build, but same error.
Here's the specific message I'm getting...
Add JDComponents.
JDComponents contains implicit unit(s) uPickFolder, JDCommon,
JD.VSample, JD.VFrames, NativeJpg.
...and every unit in the package which are OK to be there. The problem didn't start until I changed this control's type name and went to re-compile.
Now if I ignore that message and hit 'Cancel' everything seems to install fine, despite the warning that it "might cause errors".
For what reasons might it be doing this? And how to go about fixing it? I'd hate to have to post my entire component library to be debugged.
PS - My library makes use of the delphi version suffix (160 for XE2) and my own version suffix (2), so the package names actually read JDComponents.160.bpl.2 and DCLJDComponents.160.bpl.2.
UPDATE
I managed to get it installed, please see my answer below.
After doing these following steps, I managed to get it re-built successfully:
Uninstalled the package
Deleted all DCU's, package, and anything compiled
Restarted the PC
Re-build everything
So the source of the problem is still unknown, but most likely somewhere in a compiled file (DCU or the package), it was still referring to this old type name from before it got changed. When the compiler came across this, it got confused and told me I had to include this other package, which is actually the same package.
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.
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.
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.
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
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.
Check that you don't have an strained old dcu file somewhere in source dir.
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).
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...
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.
There is a duplicate file in the list of search paths, and the incorrect version is found first
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.
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. :-(
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.
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.
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.
I just had the same error message in Delphi XE. Mine was solved after closing Delphi, opening it again and recompiling my project.