CSLA.NET Roadmap for .NET 4 and Silverlight 4

solidgranite posted on Monday, November 23, 2009

Hi Rocky

First let me say I'm a huge fan of CSLA.NET

We are currently using Version 3.8.0 (the Desktop and Silverlight versions).

Like a lot of people out there (as there is a go-live license) we are using Beta 2 of Visual Studio 2010 with .NET 4. We're also starting to look at Silverlight 4.

We're currently producing a plan for our next 6 months development and are trying to cater for the next release
(and thus new platform related improvements) of CSLA during that time.

I was wondering, what is your roadmap for support of .NET 4 and Silverlight 4?

I understand that both of these frameworks are still in Beta but was wondering whether your plan for CSLA Version 4??? (next major release)
is to support

.NET 4 and Silverlight 4

or

.NET 4 and Silverlight 3

Could we expect a new major release within the next 3 - 6 months?

I appreciate there must be a huge amount of work with every release and that 3.8.0 is only just out.


Kind Regards

Paul

JonnyBee replied on Tuesday, November 24, 2009

Hi,

The CSLA roadmap is available here. http://www.lhotka.net/cslanet/Roadmap.aspx

RockfordLhotka replied on Tuesday, November 24, 2009

I've started work on CSLA .NET 4.0 - in fact the /trunk of the repository is now 4.0 and 3.8 is in a branch for maintenance.

I don't have a complete plan for changes yet, I'm still in research mode. Some things that are high on my list include:

1. Change BusinessListBase/ReadOnlyListBase/etc to work with WPF (possibly creating a legacy set of collection types for Windows Forms)
2. Take advantage of the SL4/.NET 4 ability to have SL4 class libraries run in .NET 4
3. Improve the business rules subsystem (see this post), possibly also including the use of MEF to dynamically find/load rule methods
4. Support the .NET 4 client profile, also possibly split out interface layer functionality into separate projects (see this thread)
5. Rework LINQ to CSLA so creating a LinqBindingList is an explicit operation, not implicit - and also so there's a LinqObservableCollection for use with WPF
6. Remove the non-generic DataPortal methods, thereby removing the generic type parameter on SingleCriteria

Of these, item 3 is probably the biggest change because it will include some breaking changes around custom rule methods. Interestingly enough, this change has nothing to do with .NET 4 or SL4 - I've just been waiting for a major version number (3.x to 4.x) to make such a major change.

Item 1 is a big deal for WPF users, because auto-sorting and other view-oriented concepts in WPF will now fully work as expected. It does mean some breaking changes for Windows Forms users, but hopefully nothing more than changing the CSLA base class from which you inherit.

Item 2 should be a wonderful thing for SL users, because it should elminate the whole linked file and dual project requirement that exists today. I suspect it will force the use of ObjectFactory though - but I haven't confirmed that yet.

Item 4 is already done - at least the client profile part. I'm still considering whether to split out the interface layer code.

Item 5 should cut down on our maintenance burden around L2C. Auto-creating the LBL seemed like a good idea, but has really been more trouble that I think it is worth.

Item 6 is another one where I've been just waiting for a major version to make such a big change. This will incur some breaking changes around the use of SingleCriteria, and obviously will impact anyone still using the non-generic DataPortal methods (from what I can tell that's a serious minority).

RobKraft replied on Wednesday, November 25, 2009

Thanks for the heads up with this post Rocky! We are currently working on our code generator for cranking out a lot of business objects for Silverlight. So, regarding item #2, I am concerned this could cause a major change to what we are doing. It seems to me that we would still need 2 projects (one for silverlight and one for .Net) if we wanted to use the same method names (like GetIdentity) for both Async and non-Async clients. However, if we created GetIdentityAsync for the Async clients; then we could compile all the code in one DLL (assuming we used an objectFactory or other mechanism to take ado.net referencing code out of the DLL).
Is my understanding correct?

RockfordLhotka replied on Wednesday, November 25, 2009

Rob,

Whether you can get away with just one SL class library for your business
layer depends on whether you can live with the limitations that will impose,
that's true.

I don't plan to have CSLA dictate this one way or the other - it will be a
choice you can make.

But surely for SL-only apps it will make life much simpler. And it will have
no impact on .NET-only apps. Only hybrid apps, where the business layer is
used by both SL and .NET interfaces will be in a position where they might
still need two linked class libraries.

Rocky

solidgranite replied on Wednesday, November 25, 2009

Thanks Rocky for the update.

I'm particularly interested in Item 2 as the PnP team have said they aren't at this stage planning on porting the VS Project Linker project from VS2008 to VS2010.

I'll be looking forward to finding out whether we will be forced to use ObjectFactory for Item 2 however.

Thanks again

Paul