When any major release of Esri ArcGIS comes out we typically advise our clients to hold off on upgrading until both Esri and Telvent have released at least one service pack to their initial release. At version 10 there were so many major architectural changes to the Esri foundation that this waiting period was extended by many utilities, and we believe that this was a solid choice.

However, we have now seen the release of Esri ArcGIS 10 Service Pack 3 and Telvent ArcFM™ 10.0.3. And we would absolutely recommend that you make the jump and start taking advantage of version 10! We’ve begun to upgrade our clients, and this article will outline some of the major technical challenges to undertaking this endeavor.

Our clients use a blend of software including ArcGIS Desktop, ArcSDE, ArcEngine, ArcGIS Server, ArcFM™ Desktop, Designer™, Geodatabase Manager™, Responder™, ArcFM Viewer™, and most importantly, plenty of customizations. So we’ve had to run the gamut with an upgrade and we hope this article will help you out.

The Databases

An upgrade typically starts with the SDE geodatabase. The first question we get asked is whether you have to get to state zero to perform the upgrade, and the answer is definitively “no.” Some major changes have occurred to the Esri infrastructure used to upgrade your geodatabase that make it easier than it has been in the past.

Previously we would install the new version of the SDE software and then use the SDE command line tools to perform the upgrade on the database. Now at version 10, Esri has made the SDE upgrade available as a geoprocessing task directly in ArcCatalog. Running the upgrade is as simple as connecting to the geodatabase via a direct connection, right clicking the gdb and running the upgrade from the properties tab. The GP task will run both prerequisite validations and will then perform the upgrade to the underlying schema.

We hit a few bumps with invalid domain entries, geodatabase-registered tables that didn’t exist, and some replicas that didn’t exist. But on the whole the database upgrade ran without issue once we resolved those smaller logistical issues.

The Telvent upgrade included the usual two step process of creating the MM tables and upgrading the geodatabase, and they worked without any issues at all.

Next we moved onto upgrading the Responder™ database. Telvent always includes upgrade scripts (both Oracle and Microsoft SQL Server) for upgrading the underlying schema. These provide a good starting point and we would recommend creating custom upgrade scripts to ensure your tables, sequences, and stored procedures are all up to date. This went very smoothly as well and with a few modifications we were able to script out the RX database upgrade.

The Product Software

Next we moved on to installing the latest and greatest client product software. This was a relatively smooth step across the board. Our biggest challenges have come as clients have moved their server implementations to 64 bit operating systems. Almost all of the product software is still compiled as 32 bit applications. The 32 bit applications can run as 32 bit processes on a 64 bit machine. For the most part, as long as you have a 32 bit version of the Oracle client (not applicable for SQL Server) then the apps will work right off the bat. The only intricacies we ran into were related to the various server web apps that had to run on Microsoft IIS 7 on a 64 bit machine. For these web apps you need to take a few extra steps, including:

• Enabling 32 bit web apps on your 64 bit server
• Setting up your web application to run in a 32 bit application pool
• Ensuring you have the right versions of the .Net framework registered with IIS to get ASP.Net web apps to run

Most of the time, this will take care of your issues. However, we found that when running on Oracle we still could not get our web apps to communicate successfully with the Oracle geodatabase. In the end we found we had to install ODP.Net on top of the base Oracle client software.

ODP.net is installed as part of the Oracle ODAC software and adds a few extra components that are required for Microsoft .Net applications to talk to the Oracle database. Make sure your ODAC install version matches the current Oracle client version as well, as you can easily corrupt your client install if there is a mismatch. This problem doesn’t exist when using Microsoft SQL Server, which should simplify your implementation.

The Customizations

And finally we come to the challenging part of the upgrade. As hard as Esri and Telvent work to ensure our upgrades go smoothly, the customizations are always the wild card. As mentioned in a previous article, if you have Visual Basic customizations, now is pretty darn good time to have them converted to Microsoft .Net. This is the last major release that VB will be supported and we’d recommend not waiting until the absolute last minute to take care of this major issue. Get this out of the way first.

