Can't install custom bpl Delphi 13 32 bit

[Connie McBride 0]

I have an install that has very few 3rd party libraries 

  -Devexpress

  - imageen

  - JCL

  - CodeSite

  - FastReports

 

I also have custom components that have been developed over the years.

I deleted all the DCUs, then rebuilt the BPL using Window32 as the target platform.

I cannot get the BPL installed.

 

the identical package builds and installs just fine in delph12.3, I didn't change anything (other than copy the code into a separate directory, and change the paths for Delphi 13 version)

all output paths are relative, but the library path is not.  it is set to exactly match the output directory of the package.

I have installed the latest patch.

I have made sure the output path of my package is the first path listed in the delphi library path.

none of my custom components have been built for win64 (at this time)

 

Any ideas where I should look next?

at one point, I removed all the uses files and all the 'register' statements, and got it to 'install' an empty BPL, but as soon as I re-introduced a 'register' statement, it blew up.

 

[FredS 141]

1 hour ago, Connie McBride said:

Any ideas where I should look next?

I ran into a lot of that, there are some major path issues now since both Win32 and Win64 are dumped into the System.
Once you get past that there is the Optset issues where old ones which you deleted are still part of the project file and are being used.

 

I've come to the point where I consider that entire Optset section dangerous for your mental health.

 

If that is not the issue then try moving DCPs in with BPLs instead of a secondary path.

Also Build Groups have been problematic in the past and dump into the wrong directories.

 

..and yes I've seen all those issues but meanwhile have switched to use MsBuild instead, installing a previous version of DevExpress and UniDAC went smoothly after that.

[Anders Melander 2203]

2 hours ago, Connie McBride said:

Any ideas where I should look next?

For both run- and design-time packages:

1. Delete the old bpl and dcp files.
2. Clear the DCP output directory and Package output directory field in the package project options.
3. Set Unit output directory to something like ".\$(Platform)\$(Config)".
4. Set Search path to the relative path from the package project to the source files. E.g. "..\..".
5. Build & install.

BPLs go into the default global Package output directory: "$(BDSCOMMONDIR)\Bpl\$(Platform)".

DCPs go into the default global DCP output directory: "$(BDSCOMMONDIR)\Dcp\$(Platform)".

 

I never share DCUs between projects so I don't touch the global Library path. Instead I add the required source folders to the individual project's Search path.

 

Works every time without problems.

[Connie McBride 0]

20 hours ago, FredS said:

I ran into a lot of that, there are some major path issues now since both Win32 and Win64 are dumped into the System.
Once you get past that there is the Optset issues where old ones which you deleted are still part of the project file and are being used.

 

I've come to the point where I consider that entire Optset section dangerous for your mental health.

 

If that is not the issue then try moving DCPs in with BPLs instead of a secondary path.

Also Build Groups have been problematic in the past and dump into the wrong directories.

 

..and yes I've seen all those issues but meanwhile have switched to use MsBuild instead, installing a previous version of DevExpress and UniDAC went smoothly after that.

I don't use optsets, I found them to just not behaving like I wanted them to.  

I have it dumping the dcu's and copied all my forms into a single directory for the version, and up until now (been doing delphi since delphi 2.0), I have had no issues.

[Connie McBride 0]

19 hours ago, Anders Melander said:

For both run- and design-time packages:

1. Delete the old bpl and dcp files.
2. Clear the DCP output directory and Package output directory field in the package project options.
3. Set Unit output directory to something like ".\$(Platform)\$(Config)".
4. Set Search path to the relative path from the package project to the source files. E.g. "..\..".
5. Build & install.

BPLs go into the default global Package output directory: "$(BDSCOMMONDIR)\Bpl\$(Platform)".

DCPs go into the default global DCP output directory: "$(BDSCOMMONDIR)\Dcp\$(Platform)".

 

I never share DCUs between projects so I don't touch the global Library path. Instead I add the required source folders to the individual project's Search path.

 

Works every time without problems.

this is what I have set my options to.

all the source code for my custom components is in the ..\Source directory

 

when I do a build now, I am getting this:

so now I'm not getting as far as before, where it did the build, but couldn't install...

 

 

[Uwe Raabe 2271]

What packages are required by yours?

[gkobler 59]

1 hour ago, Connie McBride said:

..\Source directory

 

In my opinion the output directory for win32 should be "$(BDSCOMMONDIR)\Dcp" without the „$(Platform)“. For win64 is "$(BDSCOMMONDIR)\Dcp\$(Platform)" ok. And the same rule for the BPL Output directory. 

