F2051 Unit was compiled with a different version (again) - delphi

(Warning: long read. This question references a lof of the other questions about F2051)
We have a folder named PatchLibs in our source tree in which we put modified files of third party sources.
This is in the project search path: ..\Skin;..\PatchLibs
I copied the file dxBar.pas from DevExpress controls into Patchlibs and modified some code in the implementation section only.
Now, when building (with all local .dcu files deleted and a 'Cleanup') I get the infamous:
[dcc32 Fatal Error] F2051 Unit cxBarEditItem was compiled with a different version of dxBar.TdxBarItemControl.GetItem
It doesn't refer to a line of code. I get the message when it starts compiling.
Configuration:
New Delphi and DevExpress versions installed in a new VM; copied the program source tree.
C:\DelphiLibs\DevExpress\VCL\Library\RS27 is in the 32bit library path
That folder contains all the DevExpress dcu's, notably cxBarEditItem.dcu and dxBar.dcu
(So does the $(DXVCL)\Library\RS27\Win64 library path, but this is a Win32 app)
There are no other occurrences of cxBarEditItem.dcu anywhere; dcBar.pas and cxBarEditItem.pas are in c:\DelphiLibs\DevExpress\VCL\ExpressBars\Sources\
(I even scanned the disk for all cx*.* and dx*.* files).
That source folder is also present in the Browsing path ($(DXVCL)\ExpressBars\Sources)
These are just units (no corresponding .dfm files)
There are other modified DevExpress files in Patchlibs that I have no issues with; and there are some more with which I have the same issue (not just dxBar).
Project is set up to place .dcu files next to their .pas sources (Unit Output Directory is blank)
No DevExpress files are part of the project
Other source files in the project have changed
If I pull a copy of cxBarEditItem.pas into Patchlibs, the error only just propagates to another unit (repeatedly).
Despite having read many answers (Notable SO question: Why are my units "compiled with a different version" of my own files?)
I simply do not understand why the error occurs and how to fix it this time.
cxBarEditItem.pas has dxBar in its interface Uses section, and cxBarEditItem is in my Uses clauses, but why would it want to recompile?
I can of course start adding the DevExpress source code directories into the Search Path, but there are a lot of those and this will result in .dcu files in them as well.
I prefer not to do that because it masks the actual problem and this was not necessary in the previous Delphi/DevExpress setup:
32 bits library path in earlier Delphi 10.3:
c:\DelphiLibs\CompanyName
c:\DelphiLibs\CompanyName\TTLib
c:\DelphiLibs\CompanyName\DataFox
C:\DelphiLibs\RBuilder\Source
$(BDSLIB)\$(Platform)\release
$(BDSUSERDIR)\Imports
$(BDS)\Imports
$(BDSCOMMONDIR)\Dcp
$(BDS)\include
c:\delphilibs\multilizer\localizationcomponentsxex_x86\packages\full\bplxe\20.0
C:\DelphiLibs\Multilizer\LocalizationComponentsXEx_x86
c:\delphilibs\pascal script\dcu\d25\win32
C:\DelphiLibs\Pascal Script\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Dcu\D26\Win32
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\DataSnap
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\ZLib
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Synapse
$(Everwood)\Bin
C:\DelphiLibs\Scalabium\SMExport\Sources
C:\DelphiLibs\Scalabium\SMImport\Sources
C:\DelphiLibs\Cooltray
C:\DelphiLibs\PlusMemo\
C:\Delphilibs\RBuilder\Lib\Win32
C:\DelphiLibs\PlusMemo
C:\DelphiLibs\IPWorks 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks Auth 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks Encrypt 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks SSH 2020 Delphi Edition\pas
C:\DelphiLibs\IPWorks ZIP 2020 Delphi Edition\pas
C:\DelphiLibs\VirtualUI\dev\Delphi
c:\DelphiLibs\CEF4Delphi-master\source\
$(DXVCL)\Library\RS26
32 bits library path in Delphi 10.4:
c:\DelphiLibs\CompanyName
c:\DelphiLibs\CompanyName\TTLib
c:\DelphiLibs\CompanyName\DataFox
C:\DelphiLibs\RBuilder\Source
c:\program files (x86)\embarcadero\studio\21.0\lib\Win32\release
C:\Users\Jan\Documents\Embarcadero\Studio\21.0\Imports
c:\program files (x86)\embarcadero\studio\21.0\Imports
C:\Users\Public\Documents\Embarcadero\Studio\21.0\Dcp
c:\program files (x86)\embarcadero\studio\21.0\include
c:\delphilibs\plusmemo
C:\DelphiLibs\RBuilder\Lib\Win32
C:\DelphiLibs\Multilizer\LocalizationComponentsXEx_x86
C:\DelphiLibs\PlusMemo
C:\DelphiLibs\Pascal Script\Source
C:\DelphiLibs\Scalabium\SMExport\Sources
C:\DelphiLibs\Scalabium\SMImport\Sources
C:\DelphiLibs\Cooltray
C:\DelphiLibs\VirtualUI\dev\Delphi
C:\DelphiLibs\nSoftware\IPWorks 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks Auth 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks SSH 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks ZIP 2020 Delphi Edition\pas
C:\DelphiLibs\nSoftware\IPWorks Encrypt 2020 Delphi Edition\pas
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Dcu\D27\Win32
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\DataSnap
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Grijjy
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\Synapse
C:\DelphiLibs\RemObjects Software\RemObjects SDK for Delphi\Source\ZLib
C:\Program Files (x86)\RemObjects Software\Everwood\Bin
C:\DelphiLibs\SQLDirect\Source
C:\DelphiLibs\CEF4Delphi-master\source
C:\DelphiLibs\DevExpress\VCL\Library\RS27
Moving that last one up or down or changing it to $(DXVCL)\Library\RS27 did not help
Those 5 Embarcadero lines look weird (see this SO question,
I replaced them with their old counterparts (and reported to Embarcadero); no change in the issue.
Additional research/failed attempt
Ian Boyd had a very a similar problem way down in 2014
F2051: Unit %s was compiled with a different version of %s
Suggestions there were RTTI settings or compiler options.
Based on David's answer there, I decided to give that a try.
My situation was slightly different: I had to try to find out what compiler settings were used when building the DevEx code and insert those into the top of my modified dxBar.pas.
I noticed that there are two .dproj files in Packages subfolders in the DevExpress installation: cxLibraryRS27.dproj and dxBarRS27.dproj (requiring cxLibraryRS27 BTW)
By setting all compiler options in a test project to non-defaults and comparing that .dproj to one with all the defaults I was able to understand (most of) the relation between UI option settings and the .dproj contents.
I then compared their cxLibraryRS27.dproj settings against those from our project and found the following differences (irrelevant lines removed):
They had this extra:
<PropertyGroup Condition="'$(Base)'!=''">
<DCC_E>false</DCC_E> No idea what these are...
<DCC_F>false</DCC_F>
<DCC_K>false</DCC_K>
<DCC_N>false</DCC_N>
<DCC_S>false</DCC_S>
<DCC_DebugInformation>0</DCC_DebugInformation>
<DCC_LocalDebugSymbols>false</DCC_LocalDebugSymbols>
<DCC_AssertionsAtRuntime>false</DCC_AssertionsAtRuntime>
<DCC_SymbolReferenceInfo>0</DCC_SymbolReferenceInfo>
We had this extra:
<PropertyGroup Condition="'$(Cfg_1)'!=''">
(this is the one with <DCC_Define>RELEASE;$(DCC_Define)</DCC_Define>)
<DCC_IntegerOverflowCheck>True</DCC_IntegerOverflowCheck>
<DCC_RangeChecking>True</DCC_RangeChecking>
<DCC_SYMBOL_DEPRECATED>False</DCC_SYMBOL_DEPRECATED>
<DCC_SYMBOL_LIBRARY>False</DCC_SYMBOL_LIBRARY>
<DCC_SYMBOL_PLATFORM>False</DCC_SYMBOL_PLATFORM>
<DCC_UNIT_LIBRARY>False</DCC_UNIT_LIBRARY>
<DCC_UNIT_PLATFORM>False</DCC_UNIT_PLATFORM>
<DCC_UNIT_DEPRECATED>False</DCC_UNIT_DEPRECATED>
<PropertyGroup Condition="'$(Cfg_1_Win32)'!=''">
<DCC_COMBINING_SIGNED_UNSIGNED>false</DCC_COMBINING_SIGNED_UNSIGNED>
<DCC_COMPARING_SIGNED_UNSIGNED>false</DCC_COMPARING_SIGNED_UNSIGNED>
and
<PropertyGroup Condition="'$(Cfg_2)'!=''">
(this is the one with <DCC_Define>DEBUG;$(DCC_Define)</DCC_Define>)
<DCC_DebugInfoInExe>true</DCC_DebugInfoInExe>
<DCC_DebugDCUs>true</DCC_DebugDCUs>
<DCC_WriteableConstants>True</DCC_WriteableConstants>
<DCC_IntegerOverflowCheck>True</DCC_IntegerOverflowCheck>
<DCC_RangeChecking>True</DCC_RangeChecking>
<DCC_SymbolReferenceInfo>2</DCC_SymbolReferenceInfo>
<DCC_StackSize>16384,9437184</DCC_StackSize>
<DCC_SYMBOL_DEPRECATED>False</DCC_SYMBOL_DEPRECATED>
<DCC_SYMBOL_LIBRARY>False</DCC_SYMBOL_LIBRARY>
<DCC_SYMBOL_PLATFORM>False</DCC_SYMBOL_PLATFORM>
<DCC_UNIT_LIBRARY>False</DCC_UNIT_LIBRARY>
<DCC_UNIT_PLATFORM>False</DCC_UNIT_PLATFORM>
<DCC_UNIT_DEPRECATED>False</DCC_UNIT_DEPRECATED>
<DCC_COMPARING_SIGNED_UNSIGNED>False</DCC_COMPARING_SIGNED_UNSIGNED>
<DCC_COMBINING_SIGNED_UNSIGNED>False</DCC_COMBINING_SIGNED_UNSIGNED>
and they did not have this PropertyGroup
<PropertyGroup Condition="'$(Cfg_2_Win32)'!=''">
<VerInfo_IncludeVerInfo>false</VerInfo_IncludeVerInfo>
<DCC_DebugInfoInExe>false</DCC_DebugInfoInExe>
<ILINK_FullDebugInfo>true</ILINK_FullDebugInfo>
<BCC_SourceDebuggingOn>true</BCC_SourceDebuggingOn>
<BCC_DebugLineNumbers>true</BCC_DebugLineNumbers>
<BT_BuildType>Debug</BT_BuildType>
<DCC_ImportedDataReferences>false</DCC_ImportedDataReferences>
<DCC_DebugDCUs>false</DCC_DebugDCUs>
</PropertyGroup>
Going through these I think these are the settings they have differently and that may influence the generated .dcu files:
Range checking off {$R-}
Overflow checking off {$Q-}
Local debugs symbols off {$D-}
Runtime assertions off {$C-}
Symbol reference info off {$L-}
Writeable constants off {$J-}
Debug info in exe off {$Y-}
So I put this at the top of dxBar.pas:
{$C-,D-,J-,L-,Q-,R-,Y-}
Nope, no success...

I did not read entirely but immediately checked the DevExpress sources when I saw the compile error.
This is very much related to the fact that TdxBarItemControl.GetItem is marked as inline. When inline or generics (they behave similar) are involved it often is required that if you change such a unit also any other unit using this one has to be recompiled as well.
Suggestion based on experience (we also use DevExpress with custom modifications):
Put them into version control (also the binaries! git lfs ftw) and when you change any of the source just recompile and commit any changes. Keep this repository seperate from your own source repository but tag/branch it identical to your source repository. Changing between versions then also will be a no brainer.

I am not convinced it is about compiler options. I guess there may be a missing cxBarEditItem.pas file. Or there is an old cxBarEditItem.dcu somewhere in your linking path. So the compiler is confused.
Try to clean up the component sources, to have only .pas files and no .dcu, and try to recompile again.
If it is not enough, then maybe this is a problem with the components .inc files, and incompatible options. Don't try to modify the third-party component source code, you will most probably break something.

I just had the same problem, searched it, found this and for me the answer was this: I forgot to add a .pas file for a unit to the .dpr but still had a .dcu for it lying around from another build.
I had to add the file to the .dpr and everything worked again.

Related

Delpi packages: should I include source directory in "Tools - Options - Language - Delphi - Library - Library path" and recompile *.dcu each time?

I am migrating from Delphi 2009 to Delphi 10.4 Sydney and I am updating the convention that I will use for the organization of my Delphi custom packages.
To see how the things should work in Delphi 10.4 Sydney, I installed 'LockBox2-2021.05-Sydney' with standard GetIt package manager that comes with Delphi, that is recent addition to Delphi and that appartently defines the best practices/conventions how the packages should be used and installed.
These are my observations:
GetIt copy complete package project to the BDSCatalogRepository (there is such Environment variable now) directory, e.g. C:\Users<ME>\Documents\Embarcadero\Studio\21.0\CatalogRepository\LockBox2-2021.05-Sydney\ and there is one common directory (/source) for the .pas/.dfm/*.fmx files and separate directories for the compiler-version-dependent project files (e.g. \packages\Sydney\Delphi).
GetIt installation adds the source directory ($(BDSCatalogRepository)\LockBox2-2021.05-Sydney\source\ in this case) to the 'Tools - Options - Language - Delphi - Library - Library path'.
Any Delphi project sees complete Library path (that now consists of the immeasurable number of source directories for the different packages projects) and if any *.pas unit of my Delphi project references any *.pas unit from the Library path, then Delphi compiler recompiles this *.pas unit from the library path and puts the resulting *.dcu in the the project 'Unit output directory' (that can be specific directory under the project folder).
This works and this seems to be the standard way of doing things for Delphi 10.4 Sydney. But it is a bit strang, I should acknowledge - each Delphi project recompiles the dcu for any package it uses. Is it good practice? Should I accept this practice? Why not accept? Maybe such recompilation overhad is not necessary, is there reason for such recompilation each time?
My understanding is that the definition of "library path" was a bit different for the Delphi 2009 ("Tools - Options - Environment Options - Delphi Optios - Library-Win32 - Library path": we usually organzed our packages in a way that put compiled *.dcu units (from the source code of packages) in one common directory, e.g. D:/Library/Delphi2009 and then we put this D:/Library/Delphi2009 into "Library path" and any custom Delphi project was able to see that the *.dcu units from the pacakges was available and visible from the library path and any Delphi project could access these dcu units from D:/Library/Delphi2009, so, there was no need for Delphi 2009 to recompile the packages *.pas files into packages *.dcu units each time when any Delphi 2009 project use that package/component.
So - this is really strange redefinition of the meaning of the "Library Path" - it was the directory for .dcu units in the Delphi 2009 times and now (Delphi 10.4 Sydney times) it is the directory for the packages/components source files (.pas) that are commonly visible to each project and that each project uses for compiling its own *.dcu units for the packages/components.
Does really such redefinition of the meaning of "Library path" happened and should I really put my component/pacakge source in the directories that I should include in the "Library path" and should I really ask Delphi compiler to recompiler dcu units (of packages/components) for each of my custom Delphi project?
Of course, formally my question contains multiple questions, but these are just details to the general question about the best practice/standard how to organize packages in the the Delphi 10.4 Sydney and beyond.
Your look at what has to go into Library Path is correct. Most libraries follow this approach and put the path to the platform dcu into Library Path and the debug dcu path appropriately. It seems that at least some of the TurboPack libraries break this convention and put the source path into Library Path. This may be convenient as you don't have to copy the dfm files to these folders, but it is definitely the wrong approach. I suggest filing a report for that.

What Is a .vrc file, how is is generated and can you remove it using the IDE?

I am trying to install a commercial component called JamShellBrowser but it will not install.
I have contacted the developer, but meanwhile I'd like to know:
What is a vrc file?
How is it produced?
Can it be controlled or modified with the Delphi XE4 IDE?
I checked the IDE's help but I could not find anything about vrc files and I searched for Delphi vrc and did not find anything that would help me.
The error message is:
Checking project dependencies...
Compiling JamShellDelphiXE4.dproj (Release, Win32)
brcc32 command line for "JamShellDelphiXE4.vrc"
c:\program files (x86)\embarcadero\rad studio\11.0\bin\cgrc.exe -c65001 JamShellDelphiXE4.vrc -foJamShellDelphiXE4.res
[BRCC32 Error] JamShellDelphiXE4.vrc(2): file not found: JamShellDelphiXE2_Icon.ico
Failed
Elapsed time: 00:00:00.1
I searched the components folders for an ico file, but there is none... thus the message, but even if I remove the line MAINICON ICON "JamShellDelphiXE2_Icon.ico" from the vrc file or even delete the vrc file it is automatically generated when I try to install.
I moved from Delphi 2010 to XE4 a few months ago and noticed the apparently new vrc file but I do not know what it is or how to handle these files.
A .vrc is a temporary file created by Delphi MSBuild process to compile resources files (.res) which will be linked in the final binary output. It is passed to CodeGear Resource Compiler/Binder (cgrc.exe) and deleted after the build process.
It doesn't appear anywhere in .dproj file. This behaviour is from BuildVersionResource target, imported from $(BDS)\Bin\CodeGear.Common.Targets. Look at this file (and at CodeGear.Delphi.Targets) if you want to get a better understanding of build process.
Removing <Icon_MainIcon> tag from .dproj it's not enough, as VERSIONINFO resources can also force the creation of .vrc file (I believe "vrc" stands for "Version Resource", although it is also used for main icon in applications).
In case of packages, Delphi always put version info in packages projects. The "include version information" IDE option is ignored with package projects.
So, if you (like me)
don't rely on Delphi IDE to set application main icon
don't rely on Delphi IDE to set version info resources; and
do manage to include your own resources files for everything
you can disable its creation entirely by setting the SkipResGeneration to true in your msbuild call. E.g.:
msbuild.exe myProject /t:Build /p:Config=Release /p:SkipResGeneration=true
However, this only works for MSBuild-based builds. I don't know how to do the same for builds from Delphi IDE.
Just open your #PROJECT#.dproj in any text editor file and find lines
<Icon_MainIcon>#PROJECT#_Icon.ico</Icon_MainIcon>
and delete them.
You will find one per Build target.
Save the file and you are done.
Edit: The original answer referred to the .dpr file, however note the section to edit is in the .dproj hence I've updated the the answer above to reflect this.
I believe this is a built in IDE behaviour of Delphi XE4 and XE5, possibly caused by an upgrade bug. Generation of VRC files is something that you can not disable except by removing the tags in the dproj file that cause it to be generated.
If there was a way to fix it or remove it, it might involve comparing your dproj file with another dproj file and looking for something that was appropriate only to a .dpr+.dproj Project that somehow got into your .dpk+.dproj project, like <Icon_MainIcon>.
It appears to be an intermediate file that is auto-generated when a .dpr+.dproj project has some version information which must be written out of the .dproj file, and into a temporary location and then compiled and linked into your application as a version info resource. However, I have also seen it get generated for a .dpk+.dproj project, and this mystifies me as well.
It also seems to contain a resource for your default application icon and version information, and packages do not normally have a versioninfo or application icon resource.
What I find to be possibly a BUG is that there is no UI in the Delphi IDE to let you set the Application Icon of a Package. Yet, I sometimes get a .VRC and an .ICO file. But I am not aware of a fix, other than to report the issue to Embarcadero Quality Central.
With a .dproj project, a .VRC intermediate file makes at least some sense. I see the following content: Version Info, Application Icon, and VCL Styles (ie AquaLightSlate.vsf) resource linkage.
this is a clarification...
I've just started to install several component libraries into Delphi RAD Studio XE5 that I've got installed in XE2 and XE4. When I try to Build most of them, I get this same error.
The problem isn't so much the .vrc file itself, it's this particular error:
[BRCC32 Error] <project_name>.vrc(2): file not found: <project_name>_Icon.ico
I can't figure out a way to bypass it, and I have no idea what it's looking for or where.
I tend to copy my component libs from one version to the next, opening them, building them, and installing them (ie. the ones that don't come with installers). I've never seen this happen in prior versions. However, this is the first time I've had RAD Studio installed; in the past I've just had Delphi. So perhaps it has something to do with having C++ installed as well?
I had to change my X.optset file to get this to work.
X being the name of your Delphi version you brought over these options from. Mine was PolyDelphiXE2.optset.
Once I corrected the name here no more funny compiling that brought in a different ico reference.

DELPHI Compiler Path settings after INDY 10 upgrade

I already asked how to upgrade to the latest Indy TCP TP components version ( GET INDY COMPONENTS ) and Installed Indy 10 with DELPHI XE 2 now. For all the Indy projects I defined an outfolder in the project options section of DELPHI XE2, here I found later all the the .bpl files and all the -DCU#s files I need now in order to compile my application using the new INDY components to add this output folder as a library search path in these projects.
I found at my XE2 installation a path/folder with *.dcu files for x32, x64, release and debug mode (C:\Program Files (x86)\Embarcadero\RAD Studio\9.0\lib\win64\release).
Do I need now all the INDY *.dcu I have created also in these different flavours compiled, how to set the path for all project to use the new *.dcu from my folder ?
Should I copy all my dcu's to these many sub folders ??
You should not replace the pre-installed Indy files with the updated compiled files (in case you need the originals in the future, such as for DataSnap projects). Install the newer Indy into its own separate folder, then update the projects search paths to refer to that installation's output folder(s) instread of the pre-installed folder(s).
You should not overwrite the .dcu files that are part of the Delphi installation. What's more, I would not recommend that you do anything with the .dcu files that you used to build these .bpl files.
What you should do is to include the Indy source files, the .pas files, in your project. Personally I prefer to avoid using a search path to achieve that and instead simply add all the necessary .pas files to the project. But you may prefer to use the search path option.
But the main point is that since this project is supplied in source form it is best to compile the source yourself, as part of your project. That makes it much easier for you, whilst debugging, to step through the Indy code. There's no need to have separate DCU files for release and debug. It makes the build process simpler, only one thing to build. It makes it easier if your source code targets multiple Delphi compiler versions.

Why Delphi says "Unit xxx compiled with a different version of yyy" if all my paths are correct?

First of all I would like to apologize for the question itself. I simply could not make anything better. Well, the question then follows with examples and detailed ...
I manually installed QuickReport Delphi 2006 from their sources. It is composed of two packages a "DesignTime" and a "RunTime".
My Delphi is configured to build the BPL files in "D:\BPL" and DCP files on "D:\DCP" for all packages compiled on my Delphi
The source code of QuickReport are in "D:\QuickReport" and their packages (design and runtime) are configured to save the compiled units (DCU) in the folder "D:\QuickReport\DCU." This was the only configuration done in the packages. Nothing is set up with different paths and, BPL and DCP files are placed correctly in the folders I've set up, as I mentioned earlier.
With these settings I was able to build and install QuickReport without problems (just a few compiler warnings, which I believe are normal). All QuickReport components appear in your palette in Delphi, which does not emit any error on start proving that the components are properly installed and all packages were found.
Now comes the test: I started a new win32 application, completely empty, just a blank form. Then it put a QuickReport component (TQuickRep). The first thing I noticed was that the unit "QuickRpt", which is automatically placed in the clause "uses" of the "interface" is underlined in red indicating that something is wrong.
When I perform a CTRL+ENTER in "QuickRpt" unit (uses clause), the Delphi finds the source file (.pas) correctly, which is in "D:\QuickReport" then I ran a BUILD ALL command and the following compilation error appeared:
[Pascal Fatal Error] Unit1.pas (7): F2051 Unit QuickRpt was compiled with a different version of QRExpr.TQREvElement
That's it!!!
This error is only happening with Quick Report. I have other third-party components installed using the same configuration as the paths and they all work properly.
Finally I was able to solve this problem. #RRUZ and another friend gave me the tip: An lost QuickRpt.dcu file on my system. There were a QuickRpt.res file also. I found them, but the place was very improbable to me: The delphi LIB folder!!!
Well, i have some clues about this bizarre thing.
Until Delphi 7, the QuickReport was shipped together with the IDE however, it was disabled by default. On that Delphi version, all we need to do is to register the bpl to gain full access to QuickReport!
On Delphi 2006, the QuickReport is not part of IDE and there are no BPL to register, however the guys at Borland forgotten to remove all files from the old QuickReport. The Delphi Lib Folder is one of the first folders to be checked on Delphi start, so, if there are old files there, new files on another place would be never compiled, generating the annoying error!
This problem may be present on Delphi 2005 too.

Install the latest build of Indy 10 on Delphi 2009 [duplicate]

This question already has an answer here:
Step by step upgrade of Indy 10 in Delphi 2009
(1 answer)
Closed 3 years ago.
Is there a step-by-step guide for updating the Indy 10 components in Delphi 2009?
I've read the uninstalling thread and have the latest build (IndyTiburon.zip). However there appears to be no installation instructions.
If you have accomplished this, please share the details.
Edit: I have managed to get the packages installed by messing with the "requires" section in dclIndyProtocols120 and dclIndyCore120.
Essentially removed all Indy package dependencies from "requires" section and just used the Library path resolve things. Added ..\Lib\Core, ..\Lib\System and ..\Lib\Protocols to the Lib path. Had to leave dclIndyProtocols120 in requires for dclIndyCore120 as it wont install without this.
All 3 packages compiled (including IndySystem120) and seems to be working okay now.
This should be easier for D2009 users. I had to update to resolve an SMTP bug in Indy (see link).
On this question there is a more satisfying answer.
For all versions before D2009 you can use a Fulldx.bat script to recompile the packages and then just open the BPL files in (for example Indy-10.5.5\D6\dclIndyCore60.bpl and Indy-10.5.5\D6\dclIndyProtocols60.bpl) in the Delphi 2009 IDE packages dialog. Now with Delphi 2009, the FullD12.bat is there but it is not doing anything.
My simple solution is to create Indy components at run time only. I add the Indy Tiburon Core, System and Protocols to the projects search path, and also use Apache Ant with a build script to run the compiler for the final build.
One IIRC needs to compile system core and protocols in that order.
Moreover a package is a .BPL and a .DCP. So you probably would have to copy the .bpl and the .dcp to that directory in a normal case. The .BPL is what programs need to run, but to compile something that uses the .BPL (statically) you also needs the .dcp.
But that doesn't work for the Indy caseafaik because it also needs includefiles, so you need to add all their paths to the library path.
IIRC is that Delphi (at least the versions that I know) don't add directories to paths when installed, and one must always add paths to directories with .dcp or .dcu's manually.
(contrary to Lazarus that builds a list of dirs from the installed packages. But partially that is maybe also a fix for not having something akin .dcp yet, and in generally be more source oriented)
Note that I don't have D2009, it is just experience from general manual Indy compilation.
Maybe a simple method for anyone looking 10 years later... (tested under Delphi XE5):
Download the latest Version from https://indy.fulgan.com/ZIP/.
Extract the ZIP-archive into a folder of your choosing (I made a folder "Delphi Lib" under my Documents).
Throw out all Indy .dcu Files (Indy[...].dcu and Id[...].dcu) from your Delphi installation (for Example: C:\Program Files (x86)\Embarcadero\RAD Studio\12.0 (The last folders name may vary on your installation))
Open Delphi and go to Tools -> Options. Get to the "Library"-Listing and add the following folders of your newly downloaded Indy: /lib/Core/, /lib/System, /lib/Protocols.
As always: Help yourself and make backups before deleting anything. You do not want to reinstall your comlete Delphi because you threw away a file you should've kept...

Resources