Next, it should be noted that at ArcGIS 10, Esri and Telvent are both still based on the Microsoft .Net framework 3.5. This was the same version used by 9.3.1, so no major changes there; just make sure your Visual Studio projects are set with the correct target framework. At 10 Esri officially supports Visual Studio 2010 with all its bells and whistles and Telvent will officially support 2010 as of 10.1 coming out next year. Have no fear though, you can still use Visual Studio 2010 with Telvent upgrades at 10.0.X and we believe this is the way to go.

The main limitation comes when you try to install the Telvent ArcFM™ Software Development Kit (SDK). The SDK requires Visual Studio 2008 because it is installing various add-ins for the integrated development environment. These add-ins aren’t required for an upgrade, so the trick is to install Visual Studio 2008 alongside Visual Studio 2010 and then the ArcFM™ SDK will also install without any issues. The code will be upgraded as you open your VS solution files in 2010 for the first time. This all went completely smoothly and we didn’t encounter any problems.

In an effort to make ArcMap customizations easier to install and register, Esri has decided to move away from Microsoft COM as the technology used to register your custom dlls with the host computer and with the ArcGIS software. Instead you must generate certain xml add-in files that will be registered within ArcMap to tell it to load your customization. This is a pretty cool idea that will prevent the “dll hell” nastiness that many developers have dealt with for years.

We started down that road but found that for Telvent customizations we are not all the way there quite yet. Here are the main steps you’ll need to follow when upgrading your Telvent/Esri code:

• For Telvent upgrades we ended up leaving the COM category registration as-is for our upgraded commands, tools, AU’s, etc. And each individual co-class keeps its own unique GUID and ProgID as well. Finally the resulting dll’s should still be registered with COM at this point.
• For each co-class that implements an Esri/Telvent interface you will now need to add in a new .Net attribute to the top of the class to describe what the class is – i.e. a command, tool, AU, PX subtask, etc. An important note is that if you are using abstract base classes (i.e. a generic command class that all other commands inherit from), this attribute cannot be placed on the base class, but must instead be placed on each individual co-class. Some common attribute examples include:

  Command Button: [ComponentCategory(ComCategory.ArcMapCommands)]

  Special AU: [ComponentCategory(ComCategory.SpecialAutoUpdateStrategy)]

  Attribute AU: [ComponentCategory(ComCategory.AttrAutoUpdateStrategy)]

  AutoText: [ComponentCategory(ComCategory.MMCustomTextSources)]

  Subtask: [ComponentCategory(ComCategory.MMPxSubtasks)]

  TreeTool: [ComponentCategory(ComCategory.D8DesignTreeViewTool)]

  If a single co-class implements multiple interfaces, just add multiple attributes to the class. These attributes are used later to register the class with the correct categories for both Esri and Telvent. To reference any of these ComCategory entries, you’ll need to add a using statement to your class as well: using Miner.ComCategories;

• Once you’ve built the dll with your custom components and it has been registered with COM, you can now run the Telvent RegX.exe program, which will take care of getting your customizations registered with ArcMap. The RegX.exe file is installed within any ArcFM™ Desktop 10 installation to this location: C:\Program Files\Miner and Miner\ArcFM Solution\Bin\RegX.exe. At the simplest level you can drag and drop your custom dlls onto the RegX.exe and it will work its magic. But most of the time we need a bit more control over the process.

  If you want to script/automate this process, pass the full path and name of your new dll as a parameter to the RegX.exe and it will pop up a DOS prompt that shows you the work it performs as it makes the registrations. If you want to unregister the dll from ArcMap simply add the flag “/u” to your call to RegX.exe. So an example might be:

  Register: “C:\Program Files\Miner and Miner\ArcFM Solution\Bin\RegX.exe”
  “C:\MyCustomTools\CustomArcMapTools.dll”

  Unregister: “C:\Program Files\Miner and Miner\ArcFM Solution\Bin\RegX.exe”
  “C:\MyCustomTools\CustomArcMapTools.dll”/u

  On a development machine you will likely just want to add this as a post-build event to your Visual Studio projects.

