Take the 2-minute tour ×
Geographic Information Systems Stack Exchange is a question and answer site for cartographers, geographers and GIS professionals. It's 100% free, no registration required.

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.

share|improve this question
    
Detials: Given the ".NET" context, I think you mean VB or VB.NET—not VBA. –  Mike T Mar 28 '11 at 21:54
    
Oops, great point. That's a typo. –  Nathanus Mar 28 '11 at 21:59
    
C# is easier to read because its less verbose, there are more C# jobs overall, and I will be really surprised if you can do something with VB.NET that you can't do with C#. –  patrick Mar 28 '11 at 22:01
add comment

4 Answers

up vote 7 down vote accepted

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.

share|improve this answer
1  
IronPython can be also easily embedded in your application and/or interoperate with C# code. The COM interop is not as convenient as it could be, though. Moreover, while I love IronPython, I would not recommend it to someone who is just starting with ArcObjects since the additional layer of interop and abstraction can be easily confusing for beginners. –  Petr Krebs Mar 29 '11 at 6:46
    
Apparently you can do REPL in C# if you're using Mono: mono-project.com/CsharpRepl I'll be honest, I just looked it up out of curiosity when I read your answer. –  Sasa Ivetic Mar 29 '11 at 13:38
    
Petr -- I second both those points & tried to make them fairly evident in the pro/con lists. Related: If you've been doing this, it would be awesome if you wrote it up! ;) –  Dan S. Mar 29 '11 at 13:41
    
@Petr ... after a minute of thought I added extra emphasis to the "obscure & bleeding edge". –  Dan S. Mar 29 '11 at 13:53
1  
IronPython works well with ArcObjects, in my limited experience. The biggest frustration is the lack of native Python support for interfaces, and ArcObjects is almost entirely based on interfaces. Support for properties is also missing. This means that many calls will look goofy compared to the documentation. Compare (C#) IWorkspace gdsWS = gdsObjects.DefaultWorkingWorkspace; to (IronPython) gdsWS = IGeoDataServerObjects.DefaultWorkingWorkspace.GetValue(gdsObjects). –  nw1 Mar 29 '11 at 17:17
show 10 more comments

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#.

share|improve this answer
add comment

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#.

share|improve this answer
add comment

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)
share|improve this answer
    
Thanks for this -- Something about the way the interfaces are working doesn't ring right -- but I've yet to use IronPython with ArcObjects. It may also be an issue with how long ago you did this --- IronPython is a fairly active project. I don't have a local DB right now, so I can't try it exactly, but maybe I'll do a test sooner rather than later. –  Dan S. Mar 30 '11 at 20:46
    
@Dan -- It's pretty fresh: IronPython 2.7 Beta 2 –  nw1 Mar 30 '11 at 20:51
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.