Exploring ArcObjects through C# or VB from Python background

Question

While I understand that this may be off topic to an extent, I am in a bit of a bind and could use some help directing my thought process and research.

I have little programming background aside from:
1) Scripting in a language similar to C
2) Practical use of Python for use in geoprocessing with ArcGIS

This has worked just fine for me so far, but there appears to be a need for me to move into a .NET-based language so that I can start making use of the tools exposed in ArcObjects that ESRI has not yet made available through Python. A decision is being made by my management (with some direction from me) on whether the company should move forward and create a standard for coding in ArcObjects that is aimed at using VB or C#. The main considerations (since I am the only person who will be taking part in this) are future extendability, "safety" of code, and readability. Most of these concerns appear to be things that can be dealt with in the writing of the code as opposed to the language itself, but I don't know enough to be certain.

I've read an article or two comparing C# to VB in terms of .NET, but I would like to ask for further reasoning to consider when deciding on one language over another for a person of my background. What are the most important things to keep in mind when choosing which of the two languages to begin study in for use with ArcObjects?

Sorry if this is too verbose! I simply want my need to be understood.

Thanks.

EDIT: Responses have been great. I went with Dan's answer since it covered all the ground I asked about and went the extra step to point me at IPython.

Answer 1

VB.NET vs C# really does come down to, mostly, a matter of opinion.

Mine would be strongly in the C# camp, as VB.NET's predecessors (VB & VBA) actively encouraged horrible coding practices ("On Error Resume Next", anyone?) and they live on, in the culture surrounding the language and in gestures towards backwards compatibility.

However, given your specific situation, I would actually float a different idea, specifically IronPython.

It seems a fantastic match for this need:

move into a .NET-based language so that I can start making use of the tools exposed in ArcObjects that ESRI has not yet made available through Python

Cons:

• You will be living on an obscure and bleeding edge, especially within the ESRI community but even to some extent in the larger .NET community.

• You'll spend some time troubleshooting obscure bugs that come from the impedance mismatch of several layers of abstraction: IronPython is almost exactly like Python; ESRI's .NET API is almost like the underlying COM it's all written in....

Pros:

• You get to explore an obscure and bleeding edge, lighting the way for the ESRI and .NET communities to follow in your footsteps!

• You can keep working in python (until you hit other limitations) and make the move to other .NET languages a gradual one instead of a sharp transition: you can mix and match the right language for the right need, in the same project.

• Having a fast-and-loose scripting language at hand is extremely helpful even after you've moved most development to a more formal/structured language.

• Your existing python geoprocessing scripts will be somewhat portable (the GP object is visible in .NET-land too, and IronPython supports IDispatch so there's a chance they might be directly portable with just a few code-line changes).

I really wish more people were doing this. (And if they are; I wish they were publicising it!)

Note: simply for learning the ArcObjects API & regardless of doing production development, IronPython gives you something neither C# nor VBA can: a REPL -- one of the best ways to explore an API by far.

Answer 2

VB.NET is a good language, much better than the old VB, but still I am strongly in the C# camp. For someone entering the .NET world, it's better to take advantage of the fact you are essentially in a learning process and incorporate taking on C# in it as well.

I will not compare the two languages here as there has been plenty written about them, as well as many pointless flamewars fought. Here's my two cents coming from extensive experience with both of them (along with few other languages):

• C# is much more readable and natural in the .NET world. It is THE prominent language to develop in on .NET framework.

• Microsoft is heavily investing in it, it evolves quickly and has recently incorporated some features of functional languages which will get under your skin easily. VB.NET is (and will be) sort of kept around, but new features and tooling are almost always first available in C#. In another words, both are first-class .NET citizens, but they are not exactly equal.

• Before C# 4, COM interop was for some scenarios easier in VB.NET, which does not hold true for C# 4. Note you can take advantage of some C# 4 features and still compile your code to target .NET Framework 3.5 (which is supported by Esri).

So in my opinion, only if you have large legacy codebase in VB which you cannot afford to rewrite, go with VB.NET. Otherwise there is no reason why not to get your job done in the cutting-edge .NET language which is C#.

Answer 3

With the Microsoft .NET Framework, VB and C# are both CLR languages, and are technically equivalent. There are a few differences, but they both offer similar features like exception handling, etc.

Furthermore, documentation from Esri and Microsoft typically provide examples for equivalent operations in both VB.NET and C#.

It really comes down to the preferences of your development team (or yourself, if you are the team).

Personally I feel that VB is more readable, as I have a VBA and Python background. Other programmers from Java or C++ backgrounds are more familiar with C#.

Answer 4

This is not intended as an answer per se, but is submitted in reference to the IronPython answer posted by Dan S. I wanted to share an actual IronPython + ArcObjects script that I wrote a while ago. I was struggling to trace ArcObjects calls in Oracle, and thought that it would be easier with Python because I could issue calls interactively and see immediately what the trace output looked like. I never got that far, but I did write this little testing script. By the way, my use of import * is not advised.

So here it is:

import clr
import System
clr.AddReference('ESRI.ArcGIS.Geodatabase')
clr.AddReference('ESRI.ArcGIS.Server')
clr.AddReference('ESRI.ArcGIS.GeoDatabaseDistributed')
clr.AddReference('ESRI.ArcGIS.System')
clr.AddReference('ESRI.ArcGIS.DataSourcesGDB')
clr.AddReference('ESRI.ArcGIS.Geometry')
from ESRI.ArcGIS.Geodatabase import *
from ESRI.ArcGIS.Server import *
from ESRI.ArcGIS.GeoDatabaseDistributed import *
from ESRI.ArcGIS.esriSystem import *
from ESRI.ArcGIS.DataSourcesGDB import *
from ESRI.ArcGIS.Geometry import *

# create connection, context, workspace
conn = GISServerConnectionClass()
conn.Connect('localhost')
som = conn.ServerObjectManager
ctx = IServerObjectManager.CreateServerContext(som, 'MyGeodataService', 'GeodataServer')
gds = IServerContext.ServerObject.GetValue(ctx)
ws = IGeoDataServerObjects.DefaultWorkingWorkspace.GetValue(gds)

# set up tracing
IWorkspace.ExecuteSQL(ws, "alter session set sql_trace = true")
IWorkspace.ExecuteSQL(ws, "alter session set tracefile_identifier = 'pytest1'")
IWorkspace.ExecuteSQL(ws, "alter session set cursor_sharing = 'similar'")

# test query
t = IFeatureWorkspace.OpenFeatureClass(ws, 'MY_TABLE')
c = ITable.Search(t, None, False)
MY_FIELD = ITable.FindField(t, "MY_FIELD")
r = ICursor.NextRow(c)
while r is not None:
    v = IRow.Value.__getitem__(r, MY_FIELD)
    print v
    r = ICursor.NextRow(c)

# clean up
ws = t = c = None
IServerContext.ReleaseContext(ctx)