Supported Versions of CSLA (For security and bug fixes).

[haymansfield]

Hi,

I'm looking at upgrade options for a customer application based on .NET Framework 4.8.2 and ASP.NET Webforms. It is currently running a very old version of CSLA (pre v5).

The solution is not likely to need use/need new CSLA features but does need to have access to any future critical security and bug fixes.

Is there a documented set of versions which will get security and bug fixes?
The reason I ask is our initial investigation suggests getting beyond v5 is likely a large piece of work to move to DI.

This post here would seem to confirm there would be no guarantee of any fixes to version 5:

#3179

Has the position moved on since this post so that versions beyond 5 are no longer supported?

Any guidance on this, and status of WebForms support would be very gratefully received.

Thanks

[rockfordlhotka]

Generally speaking, we only focus on whatever is in main (the next version) and the "currently released" version.

So right now that means 10 (next) and 9 (released).

This isn't hard-and-fast, especially right around the time of a new release. Later this year we'll release 10, and will probably still do critical fixes to 9 for a few months if necessary.

It is also the case that CSLA is open-source and I'm willing to be pretty flexible. So if someone does go through the work of doing some fix for older versions - and we can actually still build those versions - I'll push the updates to nuget. That has happened a couple times in the past 2-3 years, which shows the strength of the community around CSLA.

Some versions are just too old to build, or not in their entirety. I want to say that v5 is in that category, where we can't build everything anymore, because Microsoft no longer supports some of the targeted platforms. iirc, we might have done a priortity security fix for v5 - that can't be used by people targeting (for example) Xamarin, because we can't build those components.

[rockfordlhotka]

Regarding WebForms - this is one of the platforms Microsoft is no longer supporting - at least in new versions of .NET. I think they continue to make it work in the old .NET Framework?

The long-term strategy for anyone on WebForms is to rewrite their UI (or app if necessary) to a modern/supported UI framework - Blazor or Razor Pages are the obvious .NET choices, and I have a strong preference for Blazor in this scenario. Most orgs in this situation, that I've encountered, also evaluate React, Angular, and other options for the rewrite - but if the org is a .NET shop it is nice to know that Blazor is an option.

[haymansfield]

Thanks very much for the detailed response, it is incredibly helpful.

Given our application is on .NET Framework 4.8.2 and ASP.NET WebForms, we’re exploring whether there’s a feasible upgrade path to CSLA v9 that avoids a full rewrite or deep adoption of DI — or is a rewrite the only option?

For example, would it be viable to upgrade to CSLA v9 while continuing to use static DataPortal calls (perhaps via App.GetDataPortal()), and defer DI adoption to a later phase?

Also, would you advise against attempting this kind of upgrade in practice — or have you seen others successfully take a similar path?

Thanks again for your advice.

[hurcane]

If your current CSLA is 4.x, your biggest challenge is getting from CSLA 5 to CSLA 6. I went through the process of upgrading our CSLA 5 codebase to CSLA 8 in the fourth quarter of last year. I had to change about 500 code files, and it took one developer 5 weeks to manually make the changes. If your current CSLA is even older, then you have a second big challenge of transitioning to the business rules subsystem that was introduced in CSLA 4.

Our project is WinForms. We went with the choice of having static classes rather than full DI because WinForms doesn't really suit DI. A majority of the code changes were the same pattern of change applied across the project. There were three common changes.

Within dataportal methods, the business object constructor needed a one-line change:

• Old: var bo = new MyBusinessObject();
• New: var bo = AppContext.CreateInstanceDI<MyBusinessObject>();

In business objects code in constructors needed to be moved to a local Create method. This was common in business classes that don't read or write data, but they have business rules.

These changes consisted of adding a simple block of code like this (and removing the constructor):

[RunLocal]
[Create]
void Create(... might have parameters here ...)
{
    // ... default values here ...
    BusinessRules.CheckRules();
}

Client-side code that used the dataportal was changed from one line to two.
This code...
var myBusinessObject = DataPortal.Fetch<MyBusinessObject>(dbKey);
became this code...

var portal = context.ApplicationContext.GetRequiredService<IDataPortal<MyBusinessObject>>();
var myBusinessObject = portal.Fetch(dbKey);

If I were to start this project today, I would utilize an AI assistant for the majority of those changes. I would estimate cutting the coding time in half.

I'm not familiar with web forms, but I think you might be able to have a session variable to store static service classes instead of using full DI.

Regarding a full rewrite, we're calling it "modernization", but we are essentially going through the process of moving from WinForms to Blazor. We're using a hybrid approach with a mix of UI technologies, with Blazor made accessible via WebView2 controls. You might consider a gradual process where you have the ASP.NET Web Forms server and an ASP.NET Core server simultaneously deployed, with links as necessary to transition the browser from one server to the other.