Geocortex Blog

Today we’re announcing the release of Geocortex Essentials 2.1.1. This is our first official maintenance release. At the release of 2.0, the products team decided that we needed a way to deliver defect resolutions to customers quickly. Previously we would create patches, but patches have their own set of problems:

• Installation of a patch involves manual steps
• The version of the assemblies packaged with a patch are the same as the version of the release (the only way to determine if someone has a patch installed is by the timestamp and file size of the patched assemblies)
• Creation of a patch requires overhead

So, maintenance releases will allow us to deliver defect resolutions in a product release. The idea is that we will be able to frequently release maintenance versions of our Geocortex Essentials software. You can distinguish a maintenance release from a major or minor release by looking at the software version number – we will increment the build number for maintenance releases, the minor version number for minor feature releases, and the major version number for major releases (look here for more on version numbers).

Supporting the idea of frequent maintenance releases is the development of our new installer which will support in-place upgrades as well as the traditional side-by-side installation so that applying the fixes in a maintenance release will be easy. Look for the new installer in early 2010.

To determine if a maintenance release contains resolutions to defects you are experiencing, consult the release notes. Geocortex Essentials 2.1.1 and the release notes are available on our support center.

About 3.5 months have passed since our 2.0 release of Geocortex Essentials. Since then, we’ve been busy. We released a “dot” release (2.0.1) in late July but I have to admit that it’s more exciting to announce a major or minor release containing new functionality.

For Geocortex Essentials Web ADF Elements we’ve put a lot of work into features that our customers have been asking for like support for coded domains and subtypes, and identify on WMS and raster layers. There are a number of other features and quite a few bug fixes as well!

For Geocortex Essentials REST Elements we’ve focused our attention on extensibility and developer support. Specifically, we’ve added the ability for a developer to easily augment our REST API by standing up their own custom REST endpoint. Developers can also create custom Site.xml extensions to add functionality to sites.

We’ve included a lot more into this release than what I’ve mentioned here – for those interested I encourage you to review the 2.1 release notes on our support center download page.

If you’re familiar with the software history of Latitude Geographics, you’ll know that we used be a Java shop. Now, we still use Java for our ArcIMS generation products, while we’ve adopted .NET for our ArcGIS Server Generation products.

In contrast to Java, Microsoft .NET has a very explicit versioning scheme. From MSDN:

“Each assembly has a version number as part of its identity. As such, two assemblies that differ by version number are considered by the runtime to be completely different assemblies. This version number is physically represented as a four-part string with the following format:
…”
http://msdn.microsoft.com/en-us/library/51ket42z(VS.71).aspx

When we build our .NET products, we want our assembly versions to reflect the released product version, and vice-versa.

Most of the software industry is in agreement on the use of the first two digits of a software version (major and minor). Incrementing the major version is typically reserved for releases containing major new features, rewrites, new technologies or paradigms. Incrementing the minor version signifies a release containing new features. There is some discrepancy in the industry; however, over the use of the build and revision numbers. Indeed, our staff has had differing views on how to use these numbers as well.

At the release of Geocortex Essentials 2.0, we’ve decided to change our perspective on this so it’s worth mention.

Pre-2.0
Prior to 2.0, a build number increment could include new feature development. That is to say that 1.3 and 1.3.1 both introduced new features; however, 1.3 was probably more significant than 1.3.1 with regards to the features it introduced. A “Hotfix” typically embodied a release containing bug fixes only (e.g., 1.4 Hotfix 1). It is worth mention that revision number is automatically generated, and typically reflects the number of physical builds created on our build server since the increment of a build, minor, or major version number (i.e., we “zero” the revision number when incrementing any other version number).

We also introduced “Service Packs” when we felt that the changes didn’t warrant a version upgrade (e.g., 1.5.2 SP1). This was not a decision based on a “rule”. I’ve always been dissatisfied with this somewhat ad-hoc approach to versioning, so following 2.0 we’ve decided to be a bit more procedural.

2.0 and Beyond
As with prior to 2.0 the major and minor version number will be reserved for major product architectural or conceptual changes, and the revision number will reflect the number of physical builds created on our build server. The main difference is the way in which we will treat the minor and build numbers. Going forward, we will increment the minor version any time that a release introduces new features. We will increment the build number to signify a release which contains bug fixes. A few examples will help clarify.

It is worth mentioning that a goal we have in the near future is to better support version upgrades of our Geocortex Essentials software. If we can distribute “dot releases” frequently without causing our customers the hassle of migrations during upgrades, we are better equipped to provide faster turn-around times between defect detection and resolution.

