Good Day,
I am in the process of trying to open a legacy software project in Delphi XE. Whenever I try to open the IDE, I get around 100 - 110 error messages, one error message per DevExpress component not loading. This happens when I open the IDE itself AND when I open an existing project now.
The funniest part is that the paths to these BPLs are correct and all the "missing" BPL files are in those paths. The Environment variables point to these folders as well, and yet it just doesn't work. I attached a few pictures for ease of reference. You will notice the "missing" files in the Folder displayed in the screenshots. The BPLs are there, the paths are correct, but these modules just will not load...
What am I doing wrong? Why can't Delphi see these files and load them, even though these files are indeed present in those specified folders? Is there another setting I can try?
Thank you very much in advance!
Attached Images:
After a bunch of attempts, in the end it was necessary to completely remove both RemObjects as well as DevExpress, and then re-installing them one-by-one. Everything was fine after that.
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.
Firstly I can't really update the version because I would have to re-write my software which uses the dated components.
I initially had alot of success by re-installing the packages (around 40) to the fresh D5 install on the new Win7 machine. If it told me the .Bpl file was missing it works when I move it to the directory:
C:\Program Files(x86)\Borland\Delphi5\Projects\Bpl
and similarly if the .dcu is missing I move it to the Delphi5\lib directory.
However my next obstacle is when I load any form which has an Advantage table (all of my software uses Adt files and AdsConnections). It gives me the error:
TableX.StoreActive : property does not exist
for many tables and a few more properties including LoginPrompt.
It seems these are not included in my components which were included on my previous installation. I've tried updating to the most recent version of Delphi Sp1 but cannot find any information on how to add these properties.
I've carried out a similar migration: several projects developed in Delphi 5 on XP were moved to Windows 7. Unlike you, I also updated to Delphi 2010 at the same time.
The biggest difficulty I had was the lack of unicode support in my Delphi 5 components - I had to edit a lot of third party code. Of course, if I'd not upgraded to Delphi 2010 I wouldn't have needed to do that. Everything else went swimmingly. Here's how I did it.
First I made a copy of the project on the old machine, went through each form and replaced each of the third-party VCLs with run-time creation. It's a slog writing code to assign all the properties and events, but when I was finished there were only standard Delphi components on my forms but the project still ran correctly. Then I was able to move the project and the third-party .pas files to the new machine, open the project in Delphi 2010 and deal with the unicode issues.
The process was gruelling but straightforward.
Since then I've migrated another older project down the same path, but this time built a new application framework in Delphi 2010 and copied the units across piecemeal. In some cases I used the original .pas and .dfm files, in others I created new forms and copied the functional code. In all these cases I installed into Delphi 2010 the latest equivalents of the original third party components. This took a little longer than the original method.
However you tackle this, best of luck.
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 have lots of components that worked perfectly under D7.
I managed to compile and install them by dragging them into the Delphi 2009 IDE.
However, when I try to use those components in a project, the compiler says it cannot find the source code of them.
Where I can enter the path to that library?
Solution:
I dragged and dropped the old DPK file in Delphi 2009. Then in project manager I choose “Build” an then “Install”.
Everything worked smoothly except that the applications that used the controls couldn't see its source.
Problem solved by adding the path into the Tool-Options-Library Win32.
Thanks to everybody and especially to Mohammed.
Have you added the source path of the components to your library path?
you can add it from Tools menu > Options > Library win 32 >Library path
If you've really installed them, then the compiler shouldn't need to find the source code. The compiler only needs the DCU files.
But if you've taken these components from Delphi 7, then you need to have the source code, because Delphi 7 DCU files are not compatible with Delphi 2009. (The only two versions ever that can use each other's DCU files are Delphi 2006 and Delphi 2007, and then only with certain restrictions.)
Trying to use DCU files from the wrong Delphi version will cause Delphi to try to recompile the units. The solution is not just to provide the path to the source code, though. If the units files haven't been compiled yet (and they obviously haven't if they're of the wrong Delphi version), then you haven't really installed anything. Installing components in Delphi has never involved dragging and dropping. Installing a component means installing the package that contains that component, and installing a package often means opening the DPK project file and then choosing the "install" command in the IDE.