Hi,
I have a class coded in Progress Developer studio 4.3 (OE11.6.0), on that machine also the Telerik DefCraft suite is installed. In a program on that machine I use somewhere the code:
define variable oChildren as "System.Collections.Generic.List< Telerik.WinControls.RadElement >" no-undo.
This compiles and runs fine!
Now I copied the source (cls-file) of that class and the needed dll's to another machine.
That machine has OE11.5.1 installed and no Telerik.
If I now open a Progress editor and do a compile <source-name>.cls save I get an error on that piece of code:
Invalid substitution type 'telerik.WinControls.RadElement' supplied ..... (15214)
I get the same error when I try to use that class from my application
If i now copy the the compiled .r to this machine and again try to run that from my application it works just fine (so now the compiled .r is runned and that is OK)
The strange thing now is if I now do a compile <source-name>.cls save (that failed before) then I do not get that compile error? Why is that?
It looks like when a program is runned that uses that "System.Collections.Generic.List< Telerik.WinControls.RadElement >" then Progress remembers that this is a valid control and compiles all files that use that compile fine.
When I close the Progress session and start a new one the problem is back?
I find that very confusing.
is that expected behaviour and can someone explain that to me?
Regards
Didier
I suspect that the facts are not quite right here. All makes sense until you said that the r-code from the first machine runs fine on the second with no Telerik controls there. That is not possible. It is true that once you have r-code you no longer need the assemblies.xml file. But the Telerik assembly itself must be on the machine in a place where .Net will find it, e.g., in the GAC.
So what would make sense is that on the 2nd machine you don't have an assemblies.xml file, but you do have the Telerik assembly. You run the r-code fine. And then in the same session, if you compile, it will work for exactly the reason you said... The AVM already knows about this class and so can now compile without the assemblies.xml file. If you start a new session, you're back to square one and the compile will fail.
Hi Laura,
Maybe I was not clear about this or maybe I misunderstand you but I wrote
"Now I copied the source (cls-file) of that class and the needed dll's to another machine."
So I copied the cls-file and the needed dll-files (Telerik Controls) to that second machine where my application runs.
It's still not clear to me that, if the needed controls (dll's) are in the root-directory of my application together with the assemblies.xml where those controls are also mentioned, the copile failes.
But after I run the r-code file (that also needs those dll-files, but not the assemblies) evrything is fine.
I can understand that the Progress VM remembers that these are valid controls after the r-code is runned but why doesn't it compile?
I know it's a strange setup (this is only temporary) because the Telerik suite is not installed on the same machine as my application is. That will change quickly and I believe that this problem will then disappear but still it's not easy to understand.
The working of that GAC is not so clear.
When are the control registrered to the GAC?
I think because the Telerik suite is not installed on that machine they are not registered and that's my problem.
But what happens then when a r-code is runned?
Are the referenced controls then added to some session-specific copy of that GAC (or I'm I wrong?)
Regards
Didier
Sorry, I did miss that you copied the Telerik assemblies. Are you using the -assemblies startup parameter? I don't think you need it if all relevant files are in the "start-in" directory. But if you haven't already, please try it for a complete picture of the issue.
The controls don't have to be in the GAC. I don't know what our install does. They just need to be in the search path .Net uses, e.g., where the .exe is run from, in a redirection directory, based on the config file, etc. .Net won't find them in the current working directory, but we try to load them from there explicitly since that is the default -assemblies directory (I think!) or we look in the directory specified by -assemblies.
We need the -assemblies at compile time since that is how we get the full names of the assemblies to load. Otherwise, all we have is the name of controls in the ABL code. They don't have the version, etc, that you need for .Net to find the right assembly to load. Once we compile, the full control name with version is stored in the r-code.