If our app is launched from the Delphi IDE we have different behaviour when executing a batch file

Hydra
,
1

Hello,

we have a Delphi App that executes commands in a .NET plugin.
The .NET command is very simple, in this case it just executes a batch file.

System.Diagnostics.Process.Start(myBatchFileName);

The batch file makes use of robocopy.

If we launch our app with Visual Studio or if we launch our app directly all works correctly.
If we launch our app from the Delphi IDE (Delphi 10.3, have not tried with older versions) then executing the batch file fails with the following error. The problem also happens if you launch our app without attaching the debugger.

’robocopy’ is not recognized as an internal or external command,
operable program or batch file.

When starting our app from Visual Studio or the Delphi IDE the command line parameters are empty in both cases.

This is most likely not a Hydra problem. It is most likeley a Delphi IDE issue.
But maybe you have an idea that could help us. :slight_smile:

In the past I ran into a similar problem. We make use of NLog in our .NET plugin.
If our app was launched from the Delphi IDE, an exception would be thrown when trying to activate NLog.
In that case I could locate the problem and implement a workaround.
The problem was that if our app is started from the Delphi IDE the following C# call would generate an exception:

AppDomain.CurrentDomain.SetupInformation.PrivateBinPath;

somehow PrivateBinPath is corrupted when our app (I guess the same is true for any app) is launched from the Delphi IDE. The workaround was an ugly hack:

static private void AppDomainPrivateBinPathBugWorkaround()
{
var currentDomain = AppDomain.CurrentDomain;
try
{
currentDomain.SetupInformation.PrivateBinPath = currentDomain.SetupInformation.PrivateBinPath;
}
catch (ArgumentException)
{
var fusionProperty = typeof(AppDomain).GetProperty(“FusionStore”, BindingFlags.NonPublic | BindingFlags.Instance);
if (fusionProperty != null)
{
var setupInfo = fusionProperty.GetValue(currentDomain) as AppDomainSetup;
if (setupInfo != null)
{
setupInfo.PrivateBinPath = currentDomain.BaseDirectory};
}
}
}
}

I just checked and the work around is still needed for Delphi 10.3.

Do you have any idea, what the issue could be?

Thanks!

2

Wild guess, could it be that Delphi doesn’t pass the proper PATH environment variable to the app, and this the robocopy exe cannot be found? Try printing out there environment or running the SET command in your patch file.

3

Yes, that it is indeed the problem. :smile:

When our app is launched from the Delphi IDE, PATH includes only 3 folders:
C:\Users\Public\Documents\Embarcadero\Studio\20.0\Bpl;
C:\HHProjects\Head2\OurApp\buildWin32\bin;
C:\HHProjects\Head2\OurApp\BuildCommon\ide\

When not launched with the Delphi IDE it is a different story. PATH is complete.

THANKS!!!

1 Like
4

What values you have for path variable in global delphi options and in project options?

I mean
Tools->Options->IDE->Environment Variables->User system overrides
and
Project->Options->Debugger->Environment Block->User system overrides

5

We use a tool to launch the Delphi IDE and open a particular project. This tool also registers the design time packages and sets the PATH override so that the designtime packages we use for that particular project can be found.
So far so good.
I just notice for the first time that the PATH is also overriden in the Debugger->Environment Block section.
I will have to investigate why the value is overriden here. I would be surprised if we were setting this value from our tool. Will have to check…

Thanks!

6

The Debugger -> environment block Setting have no User System Overrides.
So we are not overriding the value.
What is surprising to me is that the program is executed using the PATH override which I always thought would only apply to the IDE itself, but not to any programs it launches…

Anyhow thanks for the help in helping figure out what the cause was. In the meantime we have been able to workaround it.

7

I’m not 100% sure about Windows, but i know it’s the case on UNIX, that each process, by default, inherits the environment from the process that launches it. If Delphi runs with override environment variables, it has. no access top the “default” ones anymore. Any process it launches would either inherit the ones Delphi itself;f has, or get custom ones Delphi explicitly provides it.

1 Like