Upgrading Extensions to version 9

Upgrading Extensions to version 9

  
Does anyone have experience upgrading Extensions to version 9 in a .NET environment?

The 8 to 9 upgrade deocumentation describes a couple of scary changes, like the upgrade to .NET 4.5 and changes to how RecordList is handled, but it does not go into specific details.

The upgrade to .NET 4.5 is easy to understand... recompiling things should do the trick... though I need to know what happens to the references if they are .NET 2.0 or 3.X.

The much bigger concern are the changes to RecordList in Extensions... many of our Extensions use them.

Thanks!

J.Ja
Hi Justin,

The basic change in Record list s is the Data property that was type ArrayList is now a IList<T>. That means that extensions that are accessing it directly may need some code changes. It will give compilation errors if something is wrong and the necessary changes are very obvious when looking at the code.

Regards,
João Rosado
Joao -

Thanks!

Does this mean that we no longer need the "BeginIteration()" and "Next()" patterns when working with them, and can just directly enumerate/iterate the RecordLists?

J.Ja
Unfortunately those patterns are still necessary.
Although there are currently extensions that instead of iterating the recordlists they iterate the underlying array (the Data field) directly (for example the SortRecordist extension from the forge).
The Data array can be iterated normally without the BeginIteration pattern, but it is not the official/recommended way to do it because there are situations where you may end up with duplicated/overriden lines if you access the .Current field before or during the manipulation of the Data field.

Also I missed a question on your original post: regarding extensions .net upgrades, you are not forced to change them or any reference to 4.5. They can for now (at least until the next major version) still stay targeting .Net 3.5 since everything is backwards compatible.

Regards,
João Rosado
For the record (no pun intended), we never use BeginIteration and Next. RecordList types implement  IEnumerable and IEnumerator, and should be (and to our findings are) iteratable by using a foreach.
Nooooo... they *look* like they are working... until the record list comes from a DB query... and then you get bad results!

My suspicion is that the RecordList is not fully populated with data when it gets passed, because the queries use cursors... and if the RL is short enough then it works, but if the query returns more results that didn't populate, the interations do NOT get all of the data, they get only what the first page from the cursor returned... and BeginInteration sets the cursor to the beginning of the results and Next() moves the cursor forwards as needed.

Please trust me, I have done what you have done in the past, it worked often enough that I thought that the BeginIteration/Next() was outdated advice... and then I got Production issues because there was much more data there that triggerred unexpected behavior.

J.Ja
Justin James wrote:
Nooooo... they *look* like they are working... until the record list comes from a DB query... and then you get bad results!

My suspicion is that the RecordList is not fully populated with data when it gets passed, because the queries use cursors... and if the RL is short enough then it works, but if the query returns more results that didn't populate, the interations do NOT get all of the data, they get only what the first page from the cursor returned... and BeginInteration sets the cursor to the beginning of the results and Next() moves the cursor forwards as needed.
Well, that makes perfect sense to me. Very likely such a record list will report its length as the number of records that the foreach iterates over, so that it is consistent with IEnumerable etc. Next() will have some magic that'll fetch the next series of rows from the db etc.

That said, out use cases never involve database access, which will be the reason the foreach works like a charm. We just iterate over record lists passed as input parameters, or coming from web services, in which case all the data is already there.
I *think* the length gets reported at the total number of records pulled from the DB so far. I know in Service Center code, calling RecordList.List.Length causes the entire query to be run in full and all records to be retrieved, so the RecordList gets fully populated... which is why RecordList.Count is better if you don't need the actual results (it just runs the query using COUNT for the SELECT).

J.Ja
well from above conversation I understood that RecordList causing problem in .net extension. Am I right?

And unfortunately I am also getting compilation error when record list is passing as a parameter to action in extension. Can anyone suggest change over below lines of code...

 public void MssActionName(string a, string b, string c, out RLRecordList ssADUserInfoList, out RLRecordList ssErrorADUsersInfo)
        {
//the below line causes problem to me
 if (ssErrorADUsersInfo.Data.Contains(path.Substring(0, locOfComma)) == false)
                                    {
}
}

Thanks in advance..
Regards,
Venkatesh Gude.

Venkatesh,

Can you elaborate on what you mean by "sauses problem to me"? What problem?
Kilian Hekhuis wrote:
Venkatesh,

Can you elaborate on what you mean by "sauses problem to me"? What problem
I have created .net extension in 8.0 platform server which worked fine and released and now I upgrade my server to 9.0 after that I am getting compile error while trying to publish same extension in platform server 9.0 at the above mentioned if condition.

Thanks,
Venkatesh Gude.


It would help if you showed us the exact compile error.
Thanks Kilian for your assistance..Please find below error

 
Ok, it seems that the "Contains" function has changed between platforms. Are you yourself the one who has to fix this? I could give you a few pointers, but if you're not using Visual Studio, that won't help much :)
I am the one to fix. 
I am doing it through visual studio only please provide the steps to resolve

Thanks,
Venkat Gude.
Well, since I didn't have this specific problem, I can't provide a ready-made answer, but the key is in João's remark above: "the Data property that was type ArrayList is now a IList<T>". So this means you'll need the Contains function from IList<T>, instead of the one from ArrayList. Looking at your code, since Data is an IList<IRecord>, you need to pass an IRecord instead of a string.
Can you please suggest what are all the changes that required to do in my above piece of code because still I am getting compile error after solving this but where as .net code does not have any errors at the time compilation.



Regards,
Venkat Gude.
Hi Venkatesh,

I've helped you as much as I can, and as much as I can devote my time.
Hi,

From the code snippets I can see why it doesn't compile.... but I'm pretty sure that even comping before it would not work as intended.

If the code was really like that before the upgrade: .Data was an ArrayList of records, so doing a .Contains with a string parameter would ALWAYS return false.

So now with the new version it forces you to have the correct types and shows that your code was wrong.

Not sure what exact code you need there since in your post you do not show what are the attributes of the ADUserDisplay structure.
But of you start doing a lambda on the Contains the visual studio auto complete should help you with the rest:

if (ssErrorADUsersInfo.Data.Contains(rec => rec. == path.Substring(0, locOfComma)) == false) {

Try to autocomplete on the "rec." and see if you get to the attribute that you actually need to compare with that substring.

Regards,
João Rosado