Over the last 3 years we’ve been building a state-wide enterprise forest managment system for Michigan. During the main development and stabilization phases, we locked the application at ArcGIS 8.3. However, with the upcoming release of ArcGIS 9.2, version 8.3 will become deprecated. What this means is that ESRI will no longer support a direct upgrade between ArcSDE 8.3 and ArcSDE 9.2. So, it’s time to bring the entire app up to the latest version – 9.1. Since I need to document what I’m doing, I thought that I’d share a generalized version of the various steps, how they go, the problems we encounter, and the solutions we use. Hopefully it will be interesting/useful reading…
Code Upgrade: ArcGIS 8.3 to 9.1:
The thing to address is the code – since there was a breaking change in ArcObjects between 8.3 and 9.0, all the code must be re-built, using new references the the new libraries (bye-bye esricore!). Now, it’s worth noting that this is a big system. We’ve got 53 VB6 COM dlls, containing 100′s of commands, GUIs, class extensions, user managment, permission managment etc etc, so we were somewhat concerned about how much work the code upgrade would be.
Happily, we found that the ESRI VB Code Converter did a pretty good job of it. I talked with the developer who handled this upgrade, and besides having to work out the build order of the projects because of dependancies (my bad – I should have told him where to find that!), there were very few errors, and it took less than 8 hours to complete. In a few cases, class names need to be fully qualified when dimming them (i.e. IPoint must be esriGeometry.IPoint)
Not a whole lot to report – the tools work, and it’s not that big a deal.
Testing the Changes:
From this point, we pushed the build out onto a “beta” system in our Citrix farm, for our client to test. I mention this because having this Citrix farm has been really helpful in getting rapid feedback from our clients. However, from time to time we have some strange behavior on these systems. For example, we posted the code, our client logged into the box, and something did not work. We checked it on the development boxes, and it ran just fine. We logged onto the “beta” box via Citrix, and try it – it works. We tell our client. They log back into the same box, with us shadowing them, and it fails.
So you’re following along: on one box (beta) with one install of ArcGIS, and one set of application dlls, the application works for one user and not another. Joy. It gets more interesting – when we have our client log into Citrix using one of our logins, it fails. When we login, it works. Additionally, the “failure” is not really a failure in the typical sense. Basically a part of the interface freezes, and the cursor changes to a cross hair. There is no code in the form in question which changes the cursor.
This is still an on-going problem, so if anyone has ideas, I’d love to hear about them.
Up Next: Upgrading ArcSDE to 9.1, and making some schema changes…