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....
Thanks in advance for any feedback provided.
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.
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.
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.
Thanks Rocky, that will be what we do for now, then.
Copyright (c) Marimer LLC