Customizing CSLA

colinjack posted on Tuesday, August 15, 2006

Hi Guys,

I'm going to have a few cases where I want to add members to existing CSLA types (BrokenRulesCollection being one example). As I see it I have two decent ways of doings this:

   1) Create my own MyCompany.CSLA assembly, put the new types in there and derive from the CSLA ones (using InternalsVisibleTo from the CSLA assembly to my assembly).

   2) Modify CSLA directly.

The first solution seems like it'll give me the easiest upgrade path...BUT I still need to modify CSLA to hook in my custom classes at the appropriate points so its not perfect.

I imagine you've all tackled this sort of thing so I'm wondering how you've done it?

Thanks,

Colin Jack

ajj3085 replied on Tuesday, August 15, 2006

I would opts for #1, since with #2 everytime there's a new version put out, you'll spend more time merging the changes with your changes...

If you need access to internal members of Csla and you're on .Net 2, add a file into Csla whcih includes the InternalsVisibleTo assembly attribute.  This will allow you to keep everything seperate and still have access to internal Csla stuff, should you need it.

HTH
Andy

Brian Criswell replied on Tuesday, August 15, 2006

I have had good success with keeping my copy of CSLA in Subversion.  Whenever Rocky releases a new version of CSLA, I just unzip it over the top of my copy.  TortoiseSVN tells me which files have been modified and I diff them to see what the changes are.  The changes generally fall into one of two categories:

1. Bugs fixes/new features from Rocky - I leave these.
2. Reverting customisations I have made back to vanilla CSLA - I choose my old version.

The whole process takes about 15 minutes.

This allows me to make modifications directly to the CSLA files.  For instance, I change SafeDataReader to implement ISafeDataReader instead of IDataReader.  This allows me to have child classes that can be loaded by either SafeDataReader or my SafeDataRowReader.

ajj3085 replied on Tuesday, August 15, 2006

Brian, I too keep Csla source in source control (Vault, in my case).  I just dislike having to be very careful about merging... not to mention testing to make sure my changes to Csla don't really break anything.  You can still have unit tests pass because they aren't thorough enough to test the exact situation that will cause a failure.

DansDreams replied on Wednesday, August 16, 2006

I went the #2 route with the VS6 version.  Boy oh boy did I go down the #2 route.

While handling new CSLA releases may seem like a 15 minute job with with the source control and merging functionality, if you're really planning on extensive modifications I don't think that is so easy once your modified version doesn't look so much like the original.  Granted, there's so much more functionality in this version of CSLA and that risk is greately mitigated, but I for one am never going down that road again.

Brian Criswell replied on Wednesday, August 16, 2006

One thing that you could do if you are going to make extensive modifications to CSLA is to keep the vanilla CSLA in a separate branch of your CSLA repository.  You can then unzip the new versions on to the branch and this will highlight what the changes are.  Then, if you want, you can merge the difference between the two versions on the branch back into your main version that has your customisations.

SonOfPirate replied on Wednesday, August 16, 2006

Having had a framework in place before "finding" CSLA, our approach was to use CSLA as a guide and toolset to improve our own framework - which we refer to as a hybrid-CSLA (on steroids) framework.  With .NET 2.0, we went back to the drawing board and redesigned our framework from the ground-up but due to all of the customizations, extensions, etc. that we have in our framework we again chose a custom implementation.

With that in mind, the way we handle maintenance issues such as upgrades to the source code in CSLA (and other components we have access to the source code), is to maintain each version separately in our source control library.  We do not merge versions.  Then we can use a comparison tool such as BeyondCompare to diagnose what changes were made from version to version.  Once identified, we can go through them and determine what may or may not need to be done to our own framework to leverage those changes.

We have found that this is rather painless once the framework is established on both sides.  As mentioned in a previous post, most changes from one version to the next are going to be bug fixes (which may have already been caught) and/or enhancements to existing features that can be rolled into the framework in a similar manner if desired.  Only when there is a major change, like going from 1.0 to 2.0 does this present a problem.  But, since our framework needed retooling, it fit right in with our own plans (this time).

Because we aren't dependant upon the actual CSLA builds, we can chose when and if to implement the changes.  This allows us to coincide this with scheduled upgrades and releases to our framework and better manage version creep that can occur with multiple projects using multiple versions of our framework refering multiple versions of CSLA and so on.

It has worked well for us thus far.