Using CSLA 3.5.2 for existing software, now starting with Silverlight - suggestions for approach?

Using CSLA 3.5.2 for existing software, now starting with Silverlight - suggestions for approach?

Old forum URL:

js999 posted on Friday, December 09, 2011

We have an existing WPF app with about 90 CSLA business objects, using CSLA 3.5.2 and using the WCF DataPortal.

We are now starting a smaller Silverlight app to manipulate selected business objects. We want to be able to use the same WCF data portal for both the existing WPF app and the silverlight project.

I downloaded the CSLA 4.2 package because of the Silverlight support, shared the classes, and I used #if !Silverlight to keep the dataportal code, fetching etc out of the business objects when compiled in Silverlight.

Obviously, there are still several problems, many of them probably rise from the fact that current business objects source is 3.5.2 compatible, while the Silverlight project currently include the 4.2 CSLA silverlight library....

  1. Switching all software to CSLA 4.2 is an option - how big a task is this, considering the 90 existing classes... Any really "heavy" changes influencing the way things are done in general, or just minor fix-up throughout the existing source code?
  2. Will it be possible at all to stay at 3.5.2 for our existing components, and have the silverlight client use the 3.5.2 backend? 

 Thanks in advance for any feedback provided.

JonnyBee replied on Friday, December 09, 2011

There a ton of rocks on the road ....

Basically: Csla 3.5 is quite old version and will not be interoperable with code on Csla 4.2 (shared dataportal etc).  You will not be able to utilize CSLA 4.2 on the client side (with the DataPortal) to use a CSLA 3.5.2 backend/serveside.

My recommendation would be to migrate you application to CSLA 4.2. The major issues will be

I'd suggest to read through all the change notes and the breaking changes on the way up to 4.2.

js999 replied on Friday, December 09, 2011

Thank you Jonny - moving forward is always the most appealing, and upgrading would be a step forward. But it would also involve a lot of work and be a risk for our next release.

I was wondering if there was a valid alternative with less impact on our existing projects, e.g. running CSLA Light 3.6 in the Silverlight client. Or maybe upgrading to version 3.9 overall would mean easy upgrading of existing code, and a much better version of CSLA Light...

Reading through the change notes is a good start, I will do that. Other recommendations as to what version to settle for are still much welcome.

RockfordLhotka replied on Friday, December 09, 2011

If you are going to stick with 3.x, you should go to 3.8.4.

To get SL support you have to use at least 3.6, but that was built for Silverlight 2 and is now about 4 years old. There are a lot of bug fixes and features in 3.8 that are really necessary to be productive.

Ideally yes, you'd move to 4.2, but I understand you can't if your servers are still running .NET 3.5 - then you are stuck on CSLA 3.x too. In that case 3.8 is you best bet.

js999 replied on Friday, December 16, 2011

Thanks Rocky, that will be what we do for now, then.

Best regards,


Copyright (c) Marimer LLC