Rather urgent request for help: Wrong assembly

We have our development system on 10.2A SP2. We have our live system on

10.2A00. You can see where I am going with this, can't you ...

Today we deployed a little "upgrade" which added some new functionality.

Unfortunately it seems to have broken some other part of the system and I

cannot for the life of me figure it out.

The problem is that we are trying to instantiate a form, but get the error

System.IO.FileLoadException: could not load file or assembly

"infragistics2.win.ultrawingrid.v8.1, version=8.1.20081.2150" or one of it's

dependencies. The located assembly manifest does not match the assembly

reference"

Are you seeing the error in the live or dev environment? And do you have a separate install (ie non-UltraControls) of the controls in either place?

-- peter

I assume, the assembly version is referenced in the R-Code, it's part of the strong name.

But you wouldn't wanna run code compiled with SP2 on 10.2A00 for another reason: SP1 added properties (MaxDataGuess) to the ProBindingSource. That's referenced in any GUI for that's using a BindingSource and will fail on 10.2A00 as well...

It is on our live system. But see the next post, I've fixed it.

Julian

Yup, the r-code does seem to store the reference. I found a base class that used the wingrid control. I removed the .r and things started working again.

Why does the .r hold the reference to the *version* of the class ? I would have thought that the ABL would request the class and the OS would return the correct dll

Julian

Even in .NET the exe/dll keeps track of the version of assemblies it's using. This will supposedly prevent maliciously injecting someone else assemblies.

Oh, ok. Thanks.

Eeek. Did I miss the SP2 readme part where it said that "you must have the same sp level on all deployments" ? If I recompile under sp2 I cannot deploy to a SP1 or SP0 platform - that's quite "interesting"

Why does the .r hold the reference to the *version* of the class ? I would have thought that the ABL would request the class and the OS would return the correct dll

type-safety.

If the runtime would just pick any version of the Infragistics DLLs that's available, who knows if it behaves as desired?

jmls schrieb:
Eeek. Did I miss the SP2 readme part where it said that "you must have the same sp level on all deployments" ? If I recompile under sp2 I cannot deploy to a SP1 or SP0 platform - that's quite "interesting" 

For the Infragistics Controls it's really easy! The DLLs belong to the application, not the system. So simply deploy the Infragistics DLLs from you devleopment environment to all clients using COPY to a directory containing assemblies. Because the dll names only contain the major version number (not the 2150 part) that would overwrite the outdates versions of the DLLs. The consequence will be that you have to run a full update of our R-Code, not only the single modified code.

The issue with the differences in the Progress.Data.BindingSource (see my previous post) is more critical as it's part of the runtime and you can't change it that easy.

I have two suggestions (not sure if you like any of them):

1.) Install SP2 on all clients (my preferred solution)

2.) Stay with 10.2A00 on dev until you can update prod to SP2. I'd never deploy R-Code compiled with a newer version of Progress to an older runtime. I consider a service pack a version for this rule as well.

Even recompiling the 10.2A02 Visual Designer Source code won't work on 10.2A00 as soon as the Visual Designer did set this DataGuess property in the generated source code.

jquerijero schrieb:
Even in .NET the exe/dll keeps track of the version of assemblies it's using. This will supposedly prevent maliciously injecting someone else assemblies.

Exactly. And for that reason the R-Code contains a reference like this:

Infragistics2.Win.UltraWinGrid.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb

The PublicKeyToken will prevent code injection, the version number, name and culture could be tweaked.

mikefe wrote:
jquerijero schrieb:
Even in .NET the exe/dll keeps track of the version of assemblies it's using. This will supposedly prevent maliciously injecting someone else assemblies.
Exactly. And for that reason the R-Code contains a reference like this:
Infragistics2.Win.UltraWinGrid.v8.1, Version=8.1.20081.1000, Culture=neutral, PublicKeyToken=7dd5c3163f2cd0cb
The PublicKeyToken will prevent code injection, the version number, name and culture could be tweaked.

And to square the circle, that's part of what the assemblies.xml file does: tell the compiler which version of the DLL to write into the r-code (since it doesn't and shouldn't appear in the source code).

-- peter

So, just to clarify the thoughts in my head (difficult, if not impossible) , when I change the .dll version (minor or major) I will need to recompile all programs that reference that dll ? (is this mentioned anywhere in the documentation ?)

Is there anyway of determining which .cls file references a particular version of the .dll ?

Is there anyway of determining which .cls file references a particular version of the .dll ?

Scan the R-Code for the word Infragistics etc.?

Gee, thanks Mike

There I was hoping you would say "sure, just right-click on the assembly reference and choose the 'where used' option" ...

jmls schrieb:
Gee, thanks Mike 
There I was hoping you would say "sure, just right-click on the assembly reference and choose the 'where used' option" ...

Come on, that would have been too easy... But an enhancement to the RCODE-INFO handle would actually be nice.

So, just to clarify the thoughts in my head (difficult, if not impossible) ,

when I change the .dll version (minor or major) I will need to recompile all

programs that reference that dll ?

Probably, but in certain circumstances it depends. There's a file in $DLC/bin - prowin32.exe.config - which does allow for some level of redirection for forwards compatibility. In 10.2A02 it will allow 10.2A00 R-code to run against the controls provided with 10.2A02.

>(is this mentioned anywhere in the documentation ?)

I'm not sure. And besides, who reads the doc anyway? (I kid, I kid

Is there anyway of determining which .cls file references a particular

version of the .dll ?

Not from the source. You could inspect the r-code in a text editor. (Heavy-handed hint hereafter) Wonder if it'd be worthwhile having an rcode-info enhancement that was able to return the assemblies ref'ed in a piece of r-code?

-- peter

I don't suppose this information would be available from the XREF?

Our backward-compatibility support policy is that as long as you do not use any new feature your code is backward-compatible. This still holds "true" in 10.2A but (of course there was a but...) with GUI for .NET there are updates that happen automatically for you for your convenience . So even though you did not explicitly update your code, the assembly references were updated to use the new Infragistics dlls when you re-compiled in 10.2A02 . The update happened because in prowin32.exe.config we have a redirection for all the old Infragistics dlls (...1000) to the new ones (...2150).

You can fix this at compile time in 10.2A02 by commenting out those redirection entries in prowin32.exe.config.

Alternatively you can let the compile do the update and then add your own redirection in your 10.2A00 deployment. You *should* be able to use the create an assemblies.config file in your -assemblies directory which undoes the redirection (go from 1000 to 2150). You can read more about this in the document "10.2A OpenEdge Deployment: Managing ABL Applications".

I say should because I am not sure that we have tried to redirect anything other than local assemblies. You will note that the documentation says this can only be used for local assemblies. However I spoke with the developer and they think it should work. If it does not you can edit the prowin32.exe.config to do the redirection (go from 1000 to 2150).

We will take a look at this use case with assemblies.config internally. If it does not work, feel free to log it as a bug.

Now Mike talked about some automatically generated updated in the Visual Designer. This ends up with code that uses the new MaxDataGuess property and is considered using a new feature since 10.2A00.

-Shelley