Compiling .Net Code with different versions of infragistics

Posted by Darren Parr on 10-May-2013 13:15


We've shipped a release to about 4 or 5 customers, lets call it release 1. Its runs OK and may need fixes. In the meantime we are developing some extra features which may make their way to our next release. Ths issue I have is that I have just patched my 11.2 to 11.2.1 to get the eclipse improvements etc. I must admit that on the face of it, it looks less buggy and quicker.

I have not changed my assemblies.xml but just recompiled the project. On inspectng the r-code the version stamped onto my r-code has increased which surprised me as i thought it might be based on the entries in the assemblies.xml. So the first issue I have is how to control this. Mike Fechners article on this is great, but I still want a little more information. I have an environment on a PC which we use to compile our code for release to site. We have insisted on this not beng patched and so we can ensure we don't get in a mess on site. What happens however if we make our next release use the controls from 11.2.1. Do I eed another completely different PC to be able to compile our code? I would like to be able to drop the controls I need into the assemblies folder and have it use them. Does that work? It looks like OpenEdge has installed them in the GAC. I would love to know how OpenEdge works out the version to put in the r-code.

The issue here is that we can't update the controls on our compile PC to those from 11.2.1 as we would end up with r-code whch does not run in vanilla 11.2. I am very intersted in finding how everyone does this. I can't kp creating virtual environments for the different releases of openedge as its seems a massive waste of resources. I would like to just have different shorcuts for the compile with different assemblies.

Many Thanks


All Replies

Posted by Matt Baker on 10-May-2013 16:28

The "trick" here is to not compile against the controls in the GAC, but to compile against the assemblies on disk.

Normally the search path for picking up .net controls searches for the latest in the GAC, then searches the local copies if not present in the GAC.

Unfortunatley, this pretty much means "don't install infragistics controls on the machine where you do your compiles".  Instead, check-in the assemblies that you intend to build against (since those are part of your aplication) into your source code control and the appropriately configured assemblies file, and setup your build environment to compile against those using the -assembles switch this way the "build" version will get burned into the r-code instead of picking the "latest" which (won't be) in the GAC.

This of course assumes the machine where you do your builds is NOT the same as your personal development machine.

Posted by Darren Parr on 12-May-2013 14:25


Thanks for that. I guess I never thought of not installing the ultra controls on the compile server.

Do you adopt a similar approach for webclient builds. At the moment we are packaging the .net controls with the webclient system task.

Do you favour just dropping them in the local assemblies folder and always resolving them locally. It sounds quite possible that someone could install some of the controls in the GAC using other products. I know the GAC supports different versions of each control as I wrote one of my own c# assemblies and I ended up putting 2 different versions in the GAC by accident.

Also has anyone noticed that an assemblies folder on a samba share works (it picks up the xml file) until you need to load assemblies from that location? No errors but it just doesn't work...



Posted by Darren Parr on 14-May-2013 12:25


Just setup a windows 7 PC with OE Studio. I loaded 11.2 and loaded the patch 11.2.1. I then dropped the infragistics controls into local directories so that 11.2 controls and 11.2.1 controls were seperate.

On compiling I noticed that I was still getting the 11.2.1 controls in my r-code with local 11.2 controls in my assemblies folder. The reason for this was the prowin32.exe.config file which was resolving the controls locally with those in bin/infragistics/winforms. So it seems you can't use 11.2.1 binaries to compile using 11.2 infragistics libraries unless you want to modify the config.

Whilst I can see why progress would want to map one control version to a later one for us in a deployment scenario (ie states that something thats asks for 2124 should load 2135), it doesnt make sense to do this for compilation purposes where the assemblies.xml is explicit on the version. Surely this is a bug... I think progress should be insisting on exact version matches at compile time or at least give us a way of insisting on this. At run-time I agree with mapping things through. After all this ensures that someone loading a service pack will still have a working system.

For now I've gone vanilla 11.2 so that I can use 2135 and 2124.



Posted by Garry Hall on 14-May-2013 12:55

The issue is prowin32.exe.config, as you identified. However, the only way to address your "bug" of requiring the exact AssemblyName match at compile time is to remove the redirections in the prowin32.exe.config file.

When you request version 2124 of an assembly, for compilation or runtime, the AVM asks the CLR to load it. We chose not to re-invent the CLR assembly loading, and just use the functionality that .NET provides, warts and all. When the CLR tries to load version 2124, it sees there is a redirection to 2135 in the config file, so will always load 2135 instead. Since (I am assuming) both 11.2 controls and 11.2.1 controls are in your DLC\bin\Infragistics\winforms, the CLR will find them here first, before probing your assemblies directory. See for an explanation of assembly resolution in the AVM.

Posted by Admin on 14-May-2013 13:45

Since (I am assuming) both 11.2 controls and 11.2.1 controls are in your DLC\bin\Infragistics\winforms

This is difficult to believe as the Infragistics hotfixes do overwrite previous assemblies of the same version. The hotfixed and the original assembly simply share the same file name. So they cannot reside in the same folder.

New Infragistics releases introduce new file names.

But that was not the case from OpenEdge 11.1 to 11.2 to 11.2.1.

Posted by Garry Hall on 14-May-2013 14:02

Ah, yes. I have to admit that I did not try this with 11.2 and install 11.2.1 to see what happened to the files. I have not kept up with the versions either.

The redirection is still the cause, though. The CLR is redirected to look for 2135 when it is asked to load 2124. If 2135 is in DLC\bin\infragistics\winforms, that is what the CLR will find first.

And you have the GAC. IIRC, UltraControls for .NET will be installed into the GAC... or maybe that has changed, and I have not kept up with that. But if both versions are in the GAC, the CLR is still redirected to look for 2135 when asked for 2124, and will find 2135 in the GAC. The only way to make the AVM and CLR respect exactly what is in the assemblies.xml file is to remove the redirection from the config file. Technically, anyway... I am not commenting on the supportability of editing the config file.

Posted by Darren Parr on 15-May-2013 04:25


Yes thats correct. The 11.2.1 controls overwrite the 11.2 ones.

To ensure I can compile against each version I have dropped the controls into a C:\Assemblies\11.2 folder and also a C\Assemblies\11.2.1 folder.

As I didn't want to mess with the config file Ive just used vanilla 11.2 and I'm mappng to the 11.2.1 controls locally when needed.



This thread is closed