We've been building a large Silverlight application using CSLA 3.8 (I know, it's a tad old but hey, if it aint broke...) to a great deal of success for the last 6 years.
The business is now a little concerned about continuing to invest in Silverlight given that Microsoft have pulled it from their roadmap. The thought of Microsoft saying "the next version of Internet explorer will not support plugins" gives us chills.
We went down the path of Silverlight because at the time we thought a web based system was the way to go. However, in retrospect, what we should have gone with was not a browser based system but rather a system which was deployed via the browser, but run locally on the user's PC.
So our thinking now is, if we don't keep building functionality in Silverlight, what do we build it in? We can't go with Win8 apps as our customers don't use Windows 8. We want to stick with .Net because of our huge investment in CSLA. So we feel that our best bet is to create a three tier system in WPF and transition our Silverlight code base into that. We'd then deploy the exes via ClickOnce.
Before we start prototyping, I was wondering if you can alert me to any challenges in relation to CSLA that you can immediately think of in this endeavour?
Many thanks
Damien
If you have been disciplined about keeping business logic out of the UI and in your business objects you should have a pretty easy time transitioning everything except the XAML to WPF.
For the most part Silverlight is a subset of WPF, though that's not 100% accurate because there are controls that are different (like the datagrid) between the two platforms.
But CSLA is the same between the platforms - in CSLA 4 and higher - and extremely similar between platforms in 3.8. My goal has always been that you could take business code written for Silverlight (and now WinRT) and just have it work in .NET.
We've adhered to an MVVM architecture so in theory it should just be the UI we need to change.
I've begun setting up a test WPF exe and removed the Silverlight version CSLA.dll and replaced it with just the .Net version.
I'm now getting a lot of 'The type of namespace 'Csla' could not be found....' errors.
Am struggling to understand what's going on here...
That can happen because you are missing a dependency of Csla that prevents it from being loaded.
I strongly recommend using NuGet to reference CSLA, because NuGet will automatically bring in all the required dependencies.
As Microsoft has moved more and more of their assemblies into NuGet the dependency management has become really quite complex to do outside NuGet, and I'm pretty much just following their lead out of necessity (but also because it really is a _lot_ nicer to just let NuGet handle this stuff).
Good call on using Nuget, that got me past this stumbling point.
Just out of curiosity, is CSLA 3.8 available via Nuget?
I've installed the latest and greatest version which I think we'll run with as it's high time we upgraded.
The changing of the validation and authorization rules has been the reason we haven't upgraded sooner. We have a lot of business objects that will need changing and I'm unsure how it will flow on to our UI as our controls are integrated with the validation and authorization rules. Fingers crossed it just continues to work.
I can see the benefits of the change in approach however.
Thanks for your help.
Damien
The oldest package on NuGet is 4.1
http://www.nuget.org/packages/CSLA-Core/
Copyright (c) Marimer LLC