Can't loadpackage DCP_d5.bpl

0
votes

I am upgrading an old legacy Delphi 5 application to Delphi XE7. This application is based on numerous legacy packages, one of which is DCPcrypt 1.3. DCPcrypt is problematic: it is mysteriously uninstalled between runs of the Delphi XE7 IDE, and I can't reinstall without manually cleaning the Registry. The error message given on restarting the Delphi XE7 IDE is "Can't load package DCP_d5.bpl. The specified module can't be found. Do you want to attempt to load this package the next time a project is loaded?", followed by "Package \DCP_d5.bpl can't be installed because another package with the same base name is already loaded (DCP_d5.bpl)" if I try and reinstall it.

The version of DCPcrypt in question is bundled with a description dated March 23, 1999.

Has the Delphi package system changed, leaving DCPcrypt behind and causing these errors? If so, can anyone suggest what needs to be updated?

1
delphidelphi-xe7
Runtime packages are version-specific. You cannot use a D5 package binary in an XE7 project, or in the XE7 IDE. You will have to recompile and install the package for XE7. If your XE7 IDE is trying to load a D5 package, your configuration is messed up. – Remy Lebeau
We have recompiled and reinstalled, to no avail. – R.J. Dunnill
Then you haven't compiled/installed it correctly, because there is no reason there should be ANY references to D5 packages in XE7 installations. – Remy Lebeau
There are no references to D5 packages in this project. – R.J. Dunnill
But there are references in your IDE installation, since it is trying to load DCP_d5.bpl at all. What do you think the _d5 refers to? The Delphi 5 version of the DCP package. – Remy Lebeau

1 Answers

0
votes

Apparently all the packages that rely on a given package have to be uninstalled first, after which the package in question is uninstalled, rebuilt and reinstalled, and then the dependent package is rebuilt and reinstalled. Sometimes Delphi must be closed between uninstall and reinstall.

Regarding package names, the Delphi convention is not to include the Delphi version in the package name, but rather to add the Delphi version (in this case 210 for Delphi XE7) to the LIBSUFFIX in the configuration. The BPL will have the Delphi version in its name, but referencing modules can specify just the package name, and the correct BPL will be matched at build time.

In this case, I created a new XE7 package project, named it DPCcrypt, and set the LIBSUFFIX of '210' to denote Delphi XE7. I also added a DCPcrypt.rc resource file to the project with an icon named DCPCRYPT to give the package an icon. Finally, I added a conditional compilation block for VER280 in DCPcrypt.pas to set the DWORD type definition to longword, as the default was longint (a legacy of very old versions of Delphi that didn't have a 32-bit unsigned integer), and that eliminated the hundreds of signed-versus-unsigned warning messages on compilation.

The DCPcrypt project can now be loaded and installed. (Its package name is DCPcrypt but its BPL name is DCPcrypt210.) Whatever issue was hanging its load is now gone.