Python collision with stand alone ArcGISPro application

[dkuida]

In the attached video I demonstrate a case where Python.NET code is running while ArcGIS.Core is initialized. Code fails on some commands. This is probably due to the internal implementation of ArcGISPro.Core. It is either using Python.NET or uses a different Python to C++ marshaling.

https://www.dropbox.com/s/dkndivr6p4ygqai/esr-python-collision.mp4?dl=0

1.        I run the application without initializing the host – it passes the Python call successfully (sec 16 )
2.        I initialize the Thread with Host.Initialize()
3.        I run the same code and it throws an exception

The exception is of a generic undefined error.

“External component has thrown an exception. System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.”

It seems that Host.Initialize()  gets control over all the threads, while Python is attempting to do the same.

Python.Net allows users to run python code form .net environment. I use “pythonnet_netstandard_py37_win” Nuget package which is in full compatibility with ArcGIS pro 2.7 (and python 3.7 ).

The same code runs successfully end to end when Host.Initialize() is not running in the same application.

Failed Attempts:

·       Creating a new thread in STA and MTA compartments prior

·       Using Default and Current TaskSchedulers.

·       Creating a dedicated TaskFactory before init

·       Creating a dedicated TaskFactory after init

The collision is happening on C++ authorization level. Thus has to be addressed by the ESRI team.

I have created a repository to replicate the issue both in running and not running state is provided here

gis-geodata/arc-gispro-python-net-licensing-collision (github.com)

 To replicate the exceptions comment out this line 

Full StackTrace

System.Runtime.InteropServices.SEHException (0x80004005): External component has thrown an exception.

   at Python.Runtime.Runtime.PyObject_Call(IntPtr pointer, IntPtr args, IntPtr kw)

   at Python.Runtime.PyObject.Invoke(PyTuple args, PyDict kw)

   at Python.Runtime.PyObject.InvokeMethod(String name, PyTuple args, PyDict kw)

   at Python.Runtime.PyObject.TryInvokeMember(InvokeMemberBinder binder, Object[] args, Object& result)

   at CallSite.Target(Closure , CallSite , Object , PyString )

   at System.Dynamic.UpdateDelegates.UpdateAndExecute2[T0,T1,TRet](CallSite site, T0 arg0, T1 arg1)

   at Cadaster.Gateway.EnvironmentConfiguration.PythonScripts.CreateCityUser(String cityName, Object arcpy, DataBase database) in I:\Cadaster\Gateway\EnvironmentConfiguration\PythonScripts.cs:line 108

[JoshuaBixby]

Since you believe this relates to licensing, how are you licensing your ArcGIS Pro install?

[dkuida]

Hey @JoshuaBixby 

I did not say I believe it is a licensing issue, I believe it is a threading issue.

But to answer the question - it is a floating license from a local license server.

The same approach persists with a named user ( EDN).

[JoshuaBixby]

You definitely mentioned threading, but your GH repo is named "arc-gispro-python-net-licensing-collision," so I thought you thought licensing was involved too.  I just read too much into your repo name.

If it is OK with you, I would like to move this discussion over to the ArcGIS Pro SDK space since people following that space might be a better audience.  That said, I think discussing with Esri Support is the next best step for you.

[dkuida]

Move it of course @JoshuaBixby I oversaw the SDK while looking for topics.

The local distributor of ESRI is the one in fact that told me to publish it here 🙂 As it would get a better chance to reach the dev team.