I'm migrating a Delphi 2 project to RAD Studio XE2.
When I try to compile I get
[DCC Fatal Error] MyUnit.pas(9): F2051 Unit JclUnitVersioning was compiled with a different version of System.Contnrs.TObjectList.Remove
at the following row:
unit MyUnit;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, DB, DBTables, TB97, ExtCtrls, Grids, DBGrids, Vcl.Mask, JvExMask,
Vcl.DBLookup,
JvToolEdit, {<-- error here}
TB97Ctls;
{...}
I tried uninstalling and reinstalling RAD Studio, JCL and JVCL, but nothing changes.
Update Was using the binary Jedi installer from A.Hausladen (intended for use in Delphi trial editions only).
You either have old DCU files lying around that need to be rebuilt, or removed, or your project or library path contents are not consistent. (Find files named JclUnitVersioning.dcu that are not in the proper JCL Library folder, and remove them. The proper library folders are named jcl\lib\d7, through jcl\lib\d16, depending on your delphi version number )
This usually means that your project has access to both a directory that is in your library-path (or project search path) that contains pre-compiled DCU files, and may also have access to some source units (.pas files), and that one or more of the units that depends on other units, was compiled at a different time than now, with multiple versions of a common unit. I wish I could draw you a picture.
Imagine you have a car, and someone upgrades the engine, changing it from a V6 to a V8. Now someone who had previously been servicing your engine comes back and tries to find the place where the V6's exhaust manifold attached. It's not there any more, it's moved. Since the new engine is frozen in its current shape (stay with me here!), your service technician simply goes back to you (the customer) and says, "sorry, I'm confused, I can't continue, I give up". That's roughly what this error message means.
Cleaning it up is possible in several ways; It may be a simple matter for you to make sure you compile 100% from .pas files, and have no Library folders containing .dcu files at all. Of course, that's hardly ideal, is it, since the whole purpose of a Library path was to contain a precompiled "library" of DCU files.
So instead, I suggest you do a cleanup (delete all your DCU files) and rebuild all your component packages from source (you do have a batch file for that purpose right?) and then review both your project's search path, and library path to see that both contain only the folders you think they should contain.
Just had the same problem with Delphi 2010 and XE3 (both on same PC while migrating).
After several hours of recompiling both my projects and the JCL projects (the installer bat file errors on my PC) discovered the problem was the order in which the directories were declared in the tools/options/Delphi Options/libraries.
Took them all out, added the version specific directory (eg lib\D14, lib\D17\Win32) and then the other JCL sub-directories required (ie one at a time until a project using JCL would build)
Simple fix:
After JCL package install, reboot your PC to apply Path change. (The installer will ask for it.)
Open from Delphi IDE the JCL package. eg.: ..\jcl\packages\d7\Jcl.dpk
Click Project menu > Build ! (do not just compile)
Save all changes, close Delphi.
Now JVCL\install.bat should work fine. Tested just now with Delphi7 Light Edition 7.3.4.3
(You may also edit that .bat file and change the first line from #echo off to echo on, to see more detailed infos, what's going on.)
Related
My general question is how do you troubleshoot "My BPL won't load due to a dependency that just won't go away, no matter how much I clean up and recompile". Update You may think you have a clean recompiled system, but thanks to the inverse-miracle that is Windows and its file system virtualization mis-features, you haven't.
When I try to load my designtime package (in this case named dclFsTee.bpl) into my Delphi IDE (it's the fast report 4 teechart wrapper component package), it complains:
The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ...
That tee7100.bpl is not referenced on any DCP or DCU file on my system THAT I KNOW OF. But clearly, something is wrong, and I can't find the problem.
All Delphi users face a hundred "won't compile or won't load" problems with BPLs. The universal refrain when asked what to do is to clean up your computer.
However, I've now spent hours cleaning up my computer, and while everything compiles file, clearly there must be something out of date hiding somewhere, because the resulting BPL file that I'm trying to load still wants to load a version of a TeeChart BPL that I removed from this system days ago, along with every trace I could find.
The traces of TeeChart stuff in Delphi 2007 that I removed include everything in the $(BDS)\Lib and $(BDS)\Lib\debug folder, and all DCP and BPL folders on the system. Also every TeeChart-unit-named dcu file is gone.
Once you've gotten to the end of the road, what do you try next? (Format the hard drive, buy new computer.) Seriously. I think I'm a smart guy, but I have a 1 tb hard drive, a library path that runs to 80+ folders, and a source code repository that seems to be well organized, but clearly something is hiding where I can't find it.
I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains any old TeeChart BPLs or DCP files from the "tee chart tee7100.bpl" version that ships with delphi.
I have run the "recompile.exe" wizard that comes with teechart, which appears to just run MSBuild and build the packages, after writing a {$DEFINE x} declaration to the tee.inc files (there are two of them in the source distribution).
However, somehow, silently it seems like one of the implicit imports into one of the packages is drawing in some stale file which has not been rebuilt, and which therefore tries to load the tee7100.bpl. The new bpl name is tee911.bpl.
Rather than ask the pretty-specific-to-fastreport question, I'm only mentioning it as a specific instance of a general world of hurt that I have faced dozens of times while developing in Delphi.
I'm only giving the fast-report details so you can see that this is in fact a specific instance of a general problem that one faces sometimes inside Delphi IDE when dealing with a component source code or package, or set of packages, with dependencies. Cleaning up your computer so that your code even builds can be tricky.
So here is my Delphi package-to-package-dependency-resolution question:
What is the most effective way to find or trace implicit-load-of-some-no-longer-wanted BPL-problems so that my code (which builds and compiles just fine!) will actually load into the Delphi IDE. The BPL file that results from running Recompile seems to be linking properly to the right DCP files, and no old/stale DCP or DCU files are present. The new DCP file name is tee911.dcp, for instance.
Can you get somehow, any idea of what package is actually stale, and what is being read and linked and imported statically when the .bpl links? (I'm thinking maybe like a special MAP-like file for BPL files?)
Update After many hours of fighting with this, and using every trick I know, I realized I hadn't checked for some VirtualStore related issues caused by file virtualization in Windows 7. That means that Windows 7 lies to the programs that run on top of it. It gives you another version of the file, that isn't the one you want. This can be deadly in several ways; One; You recompile a BPL but that's not the one that loads. The BPL that was killing me was in the SysWow64 folder that was part of the VirtualStore. Note that the virtualstore basically makes phantom files appear that are only there if you're a certain "low privelege" program, which Delphi 2007 on Win7/64 bit, apparently is. To remove BPL files in your SysWow64 VIRTUALSTORE folder for your current user account:
del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl
... Some days I just hate Windows architecture. Anyways, I'm not going to put the above as the answer, because I'd like to know if anyone has a better way or any tip or suggestion that might help next time.
Okay nobody else answered so I'll put this here to be helpful for future people:
-- Remember Windows VirtualStore when cleaning up broken systems which have old versions of DLLs on them including TeeChart, FastReport, Indy and so on which tend to be involved in messes because they can exist both as "out of box packages that ship with delphi" as well as frequently installed as upgraded versions if you purchased and installed them from the vendors directly, or third, you may have your own compiled copy in your company's mega-component-pack-directory.
-- When searching for duplicate or out of date BPLs, doing a file search in windows doesn't look in the virtualstores, you'll have to locate and zap the whole virtualstore area for your process or user, or program, manually.
The second level of this issue is this:
The dependency graph for FastReports is complex:
It depends on Indy and you might have your own version of Indy, and Delphi itself has one, and other things on your hard drive might have their own copy of Indy.
It supports various editions of TeeChart, including the binaries that come with Delphi, and perhaps the Standard version or other purchased version of TeeChart that you might have bought from Steema.
It uses a precompiled header include file to do the compilation and not just ONE but TWO different copies of an identically named include (.inc) file.
When you use their own compiler tool (recompile FastReport) it works pretty reliably but isn't the best for when you want to build everything in your project from a single build script, thus the source of my problem.
The key is to learn everything there is to know about the dependencies of all the components in your giant pile of packages, and to organize your system cleanly so that you don't have old stuff (like Indy and TeeChart bpls, dcp, or dcu files) lying around. Cleaning that up is quite a complex job if you don't know what you're doing.
A utility to really remove all traces of the version of Indy and TeeChart that ship with your system, and the "Embarcadero edition" of FastReports is key to getting this situation resolved. A general tip is that "if a version of X ships with Delphi and you are going to install a new version, prepare to suffer until your system is really cleaned up".
A really amazing technique to avoid all this crap is to just not install Indy, FastReport or TeeChart (uncheck them or skip them) during your initial Delphi IDE install, then install them yourself, one by one, from sources. Just because a version comes pre-installed in Delphi doesn't make that a good thing. (Update: You can no longer unselect Indy during install, it's part of the base Delphi product since at least Delphi XE8. A clean-up utility to remove the built-in Indy from Delphi's own lib dirs is necessary for anyone who builds their own.)
Another really amazing technique is to run the Installers for commercial components on a virtual machine, then just collect up the pascal source code and transfer that onto your clean development machine, and build it yourself. That way you can avoid the terrible things that happen when you've got BPLs and stuff scattered around your system, and even installed into C:\Windows\System32 (on 32 bit systems) and C:\Windows\SysWow64 (the equivalent path on 64 bit systems).
put that BPL (tee7100.bpl) under $(BDSCOMMONDIR)\Bpl
for XE: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\8.0"
for XE5: $(BDSCOMMONDIR)= "C:\Users\Public\Documents\RAD Studio\12.0"
The other issue that can cause this, is not having the folder where you've stored your .bpl files in your system path.
This happens because Delphi attempts to call the WinAPI function LoadLibrary with a file name, instead of an absolute path. So if Windows can't find the file, Delphi can't load it.
See this forum post for more information.
This seems to be an issue in Windows 7, though not in Windows 10.
I'm migrating a Delphi 2 project to RAD Studio XE2.
When I try to compile I get
[DCC Fatal Error] MyUnit.pas(9): F2051 Unit JclUnitVersioning was compiled with a different version of System.Contnrs.TObjectList.Remove
at the following row:
unit MyUnit;
interface
uses
Windows, Messages, SysUtils, Classes, Graphics, Controls, Forms, Dialogs,
StdCtrls, DB, DBTables, TB97, ExtCtrls, Grids, DBGrids, Vcl.Mask, JvExMask,
Vcl.DBLookup,
JvToolEdit, {<-- error here}
TB97Ctls;
{...}
I tried uninstalling and reinstalling RAD Studio, JCL and JVCL, but nothing changes.
Update Was using the binary Jedi installer from A.Hausladen (intended for use in Delphi trial editions only).
You either have old DCU files lying around that need to be rebuilt, or removed, or your project or library path contents are not consistent. (Find files named JclUnitVersioning.dcu that are not in the proper JCL Library folder, and remove them. The proper library folders are named jcl\lib\d7, through jcl\lib\d16, depending on your delphi version number )
This usually means that your project has access to both a directory that is in your library-path (or project search path) that contains pre-compiled DCU files, and may also have access to some source units (.pas files), and that one or more of the units that depends on other units, was compiled at a different time than now, with multiple versions of a common unit. I wish I could draw you a picture.
Imagine you have a car, and someone upgrades the engine, changing it from a V6 to a V8. Now someone who had previously been servicing your engine comes back and tries to find the place where the V6's exhaust manifold attached. It's not there any more, it's moved. Since the new engine is frozen in its current shape (stay with me here!), your service technician simply goes back to you (the customer) and says, "sorry, I'm confused, I can't continue, I give up". That's roughly what this error message means.
Cleaning it up is possible in several ways; It may be a simple matter for you to make sure you compile 100% from .pas files, and have no Library folders containing .dcu files at all. Of course, that's hardly ideal, is it, since the whole purpose of a Library path was to contain a precompiled "library" of DCU files.
So instead, I suggest you do a cleanup (delete all your DCU files) and rebuild all your component packages from source (you do have a batch file for that purpose right?) and then review both your project's search path, and library path to see that both contain only the folders you think they should contain.
Just had the same problem with Delphi 2010 and XE3 (both on same PC while migrating).
After several hours of recompiling both my projects and the JCL projects (the installer bat file errors on my PC) discovered the problem was the order in which the directories were declared in the tools/options/Delphi Options/libraries.
Took them all out, added the version specific directory (eg lib\D14, lib\D17\Win32) and then the other JCL sub-directories required (ie one at a time until a project using JCL would build)
Simple fix:
After JCL package install, reboot your PC to apply Path change. (The installer will ask for it.)
Open from Delphi IDE the JCL package. eg.: ..\jcl\packages\d7\Jcl.dpk
Click Project menu > Build ! (do not just compile)
Save all changes, close Delphi.
Now JVCL\install.bat should work fine. Tested just now with Delphi7 Light Edition 7.3.4.3
(You may also edit that .bat file and change the first line from #echo off to echo on, to see more detailed infos, what's going on.)
In Delphi XE2, I have a single control in a pair of design/run time packages. Originally, everything was working fine. I've built each of them many times already. Suddenly without warning, the design time package started complaining in one of my units that the Graphics unit is missing when I build. Graphics is a standard unit, but it's not found from this one place. I haven't even made any changes to this unit, and as far as I know, any changes that could affect this.
Here's just the uses at the top (interface) of this unit:
uses
Graphics, ColorConv, Classes, Dialogs, ZLib;
As you can see, it's a very simple unit, and I only make very simple changes to this project. What could make it start complaining about this out of nowhere?
The strange thing is that it all works fine if I install it, it just doesn't build.
There's quite a bit of code, and I'd hate to have to post the entire thing.
Wild guess: it needs the Vcl. namespace prefix?
if there are several declaration of graphics(or other VCL units like:controls,forms ...)in your project, you can add VCL namespace to your project
as follows:
project menu-->options-->delphi compiler->>add in "unit scope names" value "Vcl"
Check your paths in Tools->Options->Environment Options->Delphi Options->Library, in particular the Library Path and Browsing Path settings. The defaults for my installation of XE2 (excluding those added by third-party components and my own stuff):
Library:
c:\program files (x86)\embarcadero\rad studio\9.0\lib\Win32\release;c:\program files (x86)\embarcadero\rad studio\9.0\Imports;C:\Users\Public\Documents\RAD Studio\9.0\Dcp;c:\program files (x86)\embarcadero\rad studio\9.0\include;
Browsing:
$(BDS)\SOURCE\VCL;$(BDS)\source\rtl\common;$(BDS)\SOURCE\RTL\SYS;$(BDS)\source\rtl\win;$(BDS)\source\ToolsAPI;$(BDS)\SOURCE\IBX;$(BDS)\source\Internet;$(BDS)\SOURCE\PROPERTY EDITORS;$(BDS)\source\soap;$(BDS)\SOURCE\XML;$(BDS)\source\db;$(BDS)\source\Indy10\Core;$(BDS)\source\Indy10\System;$(BDS)\source\Indy10\Protocols;$(BDS)\source\fmx;$(BDS)\source\databinding\components;$(BDS)\source\databinding\engine;$(BDS)\source\databinding\graph;$(BDS)\source\fmi;$(BDS)\source\data;$(BDS)\source\data\ado;$(BDS)\source\data\bde;$(BDS)\source\data\cloud;$(BDS)\source\data\datasnap;$(BDS)\source\data\dbx;$(BDS)\source\data\dsnap;$(BDS)\source\data\Test;$(BDS)\source\data\vclctrls;
Also, since you're new to XE2, you may want to check to see (outside the IDE) if you have an environmental variable for PLATFORM defined. Some PC manufacturers (HP as a particular example) define this variable on their computers, and it interferes with the IDE's requirements. (The IDE uses PLATFORM as a temporary environmental variable in paths used for different platforms, which fails if there's one predefined outside the IDE.) You can check by opening a command prompt and typing SET PLATFORM and hitting Enter. If there's one pre-defined, it can cause various hard to track down problems; you can remove it safely on every machine I've run across. (Right-click My Computer or Start->Computer, choose Properties, Advanced System Settings, Environmental Variables.)
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.
I am trying to start making my own libraries avaialble as packages prior to compiling my Apps with these packages hence modularising my code. For years I've 'sort of' understood packages, breathing a sigh of relief when I load a component package and click on 'Install' and it does. I understand that the process of installing a component (or components) is via the creation of a BPL which is then registered with the IDE.
Where I begin to get lost is how to make files available so that I can compile with EITHER a package OR pre-compiled dcu's (like the third party vendors do) and without pointing my project at the source code all the time. I can create a package with the following settings:
where I've specified that all my output will go into 'c:\scratch\wow'. After a build I find TEST.BPL, TEST.DCP and lots of DUC's. Now, when I point another project at this folder to use the DCU's, I get a missing DFM error (one of the units is a form). Should I be manually copying needed DFM's into this output folder? The DPK knows about this form, so why do I not get the DFM copied for me? I presume that using TEST.BPL, that file contains everything, but I wish to work in the two modes. Of course I can get around this by including the source folder in my project search path to find the DFM but third party libraries seem to already have the DFM's in their output folder. Did they install them there using the installer?
Thanks
instead
As others say you could use post-build events to copy your DFM files into place. Other people use a one-time external batch file that copies the DFMs to the DCU folder.
Personally I see very little benefit to making packages for things which are not developed also as reusable components. I also see very little benefit in partitioning an existing application into packages, when you don't reasonably need to use the same subsection or package more than once, or at designtime.
Things I would put into packages:
Delphi visual and non-visual components.
Things which absolutely must be plugged in at runtime, or left out. For example, supposing I sell MetaWare Light and MetaWare Pro, and instead of using compiler IFDEFs to build a differnt binary, I preferred for some reason to simply not ship the ADVANCEDFEATURE.BPL with my systems.
Things to beware of with packages:
I have run into a lot of compiler bugs when combining packages with generics. I have also run into IDE crashes and lockups, in Delphi 2009, 2010, XE and XE2. (I believe XE3 is better)
You should learn a bit about BorlandMM.dll and shared memory management in the BPL world before you move to it. There are some subtleties.
Packages limits the ability of the linker to decide what to remove. In fact, it pretty much destroys it. Packages contain everything that is linked into them, and nothing publically accessible can be removed.
Once you've created a binary package and shipped it to even one customer, you have a pretty difficult to modify contract (this BPL contains a particular signature or application binary interface) you have to be careful in the future to never change them, or mix and match them. Beware of DLL hell, even among your own customers, and be prepared to use versioning on your packages. Just as delphi packages have a version suffix, I recommend you use version suffixes in your own packages right off the bat, and bump them whenever binary compatibility has changed.
Delphi handles build dependencies between packages about as well as could be hoped, which is less well than a single monolithic application. In applications that I have that make heavy use of packages, I find project groups that contain a bunch of packages that depend on each other are very difficult to manage and build quickly. In fact, I have experienced that both compiles and builds are slower and more frustrating than they would be in a singular 750Kline megaproject.
I really wonder if you're not that into the package area of Delphi (you breath a sigh of relief whenever a delphi component actually builds and installs without issue?) if you really want to move into the Packages World totally. By all means, you should experiment. But I wouldn't bet the farm on it yet. Learn some more first.
Yes, you should copy the .dfm to the directory with the compiled units (.dcus), if that is the only directory you want in your search path. The BPL will of course contain the .dfms, and you need a .dcp to be able to link a BPL with your app.
Third party tools must have put the .dfms together with the .dcus in the directory using their installer, indeed.
Instead of copying *.DFM manually you can use Post-Build Event (Project/Options/Build Event), ex:
copy “$(PROJECTDIR)\Unit1.DFM” “c:\Scratch\wow\Unit1.DFM”
I found a way to do this without moving .dfm files to the directory of .dcu files, so you can have a directory for .dcu files only one for .dcp files only and another for .bpl files only.
All you need to do is to create another directory on your good structure, as I do. The directory is called RES and in it should be placed all the resource files (.res files, not .dcr files) that are used by applications compiled using your packages (components). In the Delphi Library Path, you must include in addition to the DCU directory (you should already have) a directory named RES.
On your component (design time) do everything you want with the form (design it, put other components, etc). In the source code of the unit you replace {$R *.dfm} with {$R UnitName.dfm}. In doing so, save all and close the DPK. Now move the .dfm file (do not copy, move!) to the RES folder (the .dfm file is a resource file to the Delphi. The {$R} directive is proof!) and after that open the DPK again to understand what has changed.
First realize that you may not open the form (F12) from his unit, though no error was issued by Delphi about "DFM missing".
Now, do a Build on your package and then install it. Realized again? No errors displayed! This happened because you have indicated the location of .dfm file in the Delphi library search path (RES directory).
Done! You can use your component and dfm will be found when your component is included in an application.
Many of you can now say that this way I will not longer be able to visually edit a form in the component design time. Yes this is true, but if you think about it, why would I want to change so often a form into a component that, in practice, should only be used and slightly edited? Draw your own conclusions ;)