CSLA 3.0.6 to latest version 4.5.501

CSLA 3.0.6 to latest version 4.5.501

Old forum URL: forums.lhotka.net/forums/t/12577.aspx


Migs posted on Monday, April 07, 2014

I am not sure if I posted this question before or somebody posted it, but somehow I cannot find the discussion.

We had lots of in-house applications that uses CSLA 3.0.6, .NET Framework 3.5/4, VS2010.  Would it possible to upgrade all of those to the latest CSLA version (4.5.501), .NET Framework 4.5 and VS 2012?

One our concern are there lots of validation and business rules in any of the project.

Thanks.

skagen00 replied on Monday, April 07, 2014

Do you have a lot of unit tests?

We upgraded through the new business rules approach and that was certainly the most involved component - though that area of our system had a lot of test coverage that gave us some comfort with the end result.  I think it took about 2-3 weeks to get our application upgraded through the new business rules mechanism.

It's obviously possible to pretty much any CSLA app (ours started at 2.x) - it's just a matter of the amount of work involved. 

What is the motivation for upgrading them? To leverage some of the newer technologies that become supportable via newer versions of CSLA, or to just "stay current"? 

Migs replied on Wednesday, April 09, 2014

Thanks for the response skagen00, it's been months that we're thinking of upgrading and yes you're right with the amount of of work involved is not a joke.  I would say for the reason of staying current and to leverage the newer technologies as you said, like migrating to .NET Framework 4.5 as our back-end resources upgraded too.

Well, we don't have unit tests for one of our main app yet.  And that's what we are trying to achieve during conversion process.

JonnyBee replied on Monday, April 07, 2014

Hi,

Possible, yes - but it will require a substantial amount of work. There is a number of breaking changes and you really need to go through all the release starting from the next version of your current version and up. 

One of the biggest issues is to alter your code to use PropertyInfo descriptors. CSLA 4.x require all properties that have rules attached to them to be defined with PropertyInfo's. But as mentioned before - there is a number of breaking changes. Once you get your code to that point you can use the Csla.Validation NuGet package to retain "most" of the Validation rules with the old syntax and focus on getting the application upgraded bit-by-bit.

You should however be able to move the application to VS 2012 and .NET 4.5 while keeping the reference to CSLA 3.0.6 with hardly any change in your code - if that would solve some of your issues. 

There has been several threads on migration to never versions - just search for "upgrade" in the forum. 

Migs replied on Wednesday, April 09, 2014

Thanks JonnyBee, this is the kind of information that I am looking at.

Migs replied on Tuesday, July 15, 2014

So it was a success when we moved several of our projects from 3.0.6 to 4.5.501.  One of the minor issue that we are having right now is Exception messages are being returned to the end client, we haven't modified any code yet except with the conversion/deprecated one.  I'm not sure if any of you encountered this or it is a known thing.  Please let me know if you need further information.  Thank you in advance.

skagen00 replied on Wednesday, July 16, 2014

Do you mean _exception messages are *not* being returned to the end client_?

