Upgrade guidance CSLA 3.8.4 jump to .Net 4.7+

[philsayersCDS]

Hello,

We have a large, widely deployed, back office ERP solution that uses several hundred business objects based around CSLA 3.8.4.
Our BO's are used all over out platform which covers Winforms desktop, ASP.Net WebApi2, and Windows Services.

The CSLA.dll library is compiled against .Net 2.0
The rest of our platform (Our BO library, UI, control libraries) is built against .net 4.7.2.
We make heavy use of the devexpress and janus winforms control suites, and the csla binding refresh component.

I'd like to move away from needing the .net 2.0 based CSLA library and switch to the version 4 release line where it's built against .Net 4.0.

Does the CSLA 4 book series include guidance that can assist here?
We're not looking to jump into the Async stuff immediately, we're just looking to re-baseline everything against .Net 4.7.2 (or 4.8) for now.

I know there's some changes around business rules/validation rules, and base class tweaks for commandbase and criteriabase. Are there any other major pain points I need to look out for?

.Net 5 is too new for our platform at the moment, we need the winforms desktop story to mature before we can jump over to 5.

The fact that we've been able to stick with the CSLA 3.xx series and use it to underpin so much of our platform without any major issues moving through .Net 2.0, 3.0, 3.5, 4.0, and 4.5 for 10+ years is such a great stability story, I'm both amazed and grateful I haven't needed to address upgrading for so long. Thanks for a great framework.

[tabaguley]

Having gone through a very similar scenario (upgrade from CLSA 1.7 to 3.8+ years ago), I though I'd share some thoughts:

The BIG Mistake: Not keeping up with regular updates to both the .NET and CSLA. Looking back I realize that this was a critical error on our part. It is now policy that all GitHub message traffic related to CSLA is monitored, and as significant updates to CSLA are rolled out, they are very quick integrated into our production code-base (usually, 2-4 times per year). That is the only way to stay on top of things.

Unfortunately, there is no standardized, automated way to update a lot of the old CSLA code to newer patterns -- at least there wasn't when I asked Rocky about this years ago. So my suggestion is to do what I've done: Write your own parsing & scripting utility to do most of the heavy lifting for you. If well-built (and tuned to different variants of CSLA as it matures), you can easily re-script your business objects for whatever version you need to target.

I would recommend reading Rocky's blog posts regarding moving to .NET Standard, .NET Core, etc. And stay on top of Microsoft's roadmap for these. As Rocky notes, try to get all your business logic code to the most up-to-date framework(s). Obviously, UI code (such as Windows Forms) will need to target other frameworks for the functionality they provide (such as .NET Framework 4.8).

Given you note that you're mostly on CSLA 3.xx, you may likely be able to simply update your projects to newer versions of both .NET Framework and CSLA (make a backup, target a different framework, recompile, see what breaks).

The most significant changes to be aware of: Property (and PropertyInfo) Declarations, Business Rules, Criteria(Base), DataPortal_xxx method signatures. Again, incorporating these changes into a scripting utility will greatly ease the transition/conversion process.

Finally, consider this approach to your utilization of CSLA: Download and maintain your own version (or versions) of it. When you decide to update it: download the latest version of CSLA, then use a tool like Code Compare to see what has changed between the versions, and apply only those changes you approved of. This is what I do a few times each year.

I have made a LOT of customizations to and modifications of CSLA over the years. Some of the things we rely on have been deprecated or removed in newer versions of CSLA. So when we update our version, we must ensure items we need remain. Code Compare makes this very easy to do.

I hope this has provided you some useful ideas on how to proceed with your upgrade path.

[philsayersCDS]

Thanks.
We're just about close as we can get to the "most up to date" version of .Net Framework by using 4.7.2. We fully expect 4.8 to be an easy jump. Keeping up is a challenge, this is a massive ERP system and any move to vNext of .Net is an steady, incremental, multi-year task. When .Net Standard/Core comes and goes, and now we're into .Net 5 with .Net 6 on the horizon, none of which have a complete Winforms story like .Net Framework 4.7.2+. We're just in a holding pattern waiting on things to mature/stabilize.

We've always just added CSLA as a referenced library. Based on this I think I'm going to grab the source code for it and see if i can get it to compile against .net 4.7.2+. As long as it builds it will at least get me past this block.

[jonnybee]

I have done a few migrations from CSLA v3.x to v.4x and wrote a couple of blog posts about the experience.
https://jonnybekkum.wordpress.com/2013/10/07/csla-validationthe-new-nuget-package-in-csla-net-4-5-40/
https://jonnybekkum.wordpress.com/2011/08/29/csla-4-2-rules-update/

Although it's a few years ago there should be some applicable techniques in there.