CSLA 3.0 Resources / Upgrade Tips

[jcatmarvin]

We happen to be working with an application that Magenic helped develop a number of years ago, it's currently on CLSA 3.0 (3.8.4) specifically. I can't seem to find any books or resources on this version to even be able to go about assessing if it's feasible or even worth the effort of updating to a newer version.

Thank you in advance for your assistance. -J

[hurcane]

I feel your pain. Our primary project is based on CSLA 3.0.5 (no managed properties). We are in the middle of a project to support both Csla 3.0.5 and Csla 5 in a hybrid environment. We don't have the resources to do a rewrite, so the hybrid approach is seemingly our best option. I think you are in better shape with simpler upgrade options coming from 3.8.

I have yet to find a single source of information for upgrading. However, information is out there in forum messages, past blog posts, and source code samples. In particular, I recommend reading Johnny Bekkum's blog post about upgrading Project Tracker from 3.8 to 4.5.

If you haven't already, I recommend getting the Using CSLA 4 books. The business rule changes, and subsequent enhancements, are a game-changer.

[rockfordlhotka]

Oh! I take it back, those 3.0-3.5 books didn't make it from the old store to the new store. I don't think anyone had purchased them for a very long time, and I guess I didn't get around to them making the transition!

[rockfordlhotka]

OK, fixed that oversight! Using CSLA .NET Version 3.0.

[danielmartind]

How are you finding working with hybrid CSLA @hurcane? Most of my applications are 3.0.5 and have the same issue. Have you taken the approach of renaming the CSLA 3.0.5 namespace so you can use both?

[hurcane]

@danielmartind Yes, we are using a modified version of 3.0.5 (internally changed to version 3.0.9) with the CSLA namespace changed to CSLA3. We are still in proof-of-concept mode, but here are some of the things we have had to deal with in running hybrid so far.

Data portal issue

Our CSLA 3 data portal is configured to use Component Services (Enterprise Services Host channel), which is not supported with CSLA 5. Instead of creating an Enterprise Services channel for CSLA 5, we are using separate data portals for the different CSLA versions. The new code is using http and we will be hosting in ASP.NET Core under IIS. This works for us because our application already includes other IIS web sites as part of the package.

This decision caused a conflict with the configuration settings because both versions use CslaDataPortalProxy. The CSLA3 code was changed to look for Csla3DataPortalProxy, but fall back to the original value if not found. Our plan, not yet tested, is to update all of our known config files during installation. We are still an on-premise product installed via MSI. We need the fallback option because some customers have custom side projects using our product as a library, and we don't want to force them to change their config unless they opt in to using our new features.

Identity serialization

The Csla 3 Enterprise Services channel uses binary serialization and the Csla 5 Http channel wants to use mobile serialization by default. The CSLA-3 based business principal cannot serialize through the mobile formatter. We are handling the DataPortalInitInvoke event to assign a CslaClaimsPrincipal to Clsa.ApplicationContext.User.

Duplication of existing business objects

We are duplicating functionality of certain utility-level business classes in CSLA 5. We are doing this to keep strict isolation and better modularity between our CSLA 3 objects and CSLA 5 objects.

[danielmartind]

Sounds like you have a more complicated scenario than me but good to know about issues you've come up against. I've got as far as running a modified namespace in preparation. I was expecting an issue with identity and having two application contexts. Just need to jump in with a smaller project and see what happens.