tmssoftware.com

After updating VCL UI Pack, I get missing BPL error messages when starting RAD Studio. The BPL files are not added by the installer at that location.

VCL TMS VCL UI Pack
#1

I recently updated the my VCL UI pack from the subscription manager and afterwards, when I open RAD Studio, I get a series of error messages that look like this:

image

Things I've tried:

  1. Checking if the file exists at that location. It does not.
  2. Searching my entire harddrive for the files. It's not there.
  3. Making sure that every previous file and folder is deleted before a fresh install. Didn't help.
  4. Downloading the installer directly from the website instead. Didn't help.
  5. Rolling back to the previous version. Didn't help.
  6. Making sure I ran the installer as administrator. Didn't help.

I don't know what version I was on before this but it had been a while since I updated. I shouldn't have any weird permission or security settings on my computer. Just your average personal home computer. Any idea what is causing this to happen or how to fix it? Why would the installer not write the bpl files?

#2

I should mention I'm using Windows 10 and RAD studio 10.4.2.

#3

Please send the installer .log file generated under c:\users<USERNAME>\AppData\Local\tmssoftware via direct email (NOT HERE as this file contains sensitive data) so we can inspect what went wrong during install on your machine and can suggest how to resolve this.

#4

Sorry Bruno. I should have replied earlier. I just wanted to let you know that you pointed me in the right direction. I looked in that log file and discovered that the problem was the same as this: Compilation errors are not recognized, long paths - #8 by Alf_Christophersen - the old library path too long for MSBuild issue. Really the only problem I guess was that the installation process reported a success instead of failure with an error message.

A lot has been spoken in the past about the issues with MSBuild and the path length, and I know it's a problem without a good solution most likely, but I guess I'll just throw my input in with the rest and say I've been bit with this exact issue over and over and over again and it sure would be nice if there was alternate approach or solution such as using an environment variable.

#5

As long as MSBUILD is used, eventually one can run into this issue, regardless of using an environment variable or use a shorter path. The best this does is potentially postpone the problem. We regret Microsoft isn't doing anything to address this limitation. Embarcadero recommends using MSBUILD as opposed to directly use DCC32 (and variants for other targets).
To begin with, we'll investigate to automatically report this problem better and secondly if we can introduce a choice for using an environment variable to reduce the cases when this limitation is met.

© tmssoftware.com