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

Home
Blog
CSLA .NET
Magenic
Speaking
Publications
About me
Contact me

Login

Version 3.0.1 change log

 

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

 

Changes and Enhancements:

 

This is primarily a bug fix release. The most important issue addressed is one with WPF data binding and lists. See the change to BusinessListBase discussed below.

 

 

Csla – Web and Windows (0700713-C#/VB)

Add toolbox icons for the web and Windows controls.

 

Csla (0700713-C#/VB)

Change the project so PresentationCore isn’t set to copy local into the bin directory. This happened in 3.0 due to one of the earlier VS builds, but is no longer necessary because that assembly is now in the GAC.

 

Csla (0700713-C#/VB)

Change the project so System.Printing isn’t set to copy local into the bin directory. This assembly is indirectly used by another .NET 3.0 assembly, and for some reason it gets copied into the bin directory behind the scenes. By adding an explicit reference to that assembly and marking copy local false the issue is resolved.

 

Csla\DataPortal - RemotingProxy (0700718-C#)

Change the config token AlwaysImpersonate to CslaAlwaysImpersonate to correctly match the VB implementation and to match the naming convention for all other CSLA config tokens. This is a breaking change. This only impacts the remoting data portal channel in C#, and only if you were using this config token.

 

Csla – BusinessListBase (0700720-C#/VB)

Remove the implementation of INotifyCollectionChanged. It is redundant with IBindingList, and implementing both interfaces means raising two changed events for any change. WPF data binding honors both events and that causes serious issues with data binding.

 

 

Known issues:

CslaDataSource

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 7/20/2007)