Service Pack 2 and Ultra Controls

Posted by Admin on 06-Sep-2009 08:28

Hello everyone,

Progress just released Service Pack 2 which also contains an update to the Infragistics Controls (UltraControls). The previous version shiped with 10.2A FCS will be uninstalled during the service pack process and is no longer available. As a result you have to update your assemblies.xml files before you'll be able to compile your UI classes (when using the UltraControls, of course).

The change is from Version=8.1.20081.1000 to Version=8.1.20081.2150

The change can be done using search and replace in the assemblies.xml file (my personal choice this time) or using one of the graphical utilities.

Though I'd let you know...


All Replies

Posted by ChUIMonster on 07-Sep-2009 08:46

Is it just me and my ignorance regarding what assemblies.xml is all about or would it be reasonable to think that the service pack ought to handle that in the future and that this is just a one-time oversight?

Posted by rbf on 07-Sep-2009 10:31

You are right that assemblies.xml IMHO should be updated automagically.

Posted by Admin on 07-Sep-2009 13:12

Call me stupid (for this and other reasons), but I'm happy with maintaining the Assemblies.xml file manually.

Maybe an option during the service pack setup - like the one asking if you'd like to upgrade the Dynamics repository when installing a new Progress release - would be helpful.

Posted by Admin on 07-Sep-2009 13:19

When an how? I have an assemblies.xml file in every project. A rough guess are ~ 30 occurances all accros my hard drive. Which one do you want to have updated automatically? And when? During the SP process or when starting the workspace?

And how about end users? They usually will be using the assemblies.xml file from %DLC%\bin\infragistics\winforms. The old one was replaced by the SP setup. If the assemblies.xml file in the application root directory (or a folder pointed to by the -assemblies parameter) still refers the old dll files, the user is in trouble. I'd rather deploy the dll files with the assemblies.xml in a folder referenced by the -assemblies parameter (we usually use -assemblies Assemblies). That ensures that the users are using the version of the Infragistics controls "released" by the application vendor. So to say, it's not uncommon, that I have multiple copies of the Infragistics dll files here and there.

IMHO deploying the assemblies dll files and the assemblies.xml should be done by the application vendor, not a Progress service pack setup.

Posted by rbf on 07-Sep-2009 15:09

I would expect a question the first time a project is opened in the new version.

Posted by jmls on 08-Sep-2009 03:42

Can you have more than one directory in the -assemblies startup parameter ? I would like to keep the .dll's for each vendor in a separate directory so I can track different versions of each control.


Posted by Peter Judge on 08-Sep-2009 08:32

Can you have more than one directory in the -assemblies startup parameter ?

I don't believe so.

I would like to keep the .dll's for each vendor in a separate directory so I

can track different versions of each control.

Do you always copy the DLLs to -assemblies (even when they're in the GAC)? Do you deal with GAC-registered assemblies differently? Enquiring minds etc

-- peter

Posted by Shelley Chase on 08-Sep-2009 10:07

I will try to answer all questions asked but I may miss one or two so please keep me honest.

OpenEdge Service Packs:

Our goal (as always) it to keep a service pack install as simple as possible. When a new version of UltraControls is put into a service pack, it is always a replacement for the "current" release. In the case Mike points out the UltraControls version went from Version=8.1.20081.1000 to Version=8.1.20081.2150. Since this is always a replacement, the assemblies.xml file does not need to be changed. Instead there is a file installed in dlc\bin called Prowin32.exe.config which automatically performs this redirection every time an assembly of the old version is referenced by an OpenEdge application.

If you are managing your assemblies.xml files yourself, you can hand-edit the version change or post 10.2B use the Assemblies migration tool to update the assembly references for a service pack update. Neither of these are necessary.

Note: There is a bug on VMs where the replacement and the original version of the UltraControls are both kept on the VM after the update install. The redirection Prowin32.exe.config still works you just need to know which version you are using. Our development team is working with Infragistics on fixing this bug.

OpenEdge Releases:

When a new version of OpenEdge and UltraControls is released that is a side-by-side install not a replacement (a new major/minor version), i.e. 9.1.x), existing assemblies.xml files and toolbox.xml files need to be updated. This is best done using the Assemblies migration tool. Within Architect of a new OpenEdge release, the first time an "old project" is opened, you will be prompted to update any local assemblies.xml and toolbox.xml files. If you say yes, the UltraControls references are all updated. If you say no, the references are left alone and it is your responsibility to update them at a later time. It is unsupported to run a newer version of Architect on an older version of the UltraControls.

Assemblies Directory:

There is only a single assemblies directory per session, by default it is the working directory for Prowin32. It can be overridden using the -assemblies startup parameter. The assemblies directory and its sub-directories are where all third party assemblies not installed into the GAC must be found. During development many controls are installed into the GAC but their deployment model uses local files. This means that you assemblies.xml file must take into consideration development versus deployment.

.NET will only search a single directory to find assemblies that are not loaded from the GAC or dlc\bin. .NET will not search ProPath or any hard-coded assembly paths. The assemblies.xml file lists the assemblies references by name not location. You can have as many files listed in the assemblies.xml file as you want as long as they are in the GAC or can be found relative to your assemblies directory.


I believe this warrants a white paper...

Posted by Admin on 08-Sep-2009 10:52

Hi Shelley,

The Whitepaper sounds great!!!

The automatic redirection did not work for me. I got compile errors

until I updated the assemblies.xml file.

No VM involved.


Posted by jmls on 08-Sep-2009 11:46

Hi Shelly - a quick question:

The assemblies directory and its sub-directories are where all third party assemblies not installed into the GAC must be found

What do you mean by "and it's sub-directories" ? Can I put .dll files in subdirectories of the assemblies directory ?


Posted by Shelley Chase on 08-Sep-2009 12:15


When you have a chance please log a bug on the failure of the .config file. It should have worked.



Posted by Shelley Chase on 08-Sep-2009 12:18

Hi Julian,

Yes, the assemblies (.dlls) can be in a subdirectory of the assemblies directory.

I realized that I did not provide a solution to your question on different versions of the same vendor dlls in different assemblies directories. I would put those in different subdirectories on my development machine and have the assemblies.xml for an application specify which version to use.


Posted by Admin on 08-Sep-2009 12:18

Will do - the prowin32.exe.config file is present - and it contains (probably) the right directives:






Posted by pkavuri on 09-Sep-2009 06:03

In 10.2a02, user has to explicitly update the assemblies.xml and toolbox.xml manually because control versions are upgraded.

OpenEdge ultra controls get updated automatically from 10.2B during workspace startup.

This thread is closed