Because I did encounter that, and it was a CSLA bug that should be fixed in 4.5.501 - (http://forums.lhotka.net/forums/p/12076/55936.aspx)

I don't have an answer but just wanted to mention that previous thread of where an exception was not getting back to the client before.

Migs replied on Wednesday, July 16, 2014

Somehow, my question is related to that fix.  I'll check on that.

I found out the issue.  We did modified the code, previously it will resume next if it encounters an exception.

OLD Code with CSLA 3.0.6:
try
{
 .....
} catch { }

NEW Code with CSLA 4.5.501
try
{
 .....
} catch (Exception ex) {
 LogThisError(blahblahex.message);
}

The old code will nothing, but the new code will return the CSLA formatted Exception.Message().  I'm not sure if this is the expected behavior or is there a way to supress this in general?  My quick fix just to put back the "catch {}".

Thanks.

Migs replied on Monday, January 19, 2015

Hey guys, I was able upgrade some of our projects to newer CSLA version (from 3.0.6).  However, in one of the project I encountered the issue of "List item must be marked as a child object".  Here's the exception:

Type : Csla.DataPortalException, Csla, Version=4.5.501.0, Culture=neutral, PublicKeyToken=93be5fdc093e4c30
Message : DataPortal.Fetch failed (List item must be marked as a child object)
Source : Csla
Help link :
ErrorInfo :
BusinessObject :
BusinessException : System.InvalidOperationException: List item must be marked as a child object
  at Csla.BusinessListBase`2.InsertItem(Int32 index, C item)
  at Csla.Core.ExtendedBindingList`1.AddRange(IEnumerable`1 range)
  at myProj.BLL.myRequestList.DataPortal_Fetch(Criteria crit)
  at lambda_method(Closure , Object , Object[] )
  at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Boolean hasParameters, Object[] parameters)
Data : System.Collections.ListDictionaryInternal
TargetSite : System.Object Fetch(System.Type, System.Object)
HResult : -2146233088
Stack Trace :    at Csla.BusinessListBase`2.InsertItem(Int32 index, C item)
  at Csla.Core.ExtendedBindingList`1.AddRange(IEnumerable`1 range)
  at myProj.BLL.myRequestList.DataPortal_Fetch(Criteria crit)
  at lambda_method(Closure , Object , Object[] )
  at Csla.Reflection.MethodCaller.CallMethod(Object obj, DynamicMethodHandle methodHandle, Boolean hasParameters, Object[] parameters)
  at Microsoft.Runtime.CompilerServices.TaskAwaiter.ThrowForNonSuccess(Task task)
  at Microsoft.Runtime.CompilerServices.TaskAwaiter.HandleNonSuccess(Task task)
  at Csla.Server.SimpleDataPortal.<Fetch>d__7.MoveNext()
  at Csla.DataPortal`1.Fetch(Type objectType, Object criteria)
  at Csla.DataPortal`1.Fetch(Object criteria)
  at Csla.DataPortal.Fetch[T](Object criteria)
  at myProj.BLL.myRequestList.GetSendingRequestList(Int32 aMaxRows)



And here's how my BLL looks like:

namespace myProj.BLL
{
    [Serializable()]
    public class myRequestList : BusinessListBase<myRequestList, myRequestInfo>
    {
        public static myRequestList GetmyRequestList(int aMaxRows)
        {
            return DataPortal.Fetch<myRequestList>(new Criteria(aMaxRows));

        }


        private void DataPortal_Fetch(Criteria crit)
        {
            UtilitiesDataContext db = new myDBDataContext(ConfigurationManager.ConnectionStrings[Database.myDB].ToString());

            var data = from Items in db.p_GetMyOrders(crit.MaxRows)
                       select new myRequestInfo(Items.myUID, Items.OrderID, Items.LocationID, Items.QName, Items.ReplaceRequired, Items.abbreviation, Items.ItemCount);

            if (data != null)
            {
                this.AddRange(data);
            }
          
            db.Dispose();
        }


        private class Criteria
        {
            private int mMaxRows;

            public int MaxRows { get { return mMaxRows; } }

            public Criteria(int aMaxRows)
            {
                mMaxRows = aMaxRows;
            }

        }

    }
}

 

Any idea?

skagen00 replied on Tuesday, January 20, 2015

It has been a while but I believe we encountered this a couple places during our upgrade as well.  Previously it wouldn't choke if you forgot to MarkAsChild() but upon upgrading we noticed that there were a few places where we were not successfully making sure the item was marked as a child before adding it to a CSLA list.

MarkAsChild() on the item before adding and I believe you will be OK.

Migs replied on Tuesday, January 20, 2015

It works!  Thanks @skagen00, all I need is add MarkAsClean() in myRequestInfo().  This is one of the major issue that I encountered in upgrading.  The other one is the "Private backing field".

Thanks a lot.

ajj3085 replied on Wednesday, January 21, 2015

Migs

It works!  Thanks @skagen00, all I need is add MarkAsClean() in myRequestInfo().  This is one of the major issue that I encountered in upgrading.  The other one is the "Private backing field".

Thanks a lot.

You may want to consider using static factory methods to crud your child objects, as the data portal now offers .FetchChild and others which will do the MarkAsChild for you.

Migs replied on Thursday, January 22, 2015

Thanks for the tip Andy that will be my next move once I fully tested the upgraded.  Some of my projects that got upgraded was already using .FetchChild.

Copyright (c) Marimer LLC