CSLA 4 version 4.2 is now released and available for download.

• CSLA download page
• NuGet

The primary focus of this release is the introduction of support for mono (Mac, Linux), monotouch (iPhone, iPad), and mono for Android.

This version also supports Windows Phone “Mango” (SDK version 7.1).

You can now reuse your business code across .NET, Silverlight, Windows Phone, and these newly supported platforms as well. As demand grows to build applications that must work on various mobile devices, the ability to directly reuse your business classes is compelling!

Version 4.2 also includes a number of enhancements to the existing CSLA 4 rule engine, along with various other features and bug fixes. Check out the change log for more information.

Our next step is to provide support for Silverlight 5 in CSLA 4 version 4.3, followed by support for WinRT (Windows 8) in version 4.5. The expectation is that your existing CSLA-based business classes will continue to work in Silverlight 5 and WinRT, providing even more long-term reuse, maintainability, and cost-effective development.

The Beta 1 release of CSLA 4 version 4.2 is now available for download on the CSLA download page.

This version adds support for:

• Windows Phone 7.5 “Mango”
• mono
• mono for iOS (iPhone/iPad)
• mono for Android

Of course it continues to support .NET 4 and Silverlight 4.

This release also includes numerous bug fixes and small enhancements. In particular, Jonny has done a lot of work to make the business rules subsystem more flexible and powerful. See the change log for a list of all changes.

At this point we have spent zero time or effort on the samples. Most samples will continue to run when bound against the 4.2 assemblies, but some may encounter minor issues. The samples in the download are still bound to the 4.1 assemblies. We will be updating the samples during the 4.2 beta phase.

Because of the organizational changes of mono from Novell to Xamarin, the 4.2 release has taken a lot longer than any of us would have preferred. I am pleased that we’re entering the beta phase, and can now move deliberately toward a release.

If you are using 4.1, I strongly recommend that you test your code against 4.2. In part to help us identify any outstanding issues, and in part because the bug fixes and enhancements to the rules subsystem may be very helpful to you.

There is now an alpha release of CSLA 4 version 4.2 available for download:

• Download CSLA 4 version 4.2.0

The big initiative for version 4.2 is to add support for the following platforms:

• Linux and OS X (via Mono)
• Android (via MonoDroid)
• iPhone and iPad (via MonoTouch)

This alpha release does not include binaries for these platforms, but does include code and sln files (for Visual Studio and/or MonoDevelop) you can use to build the source on each of the platforms.

At this point in time we have the following:

1. CSLA 4 builds and runs on mono in Windows and Linux.

1. Core CSLA 4 functionality (Csla.dll) should be the same as on .NET 4.
2. ASP.NET code using CSLA objects should work using Csla.Web.dll
3. The Windows Forms support with Csla.Windows.dll is limited due to incompatibilities in data binding between real Windows Forms and the mono implementation of Windows Forms.

1. You should find behaviors and features for Android identical to that provided for WP7.
2. There is not currently an equivalent to Csla.Xaml.dll for Android.
3. No testing has been done around the use of any remote data portal channel – only the local data portal has had any testing.

1. You should find behaviors and features for iOS identical to that provided for WP7.
2. There is not currently an equivalent to Csla.Xaml.dll for iOS.
3. No testing has been done around the use of any remote data portal channel – only the local data portal has had any testing.

Please remember, this is an alpha release, in the early stages of testing and stabilization. Any help you can provide in terms of testing and resolving issues is appreciated! Direct inquiries to http://forums.lhotka.net.

Other changes of note to existing .NET, SL, or WP7 users include:

• When an async rule completes, rules for affected properties are now also run
• BackgroundWorker from Csla.Threading is now available in WP7
• Some cleanup work was done around CslaIdentity – this shouldn’t be a breaking change, but the internals are now quite different
• Fix a bug in non-generic GetProperty where field wasn’t always set to the correct default value

A few weeks ago I posted about my initial efforts to port CSLA 4 to MonoDroid. The idea being that business classes created for WP7 could be used on Android as well.

That inspired some people – which is awesome!

• Stuart Bale volunteered to help port CSLA 4 to MonoTouch, for iOS (iPhone/iPad).
• Jonny Bekkum (a long-time CSLA team member) volunteered to port CSLA 4 to mono – the open source implementation of .NET that runs on Linux, Windows, and other platforms.
• Kevin Ford volunteered to finish what I’d started by getting CSLA 4 ported to MonoDroid (in reality, he’d already started a parallel effort, and then merged his work into mine).

Initial code for all three projects has been checked into the svn code repository. Jonny has some test apps running in mono, so there’s some confidence in that code. Kevin has a small test app running in Android, so there’s some confidence there too (though it is earlier in the process). The MonoTouch port is the hardest of the three due to some limitations of MonoTouch, and we don’t know for sure that the current code works (though it does build in MonoDevelop).