Well, I just opened the gates for people to download Geocortex Essentials 2.0. Though it’s been in beta since March, we’re pretty pumped to be shipping the final. It has been a huge project that kept growing the more we delved into it.

At version 2.0, Geocortex Essentials is divided into two tracks: Web ADF Elements and REST Elements.

Web ADF Elements includes everything from Essentials 1.x, plus some new Web ADF-related stuff.

REST Elements is totally new and follows ESRI’s RESTful development paradigm. Geocortex Essentials 2.0 introduces the Geocortex Essentials REST API. Using the REST API, developers can create JavaScript API, Flex API and Silverlight API applications that consume core Geocortex Essentials functions such as Data Linking, Template-based Printing and Reporting.

During the 2.0 beta period, Latitude product developers worked on documentation, defects, testing, the Geocortex Resource Center, and our associated client APIs (JavaScript, Flex and Silverlight).

Although ESRI released it not long ago, we also managed to squeak in support for Microsoft Bing Maps service types in both REST Elements and Web ADF Elements.

Yeah, we’ve still got lots of end-user features to port and/or create, but the final cut of Geocortex Essentials 2.0 is a major milestone for all of us on the Geocortex Essentials team and the underlying foundation is all there (along with several key initial features like data linking, reporting, and printing).

We recently created and rolled out the Geocortex Localization Portal. This web site makes translation easy for our resellers and partners who are translating Geocortex products into other languages (currently Arabic, Dutch, French, Korean, Norwegian, Polish, and Spanish).

Translators can visit http://translation.geocortex.com/ and log in using their Support Center account.

The site is a nice example of business process automation. Previously, translating a version of Geocortex Essentials followed a workflow similar to this:

Previous Business Workflow

This onerous process usually took a couple of weeks following a release of Geocortex Essentials, which meant that our translators would have to wait until they could use Essentials in their language. We didn’t want to begin the process using pre-releases or beta versions since there are sometimes changes between beta and release candidate versions of Essentials and the final release which would invalidate the translation.

Now, translation can be achieved by someone almost completely independently of Latitude Geographics, and without the issues described above. The new workflow looks something like this:

New Business Workflow

I work on and/or manage lots of initiatives that take months to roll-out, so I appreciate the odd small project that nonetheless has a noticeable impact on efficiency.

As part of the Geocortex Essentials product team, we have people who fix bugs. Typically we discover a bug ourselves or hear of the issue through a customer experiencing issues in their environment which we haven’t seen before. We take measures to replicate the issue, get to the bottom of it, and fix it.

But what do you do when you have an issue being reported from a few disparate customers (thus confirming its existence) which can’t be replicated in-house? Recently, our support department received screenshots from several different customers looking like this:

Locally, we’ve never seen Essentials do this – not on 64bit operating systems, not with IE6, nor in any combination of weird server environments we could concoct. So, we spent days trying to replicate this issue with a hunch it had something to do with the new CSS Multiplexer control we’d written for 1.5.2. This requires a bit of a tangent:

Certain versions of Internet Explorer prevent any one web page from adding references to more than exactly 32 CSS (cascading style sheet) pages. Don’t ask me why, but that’s the limit. Because Geocortex Essentials has a large number of web controls which are independent and modular, many of them come with their own CSS registration; thus, it didn’t take long before we discovered this limit (now this was a bug we encountered which warrants its own blog post altogether). The solution: the CSS Multiplexer. A web control which combines all CSS style sheets referenced on the page into one gigantic style sheet. I won’t get into the details, but it worked and improved performance as a side effect.

So when we see screenshots that look like CSS isn’t doing its job, the natural inclination is to blame the CSS Multiplexer. Long story short… this inclination proved wrong and it was not a bug. After a few days of wrestling with the CSS Multiplexer, and delivering patches to customers who were experiencing the issue only to discover the patches didn’t resolve the problem, it became evident that resolving issues using a black box approach wasn’t working. Our support department got in touch with one of the customers who was experiencing this issue and asked if we could set up an online meeting where we could see the bug and troubleshoot onsite. They agreed. Within one hour we were able to determine that a setting in IIS was preventing the CSS Multiplexer from fetching the appropriate style sheets and the customer was up and running.

We’re grateful to have customers willing to help us track down an issue like this. Of course, finding a resolution is of mutual benefit, but they could’ve just as easily asked us to investigate this with someone else. Moving forward, I think we’ll be much quicker to go down the bug observation route much sooner if we’re having trouble replicating it.

Incidentally, we’ll be publishing a knowledge base article on our support center for those who are experiencing this issue, and our developers have some ideas of ways we can get Essentials to “trick” IIS into behaving correctly to prevent this from occurring in the future.