• The above step takes care of registering our components on our development machine but we also likely need to take care of this same process within an installer (i.e. setup.msi file.) To do this you may want to fully automate the calls to RegX.exe for the registration on the install and the un-registration on the uninstall of the custom application. For this we’d recommend creating custom actions within your .Net deployment project to essentially automate the calls to RegX.exe.

The above steps should get you up and running pretty quickly to get your legacy ArcMap customizations visible and accessible in 10. Telvent has published a handy flow chart (courtesy Bill Bott) to help with your upgrade workflow at: http://resources.arcfmsolution.com/Customizations/CustomizationFlow.pdf

Hopefully our above steps further augment this workflow when you get to the custom installer step. The RegX.exe registration of your dlls will handle creating the efcg files (mentioned in the workflow) and deploying them to the necessary directories, as well as provide you a simple and automated way to install and uninstall your custom code without having to dig too deep into the weeds.

Now that you have your components registered with ArcGIS 10, we still need to make sure they function correctly! Most of the functionality should carry forward with no issues, but we ran into two bumps that were worth mentioning.

First off, if any of your code referenced data in the SDE.GDB_* tables in the SDE schema, it must be rewritten because these tables are long gone. At 10, Esri consolidated the information into four new tables centered on the GDB_Items table.

The GDB_Items.Definition column actually contains XML that further provides all the details you may have used in the past. You will then need to query into this XML to get at the data that your customization might need to act upon. In Microsoft SQL Server the GDB_Items.Definition column uses native XML and you can use some of the advanced SQL Server XML query tools to get at the data. In Oracle the same column uses ArcSDE XML which is stored in binary form and as such this data cannot be directly accessed with SQL.

To get around this, Esri created a view called GDB_Items_VW that will convert the data into an XML form that is usable, but you must have your ArcSDE dlls correctly registered with Oracle for this to work. If this is an issue for you give us a shout… it’s too long to write up here.

Once you play with the new GDB tables you should be able to figure out how to get to the data you need. Esri has a pretty good posting on the new tables as well which can be accessed here: http://help.arcgis.com/en/arcgisdesktop/10.0/help/index.html#/A_quick_tour_of_geodatabase_system_tables/006z000000tr000000/

The second bump we hit was in upgrading any type of batch application, including a batch exe, a console exe, or a windows service. Previously, you would typically check out your Esri and Telvent licenses and you would then be on your way with your batch processing. But at 10, Esri re-architected their ArcObjects code so that you now have to tell the process what Esri product you will be using BEFORE you even check out a license.

Luckily this is achieved with a simple code update, but if you don’t add it in, nothing will work! For an ArcGIS Desktop batch process you can just add the following line right before you check out your Esri and Telvent licenses:

ESRI.ArcGIS.RuntimeManager.Bind(ESRI.ArcGIS.ProductCode.Desktop);

Adding this line will require you to add a reference to ESRI.ArcGIS.Version. If you add this code to the same location as your license management you should always be safe, because it needs to be called before you do any ArcObjects processing… just like the licensing call.

Summary

Hopefully we’ve quelled some of your fears about upgrading to Esri & Telvent 10. We believe the time is now and would highly recommend moving to 10 as soon as you can fit it into your plans (and your budget) because the benefits far outweigh the cost.

The steps here are meant as helpful tips from a company that has been through the details and tried multiple approaches to almost everything. For most utilities the best course of action will still be to hire in a capable consulting firm who can guide you through the inner workings of all of these items and ensure your database and customizations are fully tested and ready for prime time. And don’t underestimate the testing… plan on a hefty test phase to test all of your functionality AND to get familiar with all of the changes to the core applications.
We hope you find this article helpful and wish you the best of luck with your upgrade to v10! If you have any questions or need any assistance please don’t hesitate to contact us.