Solving problems with Delphi BPL packages, in which BPL do not load, but you have already recompiled (problem with the Windows VirtualStore file system)

Question

My general question is how to troubleshoot: "My BPL is not loading due to a dependency that just won't go away, no matter how much I clean and recompile." Update . You might think that you have a clean recompiled system, but thanks to the reverse miracle, which is Windows and its modifications to file system virtualization, you did not.

When I try to download my designtime package (in this case with the name dclFsTee.bpl ) to my Delphi development environment (this is a teechart wrapper 4 quick message package), it complains:

 The program can't start because tee7100.bpl is missing from your computer. Try reinstalling ... 

That tee7100.bpl does not refer to any DCP or DCU file on my system that I KNOW. But it is clear that something is wrong, and I can not find the problem.

All Delphi users face a hundred “will not compile or download” problems with the BPL. A universal refrain when asking what to do is to clean the computer.

Nevertheless, I spent several hours cleaning my computer, and although everything compiles the file, it is obvious that somewhere there must be something outdated, because the received BPL file, which I am trying to download, still wants to download the TepCart version The BPL that I removed from this system a few days ago, as well as every trace I found.

Traces of TeeChart materials in Delphi 2007 that I deleted include everything in the $ (BDS) \ Lib and $ (BDS) \ Lib \ debug folder, as well as all the DCP and BPL folders on the system. In addition, the dcu file with the name specified in TeeChart is missing.

Once you reach the end of the road, what will you try next? (Format the hard drive, buy a new computer.) Seriously. I think I'm a smart guy, but I have a 1 TB hard drive, a library path that runs up to 80+ folders, and a source code repository that seems to be well organized, but obviously something is hiding there where I can not find it.

I have TeeChart Standard 2012, with full source code, and as far as I know, my development machine no longer contains old TeeChart BPL files or DCP files from the version of "tee chart tee7100.bpl" that comes with delphi.

I ran the "recompile.exe" wizard that comes with teechart, which seems to launch MSBuild and create packages after writing the {$ DEFINE x} declaration in tee.inc files (there are two of them in the source distribution).

However, somehow, quietly, it seems that one of the implicit imports into one of the packages is to draw some obsolete file that has not been rebuilt, and therefore tries to load tee7100.bpl. The new bpl name is tee911.bpl.

Instead of asking a rather specific question for a quick answer, I mention it as a concrete example of a common world of resentment that I have encountered dozens of times as I developed in Delphi.

I provide only quick report data, so you can see that this is actually a specific instance of a common problem that is sometimes encountered inside the Delphi IDE when working with source code or a component package or a set of packages, with dependencies. Cleaning your computer so your code can even be complicated.

So here is my question related to the Delphi package dependency package question:

• What is the most efficient way to find or track issues with implicit consumption BPL messages so that my code (which builds and compiles just fine!) Actually loads into the Delphi IDE. The BPL file that occurs when the Recompile starts up seems to be properly linked to the correct DCP files, and there are no old / obsolete DCP or DCU files. For example, the new DCP file name is tee911.dcp.

• Can you somehow figure out which package is actually out of date, and what is read, linked and imported statically when .bpl links? (I think maybe as a special MAP file for BPL files?)

Refresh After many hours of dealing with this and using every trick I know, I realized that I didn’t notice for some VirtualStore related issues caused by file virtualization in Windows 7. This means that Windows 7 belongs to programs that run on top of it. This gives you a different version of the file that is not the one you want. It can be deadly in many ways; One; You recompile the BPL, but not the one that loads. The BPL that was killing me was in the SysWow64 folder, which was part of VirtualStore. Please note that the virtual store basically creates phantom files that exist only if you are a specific program with a low priority, which, apparently, is Delphi 2007 on Win7 / 64 bit. To delete BPL files in the VIRTUALSTORE SysWow64 folder for your current user account:

  del %HOMEPATH%\AppData\Local\VirtualStore\Windows\SysWow64\*.bpl 

... For a few days, I just hate the architecture of Windows. In any case, I am not going to put higher as an answer, because I would like to know if anyone has a better way or any advice or suggestion that might help next time.

Answer 1

Ok, no one answered, so I put this here to help future people:

- Remember Windows VirtualStore when cleaning up crashed systems that have old versions of DLLs, including TeeChart, FastReport, Indy, etc., which tend to be rioting because they can exist as "out of the box", with delphi ", and are also often installed as updated versions if you bought and installed them directly from suppliers, or, thirdly, you may have your own compiled copy in your company’s mega-component-pack directory.

- When searching for duplicates or obsolete BPLs, searching for files in windows does not look in virtual stores, you will need to find and block the entire area of ​​the virtual store for your process or user or program manually.

The second level of this problem:

The dependency graph for FastReports is complex:

• It depends on Indy, and you may have your own version of Indy, and Delphi has one, and other things on your hard drive may have their own copy of Indy.

• It supports various versions of TeeChart, including the binaries that come with Delphi, and possibly the standard version or other purchased version of TeeChart that you may have bought from Steema.

• It uses a precompiled header containing the file to compile, not just ONE, but TWO different copies of the file with the same name include (.inc).

• When you use your own compilation tool (recompile FastReport), it works quite reliably, but not the best, when you want to build everything in your project from one build script, thus the source of my problem.

• The key is to find out everything you need to know about the dependencies of all the components in your giant package heap, and organize your system clean so that you don't have old things (such as Indy and TeeChart bpls, dcp or dcu). Cleaning is a rather difficult job if you do not know what you are doing.

  • The utility really removes all traces of the Indy and TeeChart versions that come with your system, and the "Embarcadero version" FastReports is the key to solving this situation. General tip: "If version X comes with Delphi and you are planning to install a new version, prepare for the suffering until your system is clean."

  • A really awesome technique to avoid all this crap is to simply not install Indy, FastReport or TeeChart (uncheck them or skip them) during the initial installation of the Delphi IDE, and then install them yourself, one by one, from sources, Just because that the version comes preloaded with Delphi does not make it good. (Update: you can no longer undo Indy during installation, it is part of the Delphi core product, at least with Delphi XE8. A cleaning utility to remove the built-in Indy from Delphi's own lib dirs is necessary for those who build their own.)

  • Another amazing technique is to run Installers for commercial components on a virtual machine, and then simply compile the pascal source code and transfer it to your clean development machine and create it yourself. This way, you can avoid the terrible things that happen when you have BPL and stuff scattered around your system, and even installed on C:\Windows\System32 (on 32-bit systems) and C:\Windows\SysWow64 ( equivalent path on 64-bit systems).

Answer 2

put this 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" 

Answer 3

Another problem that can cause this does not have the folder in which you saved your .bpl files on your system path.

This is because Delphi is trying to call the WinAPI LoadLibrary function with a file name, not an absolute path. Therefore, if Windows cannot find the file, Delphi cannot load it.

See this forum post for more details.

This seems like a problem in Windows 7, but not in Windows 10.