The CSLA CE is missing a lot of newer .NET features and is not supported.
I've found other Silverlight technologies can often be adapted for use on NetCF -- they share similar limitations. Is this one of those cases? Has anybody given it a try?
I've not looked to see what size project this would be or if it would even be reasonable. Anybody have a feel for that?
Thanks
I suspect it would be possible, but I've never scoped it in detail. My estimate is between 3 and 8 weeks of work for someone intimately familiar with how CSLA is implemented.
That's intriguing for us. We do a large number of custom projects using the Compact Framework, and with WP7's limited multitasking capabilities (and the inertia of enterprise class device providers), I suspect we will continue to use the compact framework for at least 2 more years.
I will propose this for investigation and scheduling after our current engagement (probably sometime in May). Let me know if you have any interest in the code if we move forward.
Thanks.
The previous CE implementation was donated by someone who was in much the same position as you from the sound of it.
If you are successful and are willing to donate the results back to the community I am sure it would be very well received.
My recommendation is to copy the existing CSLA .NET for Silverlight project into a different folder, but with the same relative location to the CSLA .NET for Windows code so all the file links remain intact. Then switch the project to a CF project. Or if that's not possible, then create the CF project in the same way (relative folder structure and linked files) we did with Silverlight.
In CSLA 4 I've continued to eliminate files from the SL codebase, linking more and more from core CSLA. I suspect, given time, there'll be almost no physical files in the SL project. Or the reverse perhaps - the SL project might become the core project and the .NET code will be linked to SL - assuming SL becomes as dominant as I think it will over the next 3-4 years.
Anyway, the fewer files that are duplicated the better from a maintainability perspective is what I'm trying to say 
Agreed. If we are able to do this, we will make every effort to maintain the same code structure/linking approach. The less real differences in code, the more likely the branch will remain healthy I guess.
Thanks
fwiw, the CSLA 4 folder and projects structures are much neater and cleaner than 3.8. It may be unrealistic for you to work with the newer code, but it is something to consider perhaps.
Copyright (c) Marimer LLC