Encountering Grief Running propy.bat at Pro 3.0

[Anonymous User]

I am in the process of migrating various add in applications to Pro 3.0 and am encountering grief with running a python script from my Pro Application.

I have relied on a method that calls the "propy.bat' routine to run the python script. This has always worked well in the Pro 2.x series under the various .NET Frameworks.  I am assuming the .NET core is introducing a twist into this.

As a base test to make sure the python script itself was functioning in my Pro 3.0 environment, I ran the script interactively in Pro through the Python window and it worked.

When I am running the application and calling the script through propy.bat, it never returns a value. I have monitored this in Task Manager and can see the Python task begin and start to consume cpu. However,
it never returns a value and the python task in task manager remains consuming 0 percent cpu.

I have tried tweaking the statements of how the process is called, by simply starting it, without using the "ReadToEnd" of the standard output. This resulted in script successfully running. However in this configuration, I am unable to 'wait' for it in the application and the python code.   I have looked around a bit on the internet and have tried to implement some different approaches with no luck.

The following method is how I have successfully been calling it at 2.x under the 'old' frameworks.  In the brave new 3.0 / .Net core world, it processes "result = reader.ReadToEnd();" and never returns.  The expected outputs of the python file are not created.

       public async Task<string> run_arcpyReturnSurfaceProcessingResultsString(string pythonFile)  
        {

            string result = "";
            await QueuedTask.Run(() =>
            {
                GC.Collect();
                ProcessStartInfo start = new ProcessStartInfo();
                start.CreateNoWindow = true;
                start.FileName = @"c:\Program Files\ArcGIS\Pro\bin\Python\scripts\propy.bat";
                start.Arguments = string.Format("{0}", pythonFile);
                start.UseShellExecute = false;
                start.RedirectStandardOutput = true;


                using (Process process1 = Process.Start(start))
                {
                    using (StreamReader reader = process1.StandardOutput)
                    {
                        result = reader.ReadToEnd();
                        reader.Close();
                        process1.Close();
                        return result;
                    }
                }


            });


            return result;
        }

Any insight would be welcome.  

[CharlesMacleod]

I wasnt able to reproduce with a batch file - sorry not a python programmer. One thing I did do different was remove the QueuedTask but I dont think that is relevant.

FWIW, I did find a few other suggestions on solving issues reading stdout: here: https://stackoverflow.com/questions/1145969/processinfo-and-redirectstandardoutput

@echo OFF
ECHO This is a test
ECHO %0 %1

  string result = "";
  ProcessStartInfo start = new ProcessStartInfo();
  start.CreateNoWindow = true;
  start.FileName = @"E:\Data\SDK\Test\TestAddin\TestStdout.bat";
  start.Arguments = "Hello";
  start.UseShellExecute = false;
  start.RedirectStandardOutput = true;

  using (Process process1 = Process.Start(start)) {
    using (StreamReader reader = process1.StandardOutput) {
      result = reader.ReadToEnd();
      reader.Close();
      process1.Close();
      //return result;
    }
  }
  System.Diagnostics.Debug.WriteLine(result);
  //return result;

[Wolf · Accepted solution]

In addition to Charlie's answer there is also a arcpy toolbox sample available here: 

arcgis-pro-sdk-community-samples/Geoprocessing at master · Esri/arcgis-pro-sdk-community-samples (gi...

This sample will add a toolbox with the py script to ArcGIS Pro:

I modified the sample and added a button that will call the py script in the toolbox from .NET:

I attached the sample solution.

[Anonymous User]

Gents, 

Thanks so much for weighing in on this.  I vetted Charlie's test of using the same code to call a different bat file that was simply echoing results and got the same outcome as Charlie, so the approach this method uses seems 'valid'.  

I really appreciate the idea of binding the script to a tool.  I will grind a way a bit on that and see what I get.

A big thanks to both of you for the prompt replies.  Other than this glitch, the migration to 3.0 seems to be going pretty well.  

I will get back to this thread with the results of the tool binding approach.

Cheers

[Anonymous User]

Gents,

Thanks again for the assists.  I was able to emulate Wolf's approach and all appears well.  It introduces a bit more into the solution, but it is behaving.  I have a few other apps that are calling out to scripts that will hopefully follow suit.

 Not sure what the culprit is causing the previous technique to fail at 3.0, but can lead a full life with this.

Thanks again for the quick replies.