My current plan is that CSLA 4 version 4.2 will be the release that includes support for mono, Android, and iOS – in addition to the existing support for .NET, Silverlight, and Windows Phone. That’ll be exciting!

If you are a developer on any of these three new targets, we’d appreciate any help in testing the code to see if it works, and to find solutions to anything that doesn’t work. Please post any issues or comments on the forum at http://forums.lhotka.net – thanks!

I’ve started the process of porting CSLA .NET version 4.1 to MonoDroid. I expected this to be relatively easy because I’ve already got a version of CSLA 4 running on WP7, and from everything I know about MonoDroid it should be pretty comparable (excluding anything to do with XAML and UI concepts of course).

After a couple hours of trying to get the Android emulator to run on my machine, I discovered that the hybrid C++ and Java worlds really don’t “get” Windows. They interpret Windows configuration in different ways. I’m not sure which one is lame and out of date (by around a decade), but either C++ or Java apparently needs help…

Fortunately some googling (with Bing of course ) turned up the answer in the form of an environment setting named ANDROID_SDK_HOME that both C++ and Java will honor. The problem is that my User directory isn’t on the C drive, and either C++ or Java can’t handle this concept. Setting ANDROID_SDK_HOME to the path of my actual User directory solves the issue so the emulator works as expected.

The Android emulator is extremely slow, but functional. Just deploying my tiny little test app takes several minutes, and my computer is no slouch. It is clear that Android developers don’t round-trip very fast in terms of running their code to see if it works. I feel sort of like I’m back in 1992 on a VAX where the compile-link-run cycle took minutes. I’m obviously very spoiled with the performance of things like the WP7 emulator or the ASP.NET development web server, where the compile-debug/run cycle takes seconds (at most).

The process of getting CSLA 4 to at least build in MonoDroid took around 4 hours of work. Not that I’m done, but the code does compile at this point. The holdups and issues are:

1. MonoDroid doesn’t have ObservableCollection and a set of related types, so I’ve started implementing them myself
2. MonoDroid doesn’t know about “Add service reference”, it only knows about “Add web reference”, and that means I need to create a new data portal proxy/host pair
3. It doesn’t look like the System.ServiceModel assembly that comes with MonoDroid actually works – my one remaining build error has to do with this assembly – and this probably means some other client-side data portal elements will be affected (like LocalProxy) – I think this indicates some bad factoring on the part of CSLA in terms of the client-side data portal implementation though, so in an odd way this might be beneficial in that the problem highlights a design flaw that needs fixing
4. There are some bugs in MonoDroid in VS, where setting some project properties “doesn’t take” – change the property values in VS and they aren’t saved to the project file – but edit the project file in a text editor and the changes are honored – not a big deal, and MonoDroid is in an early beta, so this sort of thing is to be expected
5. There’s no XAML or directly comparable concept on Android, so I’m not even trying to port Csla.Xaml, only the core Csla project – I’ll probably need to create a Csla.Android project with UI components appropriate to the Android UI technology

I mocked up the initial types to implement ObservableCollection, and it won’t take a lot more effort to make them have the functionality required by CSLA. I don’t feel the need to completely replicate those types – only the parts CSLA cares about.

Creating a data portal proxy/host pair isn’t hard, the data portal is designed with this sort of flexibility in mind. However, this will be the first non-WCF proxy/host pair I’ve built on the Silverlight/WP7 code base, so I’m looking forward to establishing that it is as easy as it should be.

The unexpected dependencies on System.ServiceModel are probably the most worrisome aspect of this project so far. I suspect unraveling the dependencies and fixing the design/implementation may lead to some breaking changes in the Silverlight/WP7 code. On the other hand, if my early suspicions are correct, the design is probably flawed and I’ll be able to improve things as a result.

The question is whether I leave the SL/WP7 code alone and just fix the dependencies in the Android code base. That’s probably what I’ll do in the 4.x timeframe, because I really try to avoid substantial breaking changes in point releases…

The loss of Csla.Xaml is not ideal. At the very least I think a Csla.Android project will need ViewModelBase and ViewModel, but I suspect other Android-related UI components may be required.

Anyway, I’m quite impressed by MonoDroid. It seems pretty complete, pretty functional, and pretty well integrated into Visual Studio. Other than my issues with the emulator configuration the install was painless.

To head off this question before it is asked: I do expect I’ll create a version for MonoTouch at some point.

But MonoDroid has a much lower barrier of entry since it installs on Windows and works in Visual Studio. MonoTouch requires a non-trivial cash outlay to buy a Mac, and a non-trivial time outlay to learn the Mac, MonoDevelop, some Mac svn implementation, etc. Where I’ll probably have a working version of CSLA 4 for Android in under 20 hours, I strongly suspect it will take more than twice that long (and a lot of money) to get a version working in iOS.

In this regard I must give kudos to Google, Android and MonoDroid – they have a much lower barrier to entry than Apple currently provides.