Rockford Lhotka
    CTO at Magenic
    Author, speaker, software architect
    Creator of the CSLA .NET framework

About me
Contact me


CSLA .NET 1.x->2.0 Change Log


CSLA .NET 2.0 Change Log

Revised: May 2, 2006


This is list of changes from CSLA .NET 1.5 to CSLA .NET 2.0. I can’t guarantee it is complete, as I’ve assembled it manually, but my intent is to provide some foresight into version 2.0 so people using 1.5 (or earlier) can get an idea of the changes.


Version 1.5 plus:

·        I started with version 1.5 as the base, and (with minor exceptions) all functionality of 1.5 will carry forward

·        This means things like CommandBase, the RulesManager, sorted collections, IDataErrorInfo, global context transfer, globalization all carry forward


Resource file translations:

·        The resource file has been translated to

o       English (en)

o       Danish (da)

o       Spanish (es-ES and es)

o       French (fr)

o       Dutch (nl)

o       German (de)

o       Italian (it)

o       Romanian (ro)

o       Simplified Chinese (zh-CHS)

o       Serbian, Bosnian and Croatian (sr, bh, hr)


BrokenRules (now ValidationRules):

·        Changed BrokenRules to ValidationRules – which isn’t a huge deal because this class is hidden behind BusinessBase anyway

·        Rearranged how ValidationRules is accessed to be more consistent with AuthorizationRules. The end result is that there’s a Protected property inside BusinessBase that exposes ValidationRules to the business object – which is how you call AddRules(), CheckRules() and so forth.

·        Require use of the RuleManager concepts added in version 1.3

o       Eliminate use of Assert method

·        Simplify use of AddBusinessRules by automatically providing the rules manager with a reference to the business object

·        Add overloads to AddRule so it is more consistent and clear

o       AddRule(handler, propertyName)

o       AddRule(handler, ruleArgs)

·        Rule structure is now a class and has been renamed BrokenRule

·        Eliminate GetBrokenRules method, leaving only the BrokenRulesCollection property

·        Eliminate the ToString override, since that information can be obtained via GetBrokenRules.ToString

·        Eliminate the <Description()> attribute for broken rule descriptions. Descriptions are now provided by setting e.Description within the rule method

·        Make all Public interface elements Friend to reduce the surface area of the class – leaving just types exposed

o       All important concepts are now Protected members of BusinessBase, etc.

§         AddRule

§         CheckRules

o       This provides much better encapsulation of the overall behavior

·        Added CommonRules class which contains a library of the most common rule implementations (StringRequired, MinVal, MaxVal, etc.) – the use of which is optional but often helpful

·        De-nested all the classes and put them into a Csla.Validation namespace for organization




·        Added functionality to implement CanReadProperty and CanWriteProperty methods on BusinessBase

·        This new functionality is strictly optional and should incur virtually no overhead if not used

·        Added AuthorizationRules and RolesForProperty classes to Csla.Security namespace to manage the list of roles allowed and denied access to each property on an object



·        Major change to the calling of DataPortal_Update, so DataPortal instead will call DataPortal_Insert, DataPortal_Update and DataPortal_DeleteSelf – thus simplifying the code so each method does exactly one operation rather than DataPortal_Update handling insert, update and delete together as it is in 1.x

·        DataPortal_Create, DataPortal_Fetch and DataPortal_Delete are unaffected by the previous point

·        DataPortal will now automatically call MarkNew and MarkOld as appropriate after create, fetch, insert, update and delete operations – thus simplifying code in those methods (at the cost of some flexibility)

·        DataPortal_OnDataPortalInvoke and DataPortal_OnDataPortalInvokeComplete are now optional – if they aren’t implemented DataPortal will ignore them – making the DataPortal easier to use with non-CSLA classes

·        Added optional DataPortal_OnDataPortalException that a business object can implement to be notified when a server-side exception occurs (immediately before that exception is thrown back to the client-side DataPortal)

·        Of course the major change is that DataPortal will support a multi-transport concept, where you specify not only whether the server-side DataPortal is local or remote, but if remote whether it should use Remoting, web services, Enterprise Services (DCOM) or (eventually) Indigo

·        The client-side DataPortal now has overloaded methods like Fetch(Of T) to provide an alternative to manual casting

