Everybody's Doing It

Everbody's doing what you might ask? Well, two things. First, everyone's blogging, on everything, software, GIS, other "stuff"..., so why not me?

Second, everyone's migrating their VB ArcObjects development to .NET (everyone that hasn't already that is)... so, in this, my first post, I have some tips for you.

First, just a few sentences to introduce myself. As an independent GIS and cartography consultant I work with ArcGIS and ArcObjects mainly focusing on the desktop applications. I'm a long time VB programmer who moved to the world of VB.NET 18 or so months ago, and I'm finding it very much to my liking.

I'll start things out with a few tips for anyone that is now, or will soon be, migrating their ArcObjects development from VB6 to VB.NET. There's a lot to think about, and the points below are by no means an exhaustive, or even an orgainzed list.

1) I think that Visual Studio .NET is an improved development environment compared to VB6 and it makes me much more productive as a developer. For VB6 developers, the .NET and the .NET IDE has great features (error highlighting, code completion, "helper" libraries, etc.), and these improvements more than compensate for any initial unfamiliarity with the language syntax.

2) When migrating your In ArcObjects code, one big thing that you need to know about migrating is that some members are "non-compliant" in .NET. This is just a fancy way of saying that they "don't work" in VB.NET/C#.
So...bookmark this page:

(esri edn) Migrating .NET Code and Non OLE Compliant Members

Non-compliance is the type of thing that can really trip up a developer because the errors that result are really hard to translate, and the individual ArcObjects (as you might have guessed) aren't specifically documented with this info.

3) Now that you're in .NET, you'll need to take another look at how you deploy applications/components written in .NET. As with most any deployment, my strategy for this is to just "figure it out once and reapply the strategy over and over". Here are some general things to keep in mind. See my next point for some specific help with .NET and VBA.

a) To use your .NET component, client machines will need to have: MS .NET runtime 1.1 or 2.0. 1.1. is part of the XP install now, I'm not sure when 2.0 will be.

b) Client machines also need the ArcGIS .NET interop assemblies. These are installed from the ArcGIS Deskop install (NOT the developer toolkit install). One tricky thing is that you need the MS .NET 1.1. runtime installed BEFORE you even have an option to install the ESRI libraries.

c) Finallly, you won't use the old regsvr.exe to register COM components.Instead, there's a .NET application called regasm.exe that, well, does similar but different things.
There's some good online documentation about this from esri that'll point you in the right direction:

Short but sweet: (esri edn) Registering Components With COM

Heavier weight: (esri edn) Deploying .NET Components

4) A fact of life we'll be living with for awhile is that, well, Microsoft has moved on to .NET, but ArcGIS is still built on COM. Of course, this obviously doesn't prevent you from developing ArcGIS components in .NET, it's well documented how to do this in the esri and ms doc.
But, what about VBA? I asked myself the other day..into night. What about the library of .NET objects that I built (for converting ArcGIS "stuff" to google kml "stuff" btw). These objects _use_ arcobjects, but aren't arcobjects components. They're just, well, classes that do "stuff".

How can I use these in from ArcMap VBA for example (or from VB6, or from Catalog's VBA, etc.)

Well, I found what I would say is the most informative piece of information I've found on the internet in a long time.

Read this article: (15 seconds) COM Interop Exposed

It will tell you how to expose your .NET classes to COM, so that you can use your objects in VBA, or VB6, etc. This article is a gem, I followed the steps, and I'm now using my objects in VBA.

Talk to you soon...

-Cory

www.eicher-gis.com