Python add-ins vs. .NET add-ins?

[BartłomiejStaroń]

from (http://gis.stackexchange.com/questions/67279/python-add-ins-vs-net-add-ins)

I found in ESRI .NET help:

    [INDENT]Python

All ArcGIS Desktop applications include an embedded scripting language called Python. Many areas of ArcGIS�??particularly geoprocessing�??are accessible through simplified Python application programming interfaces (APIs), making it easy to author and automate common tasks. Python scripts are easily shared and can be produced without an external development environment. There are a variety of public domain Python modules focused on areas such as science, engineering, and mathematics. With all its strengths, Python is not suited for every programming task. Although coverage is improving, not all areas of ArcGIS are currently exposed to Python. In addition, the editing and debugging experience in Python is not as sophisticated or easy to use as those included with commercial development environments such as Visual Studio. Lastly, you cannot listen for and respond to ArcGIS events, implement a COM interface, or plug into ESRI�??s many COM extensibility points using Python.[/INDENT]


and in ArcGIS Desktop help:
[INDENT]
    ArcGIS 10.1 introduces Python to the list of languages for authoring Desktop add-ins, providing you with an easy solution to extend desktop functionality. To simplify the development of Python add-ins, you must download and use the Python Add-In Wizard to declare the type of customization. The wizard will generate all the required files necessary for the add-in to work.[/INDENT]


If Python and .NET add-ins have the same functionality?
Does that mean that I can do the same thing in Python as .NET ??

[markdenil]

You can do SOME to MANY of the same things in Python as in .Net
There are a good many things Python cannot currently reach,
and all geo-processing goes through a geoprocessor (which can be slow to spin up).

The Python Add-In also has a rather primitive interface.

You CAN call .Net routines from Python scripts,
(and it is roumored to be possible to access ArcObjects from Python, but that is a bit snake-y)

So, Python Add-ins are great for what they are,
and allow you to avoid futzing with .Net (which is always a plus in my books)
but they are limited.

[VickiMartinez]

In a nutshell, here is my take on the advantages of one or other type of add-in.

Advantage .NET: last I heard, there is no intrinsic UI functionality with Python.  So if you want to have a add-in that has a form for users to input information, etc, then .NET is the way to go.  At the Dev summit this year, they were saying that using Tkinter was causing major problems, and not to use it with ArcGIS.  I don't think that has been resolved in 10.2.  I am primarily a .NET dev, so I prefer all of the bells and whistles that come with using Visual Studio - such as a built-in debugger.  Plus I am used to the .NET environment.

Advantage Python: arcPy is nicely optimized for doing some bulk map operations, so depending on what you want to do, it may be tons easier in arcPy.  This is especially true if you don't require any user interaction to run the tool.  For speed of development, Python may be what you prefer.  Although, I did find setting up a Python Add-in to be a bit trickier at first, once you have done it once, you won't have any problems.

Advantage neither:  There are some things that can be done in ArcObjects that cannot be done in Python and vice-versa.  Your choice of language might be limited by the task you need to complete.

[RebeccaStrauch__GISP]

Advantage Python: arcPy is nicely optimized for doing some bulk map operations, so depending on what you want to do, it may be tons easier in arcPy.  This is especially true if you don't require any user interaction to run the tool.  For speed of development, Python may be what you prefer.  Although, I did find setting up a Python Add-in to be a bit trickier at first, once you have done it once, you won't have any problems.

If you have custom toolbox with python scripts that are already setup to take advantage of the built-in user interface for getting attributes, it is easy to turn this into a addin, very few steps.  This may not be the user interaction that @Vicki is refering to, but if all you need is the basic tool interface, this works slick.

Assuming you have a custom Toolbox and python scripts with the parameters/GUI already setup (i.e. a standard ArcGIS Toolbox)

• Download, unzip, run Addin wizard. Make sure to create a toolbar with at leat one button.

• Copy <your toolbox>.tbx  into the addin's   \install  folder
• Create a subfolder under \install called   "scripts"   (or whatever you want to call it)
• Copy all the scripts associated with your toolbox into the \scripts folder
• In Catalog, open \install\<your toolbox>.tbx, make sure relative path box is checked, and point source to new location in \Install\scripts

• Modify \install\<addin>_addin.py, add the following afer the other import statements:

import os
relPath = os.path.dirname(__file__)
toolPath = relPath + r"\<yourToolBoxName>.tbx"

• For each button under def onClick(selfk):  replace each pass  with YourToolName :   (where <YourToolName> is the name listed in your Toolbox properties)

pythonaddins.GPToolDialog(toolPath, <YourToolName>)

• Compile, deploy, test

If this doesn't make sense and you would like more info, let me know.  You can check out the help for GPToolDialog, but I find the help is still missing a few critical steps to make this easy.  I have another forum entry and some powerpoint slides if anyone is interested.

Edited 4/8/2015 to fix bad formatting from old forum to GeoNet conversion.  Also added a PDF of a presentation I did at our local dev meetup a couple years ago on the subject....older, but should still be valid.

[ducksunlimited]

Just checked the agenda of Developer Summit 14, I didn't see there is a tech session for Building Python Add-ins, but there is one for .NET. Does that mean .NET Add-ins are preferred over Python Add-ins? and why? I have done a .NET add-in before but really didn't like the deployment procedure. Looks like Python Add-ins are much easier for sharing and long-term maintenance.

[JasonScheirer]

No, it does not mean there is a preference for one or the other. They have different capabilities and one or the other should be used based on how much fine-grained control you need. The lack of a tech session is simply because there is already plenty of documentation online for making Python Add-Ins and the process for making one should be pretty straightforward.