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

About me
Contact me


Version 3.0.2 change log


This document is the change log for version 3.0.2 of CSLA .NET.


Changes and Enhancements:


Csla – N-level Undo  (0700726-C#/070727-VB)

Change the way IEditableObject calls work, so they no longer cascade the call to child objects in the graph. This brings the IEditableObject behavior more in line with the DataTable, making it work better with Windows Forms data binding.


Manual calls to BeginEdit(), CancelEdit() and ApplyEdit() still cascade to child objects in the graph, so that behavior is unchanged.


This may be a breaking change in some obscure edge cases. There are some subtle differences in how the use of IEditableObject and manual calls interact, and so if you are using both in the same Windows form then you may see some affect. ASP.NET and WPF users should see no difference at all.


The subtle change is this: prior to this change, a manual call to BeginEdit() would prevent a subsequent IEditableObject.BeginEdit() call from having any effect, leaving the object at edit level 1. With this change both the manual and IEditableObject calls will take effect, putting the object at edit level 2. In reality, this change makes the behavior more clear and consistent, but since it is a change it could break some code.


Csla – FilteredBindingList, SortedBindingList (0700807-C#/VB)

The CopyTo() methods were incorrect, copying from the original list rather than the filtered or sorted list. They now copy from the correct list, and both the generic and non-generic implementations work without casting issues.


Csla\Workflow – WorkflowManager (0700808-C#/VB)

Add a WorkflowManager class to encapsulate the code necessary to launch a workflow synchronously or asynchronously. While this is not strictly necessary, because you can write this code yourself, I got tired of rewriting that same threading code over and over again and decided to wrap it into this class.


Csla – EditableRootListBase (0700808-C#/VB)

Reset the parent value of a child object after SaveItem() occurs, so multiple edits of a given child are possible with a remote data portal (bug fix).


Csla\DataPortal – Client DataPortal (0700808-VB/C#)

Add an option to automatically clone an object in the Update() method if the data portal is local and the CslaAutoCloneOnUpdate config setting is True. Right now the default for this value is False for backward compatibility, but in CSLA 3.5 I’ll probably change the default to True because that would be a better setting in most cases.


Csla\Security – PrincipalCache (0700808-C#/VB)

Add a PrincipalCache class that implements an in-memory most recently used cache of IPrincipal objects at the AppDomain level. This cache is designed to avoid duplicate security database hits when building WCF services, due to WCF’s strict separation of authentication and authorization. It may also be useful in some stateless web application scenarios.


Csla – EditableRootListBase (0700918-C#/VB)

Change this class to honor the CslaAutoCloneOnUpdate config setting. Also, if auto-clone is turned off, ERLB now always clones objects on save.


Csla – CommonRules (0700921-C#/VB)

Add a ValueType argument to the rule description for the generic rule methods.


Csla – RuleDescription (0700921-C#/VB)

Fix a bug with argument parsing in RuleDescription.


Known issues:


There is a known issue where the Visual Studio debugger will “lock up” (actually it will eventually crash due to a stack overflow) when an exception is thrown in the DataPortal_Fetch() of a subclass of ReadOnlyListBase.


The issue appears to be due to a bug in the Visual Studio debugger’s exception assistant.


The workaround is to click Tools|Options, then Debugging|General and uncheck the “Unwind the call stack on unhandled exceptions” box (You may need to check the “Show all settings” box at the bottom of the dialog to see this option).



When adding CslaDataSource to a page by choosing to “add a new data source” from within the GridView or DetailsView controls the data source control will not function properly in the designer, though it will appear on the page. (This is due to a bug in Visual Studio in terms of how it loads the control into memory, and I’ve discussed it with Microsoft.)

The workaround is to switch the designer to Source view and back after adding the new CslaDataSource control to a page. This will force the designer to reload the control, making it act properly within the designer.


As before, you can add a CslaDataSource to the page by dragging it directly from the Toolbox, or by typing in the tag manually. Both of these techniques work immediately with no known issues.



(Updated 9/21/2007 2:17:10 PM)