Extract from the log file "TMS FNC Core_2.2.0.2.log":
Extract from the log file "TMS FNC Core_2.2.0.2.log":
The download manager task is to download and launch the installer, which it does.
The installer task is to compile the packages from the command line for install in the IDE, which it does. Here the command line compiler fails to compile the packages and this normally should be reported by the installer at the end of the compilation step telling that compilation of the packages failed.
There can be various reasons for failure of compiling from the command-line, an excessive library path length is one of them as it is a limitation of MSBUILD that handles the command-line compilation that it can only deal with a command-line of 32K characters.
I would advise to sanitize your library path and remove the unused paths to get the total size below 32K or to compile the packages from the Delphi IDE (as this does not have the 32K limit)
As suggested by the Download Manager, most users will probably use the default path and will reach the system boundaries very quickly thanks to the name length.
Unfortunately the installer doesn't notice anything and you only notice it when you start the IDE.
from:
C:\Users\lrcu\Documents\tmssoftware\TMS FNC UI Pack\
C:\Komp103\TMS FNC UI Pack\ (-25 characters)
Is it not possible to reduce the name length in general?
e.g. from "tmssoftware\TMS FNC UI Pack" to "TMS\FNC UI Pack" (-12 characters)
Why are all paths always included when compiling?
Is this really necessary or is it predefined?
Can the installer not set up an environment variable?
All paths are used because that is the same way as it would happen from the IDE.
When we would only pick one path, possible there is an install error (for example previous version was not uninstalled) and it will appears as if everything is OK while it isn't.
The need for the compiler to have all paths stored in the global path statement is a big problem for all of us.
It seem to solvable if all paths are stored in the environment space as like
set path1 = long pahtname 1
set path2 = long pathname 2
and so on and then declare the gloval path name using %path1%, %path2% etc
This ha been done by several other packages.
Now I have to go to the registry and remove all packages to the tms paths stored and restart computer before installing new programs or updates beccause the path statement is too long when any installers add new paths needed for the installatuions and result is randomly errors in new and old programs becayse not everything got installed.
To set up several virtual computers for each package is not a solutiomn for my part. Don't hae time fro that :-(
We can't change the way the Delphi compiler deals with library paths.
The best short term solution is to use a short path names. For future iterations of the installer, we'll consider working with environment variables.
Here's how I resolved this...
HTH.
EdB
It will also happen without any TMS ccomponents at all, but installs tons of cool components from GetIt.
When the paths is fully expanded the length of each GetIt-package will fill your DCC parameter
With TMS you can include all your All-Access files by introducing a junction for TMS as
MKLINK C:\TMS_ "C:\Users<username>\Documents\tmssoftware" /J
Unfortunately it won't work by making a junction to the getit packages and override the environemnt path for getit-placement as not all component oackage installers check for any overides of the amaskin\HKEY_CURRENT_USER\SOFTWARE\Embarcadero\BDS\21.0\Environment Variables for BDDS-overrides like BDSCatalogRepository
I have a junction for BDSCatalogRepository C:\Repos_21 which is defined with
MKLINK C:\Repos_21 C:\Users<username>\Documents\Embarcadero\Studio\21.0\CatalogRepository
But seems like not all component installers check for these overrides, like for BDSCatalogRepository
If respected all $(BDSCatalogRepository)<mycomponents> will be expanded as
C:\Repos_21<mycomponents> with is much shorter than
C:\Users<usename>\Documents\Embarcadero\Studio\21.0\CatalogRepository<mycomponent>
Hopethis will help
I wonder how other big Delphi Component Vendors are handling this. For Example, DevExpress, ImageEn, and ShellBrowser (Jam Software) can install their huge component libraries without any path problems. What tricks are they using?
From TMS VCL UI Pack v11.0.5.0 we introduced the use of environment variables for the library path. All new product builds will adopt this technique to significantly reduce library path length.
Wanted to add the link to my thread here too for Google Search results. Basically, creating a junction so the default path exists still, but using a shorter path in your actual search path, seems to be required in some cases: