Installing TMS Products fails with different errors when using non default delphi paths

Dear all,

While trying to install current versions of your products, I nearly always run into problems.

There are multile errors like "EInOutError - Unable to create directory" without stating the real path that can not be created.

This happens for BIZCore, Aurelius, Sparkle, and sometimes others as well.

On this machine, I am using non default Delphi installation and library paths.

Everything is installed under C:\Apps\BDS\22.0 or 23.0
Currently BDS 22.0 and BDS23.0 are installed.
All Platforms are installed.

The BDSCommonDir is replaced with a specific directory:


So nearly every thirdparty package and normal embarcadero ones are correctly installed there. Nothing is stored in C:\Users\Public.....

This is a realy realy urgent topic - as I can't work since days without having the TMS components installed.

Please contact me on my mobile phone +49 172 25 71 732 if possible.
Maybe a remote session via Teamviewer etc. could work this out.

Looking forward to your response.

Hello @Ziegelt_Christian, welcome to TMS Support Center.

Try to install in a different directory. Probably you don't have write access to such directory you are trying to install.

Hi Wagner,

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.

Maybe we could try a remote support session ?

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 files. Maybe we can have more insight from its logs, Smart Setup is the new installer generation.

You tweaked all this manually?

I can't see any screenshot.

Hi Wagner,
I'll try the new setup - do I find it in my account settings ?

We tweak these settings since years - yes.
But according to the defaults / explanation from EMB.

I guess I sent the screenshot via mail

install_2024_03_14.log (40.2 KB)

Here is also the log File from the installer.

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.

I can't afford to break even more things now.

And another screenshot from the sysinternals tool - at least hinting in a direction.
It tries to find te created bpl but looks at strange places.

$(aPAC23) is a placeholder for F:_PACKAGES_2023\ - because PC setups and Laptop setups differ in terms of Place for coding libs.

I'm not sure what the installertries to find there - and the dcp files for bcl are missing completely on my machine after the installer ran.

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


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, .....

Just for you to see these settings - please find the Lib path and some more:

Lib 32

$(aPAC23)\SRC\TsiLang\Units\ERS 11\$(Platform)


::@SET BDSCOMMONDIR=C:\Users\Public\Documents\Embarcadero\Studio\22.0
@SET FrameworkDir=C:\Windows\Microsoft.NET\Framework\v4.0.30319
@SET FrameworkVersion=v4.5
@SET FrameworkSDKDir=
@SET PATH=%BDSCOMMONDIR%;%FrameworkDir%;%FrameworkSDKDir%;%BDS%\bin;%BDS%\bin64;%BDS%\cmake;%PATH%
@SET PlatformSDK=

I don't even see such env variable being set in rsvars.bat

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


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.

Hmm, maybe I'm missing something here.

%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.