Checking eConnect Version Number Programmatically

Lately, it seems that every time I deploy an eConnect integration, I run into some type of version issue with eConnect. The client will have 9.02 installed and I developed with 9.03, or 10.00 vs. 10.03. I often forget to ask in advance, and even if I do, nobody knows or remembers what version is installed. And when the wrong version is installed, the errors that I've run into seem to be completely random and inexplicable.

Based on these experiences, I figured it might be interesting to add a routine to my integrations to verify that the proper version of eConnect is installed before it attempts to run.

So today I decided to trace the "eConnect Release Information" utility to see how it was checking the eConnect version.

Turns out that it is just calling a single stored procedure:

exec DYNAMICS..taeConnectVersionInfoDYNAMICS

This returns a result set with 3 fields, with a row for each company:

Database Name
Version
CompanyName

I have verified that this procedure is available with eConnect 9 and 10, and from what I have read, may go back to version 7 / 7.5.

One good thing about the stored procedure is that it returns a "friendly" version number, like 9.0.3.0, 10.0.2.0, etc.

The stored procedure is encrypted, and I haven't bothered to buy a decryption app, so I can't tell exactly what it is doing, but I do know that it is iterating through each company database and checking something in the database.

The reason I know this, and the unintended consequence of this design, is that if there are any company databases that are Offline, or otherwise inaccessible, the version check fails completely and does not return any results. I have a client with over a dozen company databases, and several off line, so I'm unable to use the Release Information to check their eConnect version. Not very graceful.

And since this is only a stored procedure and is returning a version per company database, I assume that it is not checking the versions of the eConnect .NET DLL files.

If you want to check the DLL versions, you have a few options, but none are terribly appealing for programmatic checking.

1) The Knowledge Base recommends using Control Panel -> Add/Remove -> Select eConnect -> Click on Support Information link.

2) If you are adventurous, that same Add/Remove information can be found in the registry. Though it appears the GUID is the same across eConnect 10 releases and service packs (3C90E5C5C8D49BD42A1B7F8FF2B481C4), I suppose it could change at some point.

3) You can write code to locate the eConnect DLL and use FileVersionInfo to get the version number via .NET. The challenge is searching for the file on multiple drives and directories on a server.


And there are probably a few other creative ways I don't know about, like somehow checking the version in the .NET GAC.

The annoying part of checking the file versions is that it returns the typical useless GP version numbers like 10.00.0836.00 and 10.00.1072.00. Though documentation of such numbers is available for GP service packs, I haven't found such a list for eConnect service pack version numbers. If you know which version you want, you can just check to see if it matches, but I would rather be able to have a simple dialog that says "eConnect 10 SP2 is installed, but SP3 is required".

For now I think I'll try the stored procedure approach.