·        CommandBase-derived objects now override DataPortal_Execute rather than DataPortal_Update. This means all server-side work runs in the DataPortal_Execute method in a Command object

·        Renamed the client-side DataPortal events by removing the “On” prefix on the event names. This broke .NET standards and caused issues in the C# code since the C# compiler uses the “On” prefix to create the delegates for events.

·        The use of COM+ is very different behind the scenes from 1.x. Business class code is unaffected, but the infrastructure is simpler. The change is that the decision to run inside COM+ or not is made by the server-side DataPortal instead of the client-side DataPortal. This means that there is exactly one entry point to the server-side DataPortal, and it then branches based on whether you’ve marked your method as <Transactional()> or not.

·        Added support for System.Transactions. You can now attribute a DataPortal_XYZ method as <Transactional(TransactionScope)> to tell the server-side DataPortal to wrap your code inside a System.Transactions.TransactionScope. This provides comparable functionality to using EnterpriseServices, but is better because it only escalates to a distributed transaction if required – meaning it avoids that overhead if you are only updating a single database.

o       You can use the following <Transactional()> attribute options:

§         None = manual transactions (you are on your own)

§         <Transactional(Manual)> = manual transactions

§         <Transactional()> = EnterpriseServices

§         <Transactional(EnterpriseServices)> = EnterpriseServices

§         <Transactional(TransactionScope)> = System.Transactions




·        removed this entire interface

·        BusinessBase, etc. now use the OnDeserialized attribute to designate a method for the BinaryFormatter to call

·        A new Protected Overridable OnDeserialized method is in the base classes to allow business objects to customize the deserialization behavior

·        AddBusinessRules is automatically invoked on deserialization and CancelEdit



·        Added interfaces to enable polymorphism for generic types. Interfaces include

o       IBusinessObject

o       IEditableObject

o       IEditableCollection

o       IReadOnlyObject

o       IReadOnlyCollection

·        All CSLA .NET base classes implement one or more of these interfaces (since the interfaces inherit from each other)



·        To support the new bi-directional data binding in ASP.NET 2.0 BusinessBase now includes an overloaded Save method that accepts a Boolean parameter: Save(forceUpdate). If the parameter is True, this overload forces the object’s IsNew flag to False and then performs the save operation – thus forcing the object to do an Update instead of Insert operation.

·        BusinessBase(Of T) handles the System.Object overrides for you. The tradeoff is that you must override a Protected GetIdValue method and return a unique ID value for your object. This ID value is returned as the GetString result, is used to generate GetHashCode and is used in the default Equals implementation


Generic types and methods:

·        ONLY generic base classes are provided. In other words the following 1.x base classes have been REMOVED:

o       BusinessBase (use BusinessBase(Of T))

o       BusinessCollectionBase (use BusinessListBase(Of T))

o       ReadOnlyCollectionBase (use ReadOnlyListBase(Of T))

o       SortableCollectionBase (no longer needed)

o       BindableCollectionBase (no longer needed)

·        Core.ReadOnlyBindingList(Of T)

o       A readonly variation on BindingList(Of T) used internally for CSLA .NET and as a base class for ReadOnlyListBase(Of T)

·        BusinessBase(Of T)

o       To do this I had to split BusinessBase into two parts and add the new type, so there’s now Core.BusinessBase, BusinessBase and BusinessBase(Of T) where the latter two both subclass Core.BusinessBase

·        BusinessListBase(Of T)

o       A subclass of BindingList(Of T)

o       Does not provide in-place sorting like BusinessCollectionBase

·        ReadOnlyListBase(Of T)

·        SortedList(Of T) provides a sorted view over a BusinessListBase(Of T) or a ReadOnlyListBase(Of T) – far better than in-place sorting because this is faster and more stable – unfortunately it isn’t quite as transparent for data binding, but that’s a cost I think is worth paying (binding still works – you just have to tweak a bit of UI code that is otherwise auto-generated)



·        NameValueList will be replaced by a readonly BindingList(Of T), thus becoming bindable.

·        It will no longer contain any SQL code, which imposes a bit more work on the business developer but also means there will be NO code in CSLA that is tied to SQL Server in any way (though obviously my sample app will use SQL Server in the book).



·        Eliminated BusinessIdentity and BusinessPrincipal

·        Added BusinessPrincipalBase

