I did already try this with no success.
I also updated the acls for all folders that "I know of"
BDS is installed under C:\Apps\BDS with ACL set correctly
TMS components Source are installed to F:_PACKAGES_2023\SRC\TMS....
Delphi $(BDSCOMMONDIR) is set to F:_PACKAGES_2023\BIN<version>
This is set via rsvars.bat as well as in path settings as well as in BDS Env Vars.
And it works for almost all other packages (only EMB GetIt does not always care for those)
And it worked for TMS packages as well - I guess it stopped to work, when I installer Delphi 12 (and applied the same settings there)
But as you can see from the screenshot - I only tried to install D11 and only win32/64.
I also tried to check with sysinternals tools, what folder can't be written / created. But with no success until now.
If I can't get it running in the very near future, I will need to remove TMS components from the product and rewrite the code later to other implementations instead of Aurelius - as I can't keep people longer inthe pipeline without updte to our software.
First, relating to TMS BIZ components, I suggest you use TMS Smart Setup. Uninstall all BIZ products, clean up the folders, then try to install using TMS Smart Setup. If it fails, please send the logs.zip files. Maybe we can have more insight from its logs, Smart Setup is the new installer generation.
Regarding Smart Setup - I think I can not "trust" in it working and would try it on a different machine first - since I need to configure some settings there as well.
Does the file F:\_PACKAGES_2023\SRC\TMS\BIZCore\packages\d11\Win32\Release\tmsbcl280.bpl exist?
Your library path before install seem to be messed up, You have lots of entries with $(aPAC23) that our installers do not add. Like $(aPAC23)\SRC\TMS\BIZCore\packages\d11\.\Win32\Debug
And then, of course, our installer adds the proper folder to it as library path, like F:\_PACKAGES_2023\SRC\TMS\BIZCore\packages\d11\.\Win32\Debug which end up duplicating the folder if aPAC23 points to F:\_PACKAGES_2023.
The mentioned folder he's trying to create is what he found as when trying to retrieve the default BPL output folder, which it ends up retrieving as
$(aPAC23)\BIN\22.0\Bpl\
That's what it's trying to use to create a symbolic link, and likely it fails because such folder does not exist.
So - $(aPAC23)\BIN\22.0\Bpl\ is my default BPL folder as configured in the IDE.
$(aPAC23)\BIN\22.0\DCP is the default DCP folder.
Since $(BDSCOMMONDIR) points to $(aPAC23)\BIN\22.0\ that all is correct.
The library Path entries reside there from an older installation of BCL (and others).
Since I need to replace all absolute Paths in the registry, search path, dcu path, library path, .... to match for other systems as well - they will stay in there.
When your installer runs, it will add new entries (it always did) but it simply multiplied these entries and I at the end removed them again.
That worked for a long time without a problem.
I don't see what changed here.
Most likely the symlinking does not work - because your packages are comiling bpl and dcps into a sub folder of the BCL project folder. Not into the default one.
So is it a Problem, that your installer tries to use the Delphi $() logic instead of %aPAC23% for windows env vars ?
Because this one is set as well.
This file exists - it's only not in the lookup path.
If I build the packages anually and copy bpl and dcps into the defined default folders - things work well.
So you think I should replace my default bpl / dcp settings with an absolut path instead of an Environment Variable ?
That would create a lot more hassel, but might fix the problem.
The whole idea is, to build all the bpl things only once on one machine and then ship the whole setup via git for my LAptop, my virtual dev machine, the build server, .....
BDSCOMMONDIR is set in rsvars.bat and in the env vars of delphi (as you can see in the pictures above)
BDSCOMMONDIR\bpl or \dcp \hpp are the default folders of the ide to store bpl/dcp/hpp
So I only changed $(BDSCOMMONDIR) in rsvars and Delphi Environmentals to our placeholder %aPAC23%\BIN%BDS_VER%
that points to F:_PACKAGES_2023\BIN\22.0
And its a common setting if you like to setup for BuildServers or share installation between different computers.
Yes, but %aPAC23% is not defined in rsvars.bat file. It's missed.
Note that it solved the %BDS_VER%, it retrieves the folder as
$(aPAC23)\BIN\22.0\Bpl\
It looks like env variable are being solved, but aPAC23 is not defined when the installer is invoked.
First change BDSCOMMONDIR to F:_PACKAGES_2023\BIN\22.0\BIN\22.0 in rsvars.bat to confirm it works that way.
Then if it does, try to make sure aPAC23 is known by the installer, either adding it to rsvars.bat or somewhere else that the installer can pick up from.
%aPAC23% is defined as a system wide windows environment variable.
It must be known to your installer - as a windows programm as well as a cmd window.
$(aPAC23) is only the BDS specific declaration for iside the IDE for the same variable. It is set from the windows ENV var.
Your installer should not care for aPAC23 at all, since your installer should only use $(BDSCOMMONDIR)
Maybe the installer has a Problem to resolve %aPAC23% inside delphi where it would expect $(aPAC23).
But setting inside rsvars.bat does not resolve $( ) env vars - only the windows ones with %%.
I will try it with an absolute path later just to rule it out.
