Delphi 13 "EFilerError: A class named X already exists"

[David Robb 0]

Hello all,

 

I am seeing an issue in the Florence 64-bit IDE: if I install any component package then uninstall it, I cannot reinstall it until I restart the IDE.  When I attempt to reinstall it, the IDE behaves as if it never uninstalled it.  Here is an example error:

 

Registration procedure, _ZN6Dcpreg8RegisterEv.Register in package dclDCPCrypt370.bpl raised exception class EFilerError: A class named TDCP_blowfish already exists.
 

This seems to occur with all third-party packages.  The package is removed from the Component | Packages dialog list after I select Uninstall.

 

This also seems to happen with some of the Embarcadero packages.  E.g. if I deselect "Embarcadero - RTL Component Editors" then reselect it I receive this error:  Registration procedure, _ZN9Beaconreg8RegisterEv.Register in package c:\program files (x86)\embarcadero\studio\37.0\bin64\dclrtl370.bpl raised exception class EFilerError: A class named TCustomBeaconDevice already exists.

 

For other packages, an AV occurs and the IDE becomes unstable.

 

This problem occurs even with a clean installation with zero third-party packages installed.
 

At least one of our third-party packages is causing an IDE crash when it is unloaded, and I want to which package is causing this crash.  But I have to restart the IDE every single time I uninstall any package.

Thanks in advance.

[corneliusdavid 292]

The 64-bit IDE is still quite new. Do you have the same problem with the 32-bit IDE? You might file a bug with Embarcadero.

 

If it is a third-party package, it might be tedious restarting the IDE multiple times, but it might be what it takes (I know, I've had to do this on occasion to troubleshoot my own packages!).

[Anders Melander 2203]

On 10/24/2025 at 7:31 PM, David Robb said:

This seems to occur with all third-party packages.

Works fine with Graphics32 using Delphi 13 (37.0.57242.3601), both 32- and 64-bit:

1. Load package group project Source\Packages\GR32.groupproj
2. Compile the GR32_R.dproj run-time package (implicitly uninstalls and then reinstalls the design-time package, as far as I can tell).
3. Compile the GR32_D.dproj design-time package (implicitly uninstalls and then reinstalls the package).
4. Uninstall the GR32_D.dproj design-time package.
5. Install the GR32_D.dproj design-time package.

No errors.

[corneliusdavid 292]

32 minutes ago, Anders Melander said:

run-time package (implicitly uninstalls and then reinstalls the design-time package, as far as I can tell)

No, it just recompiles the DCUs/DCPs/BPLs; doesn't touch the design-time parts.

 

32 minutes ago, Anders Melander said:

design-time package (implicitly uninstalls and then reinstalls the package).

Yes, I believe so. If you add a component to the package and then recompile it, it'll tell you about the new component that has been registered.

 

On 10/24/2025 at 10:31 AM, David Robb said:

At least one of our third-party packages is causing an IDE crash

So is it any and all packages or just all that you've tried or just one of them?  The error shown indicates it might be DCPCrypt? 

 

I worked with a package recently that was upgraded from a messy Delphi 5 library and when I added one of the units that had been recently upgraded, it caused an access violation every time I closed Delphi. I didn't realize it at first and it took me awhile, restarting Delphi, recompiling the packages, installing, uninstalling, until I finally figured out where the problem was and fixed it.

[Anders Melander 2203]

2 hours ago, corneliusdavid said:

No, it just recompiles the DCUs/DCPs/BPLs; doesn't touch the design-time parts.

I didn't say it recompiled the design-time package but it definitely unloads it and, if possible, loads it again.

 

The packages are DLLs and since the design-time package links to the run-time package, you wouldn't be able to compile and link the run-time package if the design-time package was still loaded by the IDE.

You can also witness that the form designer, which uses the design-time packages, closes when you compile a package - and if you change the signature of a method in the run-time package and recompile it, then you will get the usual Windows Can't find function in the DLL error message after compile.

 

[corneliusdavid 292]

1 hour ago, Anders Melander said:

You can also witness that the form designer, which uses the design-time packages, closes when you compile a package

OK, I admit I've never had an application form open at the same time I'm recompiling a component package (or it's been so long, I forgot), so would never have seen something like that. As far as I knew, it was a disconnected relationship between the libraries and wouldn't visibly affect anything until you refreshed or activated the form again somehow (or, in my case, opened the application with a form containing those components).

[Anders Melander 2203]

1 minute ago, corneliusdavid said:

it's been so long, I forgot

Probably this - caused by muscle memory, gunshyness, or whaddayacall it *.

Prior versions of Delphi crashed hard if you didn't close all form units that used the library being recompiled. Delphi 12 and 13 seems to handle it fine so far.

 

*) It's like I've learned to close the IDE Structure pane, without thinking about it, if I need to select more than one component on a form. If I don't, half the time the IDE goes into a unrecoverable deadlock somewhere inside Virtual Treeview.