Mixing 11.5 and 11.6 r-code

It's not so much about OE11.5 vs 11.6. It's about the different .NET Assembly versions used during compilation (Infragistics, Telerik, Progress.NetUI, ...). During compilation the so called strong name of all types (and that includes the assembly version) is compiled into the r-code and makes the r-code dependent on those .NET assembly versions. Use a text-editor that is capable at handling binary files to verify this. It's near the end of the r-code files.

Progress defines assembly compatibility rules between service packs in the prowin.exe.config file in DLC/bin. In theory you can extend those files to provide compatibility between assemblies shipped with major releases. But I'm not sure I'd go that route.

I can live well with knowing that r-code is version dependent due to the .NET dependencies.

Thanks Mike

I devised this approach after reading your blog post. I have taken great care to ensure we don't put .net assemblies in the GAC by only installing OE studio on our compile PC. We ensure this is always unpatched and is fixed at the release level which was 11.5 and now is 11.6.

We manually link the assemblies we need into a specific assemblies directory which contains the infragistics controls we need and also an additional c# assembly I wrote for colouring rows in the grid and drawfilters etc.

I can confirm that our compiled code against 11.6 that is failing does not directly include .net assemblies but links to a class through a variable defn. All of my classes reference 11.5 assemblies (14.2) when compiled in 11.6. Its a strange issue that almost looks like an adm2 issue.

We have a smartwindow with a paging button on it. The system is fixed at lower levels of the adm2 duie to some of the overrides which have been used etc. On selecting next page, the viewer which is compiled against 11.6 (whilst the rest of the system was compiled against 11.5) just doesn't show. No fields on screen. Nothing. No errors either. We do fix the propath to a specific version of the adm2 during compile and also at runtime.

Do you know of anything which can cause issues in the adm2 like this. Ive searched for proversion etc. Its not obvious.

-Darren

Which exact error message are you receiving?

I'm pretty sure this is a .net issue as as soon as I recompile our class directory, the issue disappears. Our viewers all run in embedded windows and use the parent window handle for instantiating other windows.

So the exact error message would be helpful - as I'm expecting it to tell you which "missing" assembly your r-code expects.

There is no error reported from the viewer. It goes into constructObject and the viewer never executes but reports no error. I decided to deploy a change to the smartwindow that the viewers parent to to see if that also errors or is blank. That reports a classes dont match. I'll deal with the fallout from constructObject as like I said it may be that the adm2 version we use has a bug.

There is no difference between the classes other than they have been left in 11.5 as they were previously compiled and the code which accesses them through a variable is being compiled in 11.6. Is it possible the changes that PSC have made in 11.6 under the progress namespace like progress.windows.form have caused my classes to be out of sync with previous 11.5 versions.

I thought we were protected from that. After all whilst the digest may be different I'm sure it should realise I'm not referencing anything new.

-Darren

Sorry I meant to say that our compile process compiles all of our classes if one of them changes. We don't have that many. The r-code folder is never in the propath for our compiles as want to ensure any references to classes in any code are up to date

I put 11.5 back and its all fine now. It just serves as a reminder that we do not have r-code compatibility in OO  between 11.5 and 11.6. I recompiled in 11.5 and the issue went away. Like I said this is against a fixed set of assemblies.

Thanks for trying to help.

-Darren

You can't ensure the same version of Progress.NetUI.dll across OE releases.

OK. I guess it just worked before with 11.3 etc. as we didn't notice it and this was consistent with the KB article which indicates r-code compatibility between versions of OE 11.

Thanks

Darren