Package output path Win32 subfolder

[jairgza]

Trying to install VirtualTreeView but i get the error:

Error: Can't load package C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl\Win32\VirtualTreesD21.bpl.

The "standar" path for win32 bpl files is C:\Users\Public\Documents\Embarcadero\Studio\15.0\Bpl ,why delphinus (or virtualtreeview ?) is creatin a Win32 subfolder ? Its a bug or feature ?

I guess this is because the designtime package when installing is not finding the runtime package, but I'm not sure

[Memnarch]

Okay the Win32-Subfolder is not supposed to be there for Win32-packages(unless you configured it to do so). 15.0 is XE8 right?

Is the BPL really stored at this path or is it stored at the expected path but it tries to load the package from the subfolder?

Can you dump this registryKey for me: HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Library\Win32

[jairgza]

Windows 10 15.0 is XE7 The bpl is stored in the Win32 subfolder

I'm testing on another computer with XE7- Win8 and it's installing the packages in the correct paths, so i guess its someting in my home machine, as soon as i can I will check the registry key

Here is the dump for registryKey from the Win8 machine, it seams good: HKEY_CURRENT_USER\Software\Embarcadero\BDS\15.0\Library\Win32

Reg_LibraryWin32.txt

[Memnarch]

Hi, Okay that's strange. Currently no access to XE7 so i modified the delphinus files to use the XE7 projects for XE6 and it worked (WIndows 10 aswell). SO it does not seem to be project related(as you have guessed, it might be your environment)

What is displayed for the WIn32 Target as BPLOutput in: IDE->Tools->Options->Library

What happens when you compile the project manually from IDE? Have you specified eny EnviromentVariables of Delphi for your Windows?

EDIT: I need the Registry dump from your WIn10 machine, if it runs on Win8 i don't need that one. Only the one from the broken system ;)

[jairgza]

What is displayed for the Win32 Target as BPLOutput in: IDE->Tools->Options->Library

Package output directory: $(BDSCOMMONDIR)\Bpl

DCP output directory: $(BDSCOMMONDIR)\Dcp

What happens when you compile the project manually from IDE?

It compiles fine and the bpl,dcp files are in the correct paths

Have you specified eny EnviromentVariables of Delphi for your Windows?

No, not by me, only the Paths added automatically when installs the IDE

This is the dump from the registry: Win10_x64_LibraryReg.txt

Diging in the delphinus code, I add to the log the obtained paths In DN.Installer.pas - function TDNInstaller.ProcessProject, just before FCompiler.Compile(AProject.FileName); added

DoMessage(mtNotification, FCompiler.BPLOutput); DoMessage(mtNotification, FCompiler.DCPOutput);

The log shows the paths appending the "$(Platform)" variable $(BDSCOMMONDIR)\Bpl\$(Platform) $(BDSCOMMONDIR)\Dcp\$(Platform)

This is the log file: log.txt

[jairgza]

I think I found the problem

In source DN.ToolsApi.Extension.pas procedure TDNEnvironmentOptionsService.LoadPlatforms;

LReg.RootKey := HKEY_CURRENT_USER;
LLibraryKey := TPath.Combine(LBase ,CLibraryKey);
if LReg.OpenKey(LLibraryKey, False) then
begin
  LReg.GetValueNames(LNames);
  //we are on a Win32-Only Delphi
  if LNames.Count > 0 then
  begin
    ...
    ...
  end
  else
  begin
    //we are on a multiplatform Delphi
    ...
    ...
  end;

You are trying to detect if the IDE is MultiPlatform or Win32-Only by checking if the registry key "Library" has no elements, but I realized that one component I have, write into that key (may be is a useless value, i dont know, but its there) so Delphinus think it's a Win32-Only IDE

I removed the subkey and all works fine. But I would prefer not to have to edit the registry

Do you think there is better way to know what kind of IDE is running ?

regards

[Memnarch]

Ahh thanks! Yes this information there is useless. On Multiplatform IDEs the Library content is ignored and values are read only from their platform keys. Which component is this that writes there o.O. PS: I think i have an idea for a more robust way of detecting this.

[jairgza]

ZipForge component many thanks

[Memnarch]

BTW at this point, i am really(!) curious why i didn't check for CompilerVersion > 22 (Since XE is the only SInglePlatform IDE with the old ToolsAPi i support) XD

EDIT: You might contact the developers of ZipForge to fill a bugreport since it clutters the registry. Since XE3 the EnvironmentOptions interface of the Toolsapi is broken anyway(if it uses this)and kind of useless since XE2

[Memnarch]

Hope this fix works for you. Can you verify?

[jairgza]

Ok It is working now, thanks for your time Best regards