·        Changes here reflect the reality that virtually no one could directly use BusinessPrincipal/BusinessIdentity, so this new scheme makes it easier to create your own custom security by extending CSLA .NET in a clear manner


Minor (but possibly breaking) changes:

·        In the VB code I am changing all parameter and variables to use consistent capitalization – which could break C# code that inherits from VB CSLA .NET in some cases

·        The C# code will comply with the naming on the VB side – luckily version 1.5 of the C# code already uses the capitalization scheme I’m using globally now, so I don’t think this will cause issues for C# code inheriting from C# CSLA .NET 1.5

·        Some protected variables are changing names – specifically collections Locked is becoming IsReadOnly across the board

·        The CSLA in namespaces is now Csla

·        I’m including a CslaKey.snk file with the solution this time around. While it remains a best practice for organizations to create their own key, just adding this one single file to the solution should cut my email support effort by nearly 25%...


Project structure:

·        Reduced framework to a single assembly: Csla.dll

o       Eliminated CSLA.Core.BindableBase assembly (merged into Csla.dll)

o       Eliminated CSLA.Server.DataPortal assembly (merged into Csla.dll)

o       Eliminated CSLA .ServicedDataPortal assembly (merged into Csla.dll)

o       Eliminated CSLA.Resources assembly (merged into Csla.dll)

·        Core classes are in a Core subdirectory

·        Data classes are in a Data subdirectory

·        DataPortal classes are in DataPortal\Client, DataPortal\Server and DataPortal\Host subdirectories

·        Security classes are in a Security subdirectory

·        ValidationRules and related classes are in a Validation subdirectory



·        I do not intend to carry the CSLA.BatchQueue functionality forward at all into version 2.0

o       A couple people have ported the 1.5 version to .NET 2.0 Beta 2 with minimal effort, so I expect that anyone relying on this component will be able to move it forward for their own use



·        In VB added operator overloads

·        In C# fixed operator overloads (they were buggy)

·        SmartDate is now a Structure/struct



·        This is on hold at the moment. Microsoft only released VS Pro on MSDN and that’s what I’m using to build the framework for the book. I’ll probably go back through and make Code Analysis (FxCop) happy as a version 2.1 sort of thing.

·        I am trying to make the code pass validation checking (FxCop). In some cases this means adding attributes to tell FxCop to ignore some of my design choices. Unfortunately in RC0 these attributes aren’t always honored – especially in generic classes – so this goal may be unachievable unless the bugs are fixed by RTM



·        Added ExecutionLocation property so all code can easily determine if it is running on the client or on the server. This is particularly useful for some DataPortal scenarios where different data access should be used if DataPortal_XYZ is running on the client as opposed to the server

·        Fixed some bugs here that were causing issues on the server



·        I’ve added and removed a few String resource entries. Obviously the initial release of the framework will include English resource text for all new entries, but will continue to include the localized text for entries carried over from 1.x. With luck some of the same people who kindly translated the original entries to their native languages will do so again with the few newly added resource strings



·        Converted the 45 or so 1.x nunit tests to be official .NET 2.0 test that run in the VS 2005 test manager

·        I still need to add more tests to cover the generic classes

·        The tests are in nunit, with possible support for the VS testing through some namespace aliases

·        There is exactly one test solution that tests both VB and C# frameworks – ensuring a high degree of consistency between both implementations

·        The tests are now all in C#, specifically because C# is case-sensitive. This helps ensure that both the VB and C# frameworks have the same case on all non-private members (have I ever mentioned how case-sensitivity is an archaic concept that should have been ditched years ago?)

·        Magenic’s Managed Services Organization (MSO) has taken the test project and run with it, adding tons more tests – awesome stuff!!



·        Added a CslaDataSource control to support Web Forms data binding

·        Though technically not part of CSLA .NET, the ProjectTracker sample has a custom membership provider, allowing the standard Web Forms Login control to be used against a CSLA .NET principal object.



·        Added an extender control to address a data binding issue in Windows Forms – along the lines of this one

·        Added an extender control to automate integration between Windows Forms controls and the new AuthorizationRules support in CSLA .NET



·        Added DataMapper, a class containing a Map() method to help copy data into and out of business objects. Intended to simplify code in Web Forms and Web services, but potentially useful elsewhere


(Updated 1/4/2006)