Latest Contributions by Vidar

Hi,   Was just wondering what the plans are for developers wanting to use Visual Studio 2026 for making add-ins? I suspect I may be for version 3.7 and beyond.   Just curious to know 🙂 ... View more

Win11 on Pro 3.4 Hi,   I'm trying to clone (on a relatively new machine) the python envionment using the clone button in package manager. It gets along quite far in the process then gives out an error: ERROR conda.core.link:_execute(950): An error occurred while installing package 'esri::arcpy-base-3.4-py311_55347'.   Can anyone help? Is this a permissions issue perhaps, as we are newly working under a more restrictive environment where we can't install software when and where we want? I haven't installed conda or have another Python envionemnt installed. Only the default one by Pro 3.4 and ArcMap 10.5 (Python 2.7).     ... View more

Hi, I’m hoping to get some insight or advice from the community on an issue we’re encountering with a custom ArcGIS Pro Add-in developed in C#. Software Stack: ArcGIS Pro 3.2.4 (Advanced + Spatial Analyst) Windows 10 Pro (Build 19045.5737) Visual Studio 2022 (v17.13.6) Python environments: arcgispro-py3 (default) and a separate standalone Python 3.9 installation (required for pygplates)   Objective We have a custom Add-in button that runs two Python scripts in sequence: Script 1 runs using the ArcGIS Pro environment (propy.bat). Script 2 runs in an external standalone Python 3.9 environment (due to dependency conflicts with pygplates). Script 1 runs again for some arcpy based clean up and other misc stuff. This all works well until the user manually adds a raster to the map (via Map → Add Data → Data). After doing this, the second script fails when executed via the standalone environment.  This is not the only thing that causes this problem - if the user opens up the interactive Python prompt in Pro - that causes the same issue. Symptoms After adding a raster in the Pro UI, attempts to run the tool again affects the external Python script fail with errors like:   Fatal Python error: init_import_site: Failed to import the site module ... TypeError: type 'types.GenericAlias' is not an acceptable base type   If we run the same scripts from a standalone .NET Console app (i.e., not from within Pro), the scripts work perfectly, so I know it's nothing to do with scripts themselves.  The same scripts also work perfectly if run within a Python Toolbox - its only if the scripts are triggered from C# using the System.Diagnostics.Process instance. See code example below: public static string RunPythonScript(string scriptFileName, string[] scriptArguments, string pythonPath) { string scriptPath = Path.Combine(@"D:\Projects\FooProject\PythonScripts", scriptFileName); if (!File.Exists(scriptPath)) return "Python script not found."; if (string.IsNullOrWhiteSpace(pythonPath)) pythonPath = GetPythonPath(); if (string.IsNullOrWhiteSpace(pythonPath)) return "Python environment not found."; var args = new StringBuilder($"\"{scriptPath}\""); if (scriptArguments != null) { foreach (var arg in scriptArguments) args.Append($" \"{arg}\""); } var startInfo = new ProcessStartInfo { FileName = pythonPath, Arguments = args.ToString(), UseShellExecute = false, RedirectStandardOutput = true, CreateNoWindow = true }; using var process = new Process { StartInfo = startInfo }; process.Start(); string output = process.StandardOutput.ReadToEnd(); process.WaitForExit(); return output; } Question to the Community Has anyone else encountered issues with the Pro environment interfering with external Python script execution from within a C# Add-in? Is there a known workaround for running Python scripts in multiple environments from a Pro Add-in? Could Pro be “locking” or initializing some internal Python state that affects subprocesses? I appreciate this will probably be something to do with Conda and the internally installed Python environment Pro installs. Is there a recommended pattern for isolating or sandboxing these environments in a Pro-based C# add-in workflow? Why It Matters Our workflow depends on Python packages that cannot be installed in the default ArcGIS Pro environment (e.g., pygplates). Being able to reliably switch environments from a Pro Add-in is essential for our tool to function correctly and do the calculations we need to do with pygplates. Currently, interaction with the native Pro UI (like adding rasters) breaks that workflow and puts pro into some locked state with the default Python environment. Would appreciate any insights, workarounds, or confirmation if others have seen similar behavior. Thanks in advance! ... View more