[Anders Melander 2203]

1 hour ago, Connie McBride said:

this is what I have set my options to.

1. Don't copy/paste from forum posts. The forum software sporadically inserts weird, invisible Unicode characters into the text.
2. $(Platform isn't valid. It should be $(Platform) (likely caused by the above).
3. You missed to notice that I differentiated between project options and global options.

So again, in the project options:

1. Clear the DCP output directory and Package output directory fields.

2. Set Unit output directory to something like ".\$(Platform)\$(Config)".

3. Set Search path to the relative path from the package project to the source files: "..\Source" - and nothing else.

 

1 hour ago, Connie McBride said:

when I do a build now, I am getting this:

If the package is a design-time package then you need to create a run-time package with all the run-time stuff, and then add the run-time package to the Required packages of the design-time package.

 

If you have both run-and design-time stuff in one package then just add those units to the package.

[Anders Melander 2203]

12 minutes ago, gkobler said:

In my opinion the output directory for win32 should be "$(BDSCOMMONDIR)\Dcp" without the „$(Platform)“. For win64 is "$(BDSCOMMONDIR)\Dcp\$(Platform)" ok.

I agree.

And that is the values they take if the OP cleared the fields as I said.

[Connie McBride 0]

update.

I restarted the entire project by creating a new project in delphi 13.  copied the 'contains' list from Delphi12 version into the delphi 13 version.  

changed the options to :

 

now it compiles again, but still says :

 

 

[Anders Melander 2203]

1. Why do you have ..\Lib in the search path?
2. Download Dependencies, run DependenciesGui.exe, drop your CustomD13.bpl on it and examine the DLL dependencies.
   Is anything missing?

Here I'm viewing the dependencies of the Graphics32 design-time package GR32_D370.bpl. Among other things, it has a dependency on the run-time package GR32R370.bpl  (which I've moved in order to demonstrate what it looks like if a dependency can't be resolved).

[FredS 141]

41 minutes ago, Anders Melander said:

looks like if a dependency can't be resolved)

When a similar message came up it was because the only matching DCP found was the wrong bitness..

[Anders Melander 2203]

56 minutes ago, FredS said:

the only matching DCP found was the wrong bitness..

I think you mean BPL. "%1 is not a valid Win32 application" is a Windows error message returned by the LoadLibrary functions.

The DCP files are not DLLs and are not used with LoadLibrary. They are a collection of the DCU files contained in the package and are used by the linker instead of the DCU files.

 

See also:

• https://stackoverflow.com/questions/77183198/delphi-ide-package-load-error-on-1-is-not-a-valid-win32-application

[FredS 141]

14 minutes ago, Anders Melander said:

The DCP files are not DLLs

I did mean DCP, happened only during installation attempts.
At least in my case..

 

I do recall it happening once when an old build DCP was in the path.
 

[Connie McBride 0]

Update.

I tracked the initial problem to a 64 bit compiled bpl in my path.

progress.

I no linger get build errors, or the '% not a valid application' 

 

what I AM getting however, is this:

 

 

any tips on tracking this one down?

 

 

based on a suggestion, I ran the BPL through the dependency checker, and it looks like everything loaded:

 

[Remy Lebeau 1694]

50 minutes ago, Connie McBride said:

what I AM getting however, is this:

any tips on tracking this one down?

Does that BPL file actually exist at that path? If so, then the error is due to a missing dependency. Use a tool like SysInternals Process Monitor to see which other file is failing to be found/accessed while the IDE is loading that BPL.

[FredS 141]

2 hours ago, Connie McBride said:

I tracked the initial problem to a 64 bit compiled bpl in my path.

progress.

OK, but both 32 and 64bit are now part of the path.

The Win32 IDE and Win64 IDE share the same paths.. 

 

Was the 32bit one also on the path?

[Connie McBride 0]

17 hours ago, Remy Lebeau said:

Does that BPL file actually exist at that path? If so, then the error is due to a missing dependency. Use a tool like SysInternals Process Monitor to see which other file is failing to be found/accessed while the IDE is loading that BPL.

it does.

and thank you for the reminder.

the problem was with that original 64bit (that I had built by accident, meant to do a 32 bit build) got into a directory on my path, and then got added to the required list for my package.

saw it trying to load it in with procmon, removed it, and now all good (crossing fingers)