A few words on OpenEdge UltraControls and deployment…

Very often we are faced with questions about deployment of OpenEdge GUI for .NET based applications and references to .NET Assemblies.

End users might run into error messages like this when starting forms using the OpenEdge Ultra Controls (Infragistics NetAdvantage for WinForms):

In particular this message is an indication for running R-Code that was compiled with OpenEdge 10.2A on an OpenEdge 10.2B runtime.  The 10.2A compiler has generated references to an Infragistics Assembly with the version number 8.1.20081.1000 (the Infragistics release shipped with OpenEdge 10.2A) and the 10.2B runtime does only find Infragistics Controls of a 9.2.20092 (2009.2) release. These assemblies are by default not a substitute for each other.

To my knowledge the only way to check which versions of Infragistics were used to compile a certain R-Code is by looking at the R-Code using a binary or text editor. Near the end of the file (search for Infragistics) you will find references to the used .NET Assemblies:

Here’s a list of the Infragistics Versions that Progress shipped with past OpenEdge releases:

This list is also available in the Progress K-Base: https://knowledgebase.progress.com/articles/Article/P187231

As you can see Progress is updating the Infragsitics/OpenEdge UltraControls Version also between Service Packs. And for OpenEdge 11 another update of the OpenEdge UltraControls is announced (shipping a 2011 release of Infragistics). So this is probably going to become a continuous topic…

How does Progress solve Assembly compatibility in Service Packs?

The .NET Framework uses a technique called “Assembly Probing” that allows to define .NET Assemblies that are a valid substitute for another. Progress uses Assembly Probing when running R-Code and loading the required Assemblies. Assembly probing is defined in a file called prowin32.exe.config. This file must reside in the same directory as the prowin32.exe file itself (%DLC%\bin directory). This is a .NET convention that Progress has to follow.

The prowin32.exe.config file shipped with any Progress Service pack will define the current versions of Infragistics as a valid substitute for any version shipped with a previous service pack of that OpenEdge version or that OpenEdge version itself. This allows executing OpenEdge 10.2B01 compiled R-Code on OpenEdge 10.2B04 without seeing the above issues when loading .NET assemblies.  Assembly probing is not defined between OpenEdge versions. Probably because the Infragistics major Versions are also expected to deliver new functionality and possibly breaking changes so that Progress Software cannot necessary guarantee full compatibility (without testing the application) when upgrading. I think this is reasonable.

So this leads to higher restrictions for R-Code compatibility when referencing Infragistics .NET Assemblies:

• There is no cross version R-Code compatibility. R-Code compiled against 10.2A will not find it’s assemblies on a 10.2B runtime and vice versa (unless you have manually installed those assemblies in the GAC)
• To achieve R-Code compatibility within a single OpenEdge release it is very important to compile on the lowest supported service pack level. When R-Code was compiled on Service Pack 1 of 10.2B it will contain references to the Infragistics Controls with the version 9.2.20092.2058. A 10.2B runtime (no service pack) will find an Infragistics Version 9.2.20092.2017 and has no information that 9.2.20092.2058 and 2017 are interexchangeable. However a 10.2B02 client will find an Infragistics Version 9.2.20092.2090 and the %DLC%\bin\prowin32.exe.config file contains the necessary information to allow substituting 9.2.20092.2058 with the 9.2.20092.2090.

The good thing that results from this is that end users can apply OpenEdge Service Packs without having to get new R-Code from the vendor for the whole application.

Another thing to consider is that Progress has used the 10.2B Service Packs to add a couple of new properties to the OpenEdge GUI for .NET classes used in ABL code like the Progress.Data.BindingSource or the Progress.Windows.Form. If your R-Code is using those additional Properties (like the MapNullToEmptyString property of the ProBindingSource introduced with 10.2B03) it’s very likely to fail on releases prior to that service pack.

Within an OpenEdge release it seems like a wise idea to define a minimum supported Service Pack level (might be the initial release with no service pack) and use this for building the software that will be deployed to your users. Developers that have the (understandable) urge to develop using the latest service pack available should always make sure that another machine for building and testing against the minimum supported Service Pack level is available in the organization. When you have to use properties of the mentioned ABL .NET objects, I do recommend to use .NET reflection to test if those properties are available and set the desired values dynamically.

Progress Installs the Infragistics Controls in the folder %DLC%\bin\infragistics\winforms. These are the freely distributable Assemblies. You can use the Windows Explorer to check the version on an assembly using the dll file’s properties:

The developers version of the Infragistics Controls is typically installed in a folder like this: c:\Program Files (x86)\Infragistics\NetAdvantage 2009.2\Windows Forms

Of course a developer may deploy his own version of the Infragistics Controls either to the application working directory, the directory located by the –assemblies parameter or the GAC.