This release of CSLA .NET is focused primarily on enhancing the existing Xamarin support. There is now a Csla.dll targeting PCL Profile111, which is the current profile for Xamarin.Forms projects and .NET Core.

There is also now a CSLA-Xamarin NuGet package that includes a Csla.Xaml.dll with support for Xamarin.Forms. This includes the same viewmodel base classes as the other XAML platforms, and an implementation of the PropertyInfo control tailored for use in Xamarin.Forms.

@JasonBock added even more analyzers for Visual Studio 2015 to help developers avoid common coding mistakes when building CSLA .NET business classes.

We now have support for the prerelease of Entity Framework 7.

The pt and pt-BR resources for Csla.dll have been updated. Other languages need updates as well - please contribute if you are a native speaker!

There is a new way to customize the server-side data portal by implementing an interceptor that is invoked via the new DataPortalBroker. (#564)

There is now a Csla.Xaml.PropertyInfo control for Xamarin Forms as well as WPF/UWP, so you can use the same technique to access all metastate about each property from your XAML.

This means that (now on Xamarin too) you can bind to the property value, as well as CanRead, CanWrite, IsValid, IsBusy, and various other metastate values.

Using this capability your XAML UI can provide the user with immediate and rich visual cues as to whether the user is allowed to read or write the property value, and whether the current property value is valid (and if not, why), as well as whether the property has any outstanding async business rules currently executing.

In short, all the goodness that WPF/Silverlight/UWP developers have enjoyed over the past many years is now available on Xamarin!

(or will be once CSLA .NET 4.6.400 releases in about a week – though you can try it now with the 4.6.400 prerelease available via NuGet)

The CSLA PCL that supports Xamarin includes an implementation of System.ComponentModel.DataAnnotations, and that includes numerous types, one of which is DisplayAttribute.

The PCL uses type forwarding so at runtime the platform's DataAnnotations implementation is used (if available), and the CSLA implementation is only used at runtime for platforms where there's not already an implementation (WinRT Phone is the only remaining platform afaik).

There is a problem with Xamarin however, where all types seem to forward and work fine except for DisplayAttribute. The problem in this case is that at runtime it seems that mono is unable to locate the correct ctor for the type:

This exception occurs when the consume app attempts to access the DisplayAttribute associated with a property to retrieve values from the attribute. It appears that mono is unable to create an instance of the attribute object because it can't find the ctor. The DisplayAttribute class has only a default ctor, but is typically initialized using named parameters, such as:

[Display(Name = "foo")]

I don't know what kind of ctor mono is looking for when it fails, but it obviously isn't finding the default ctor and then setting the property value, which is what would be the expected behavior.

Build the solution – it’ll pull down the CSLA .NET framework from NuGet

Set a breakpoint in the XamarinFormsUi.ViewModels.ProjectList class as shown here

Set the startup app to ProjectTracker.Ui.Xamarin.Droid

Run the app in debug mode (on an emulator or device)

On the first screen click the All Projects button

That’ll attempt to load the ProjectList page and ProjectList viewmodel. At this point the exception will occur and you’ll end up on the breakpoint because of the failure to create an instance of ProjectInfo, but that fails because mono can’t create an instance of DisplayAttribute (used on some properties in the ProjectInfo class).

Of course the CSLA implementation includes the DisplayAttribute class, which is used to decorate properties in consuming classes like this:

[Display(Name = "blah")]

That "blah" value is a human readable name/label for a property.

Because mono actually provides a System.ComponentModel.DataAnnotations implementation, my PCL uses type forwarding so at runtime the PCL implementation is ignored in favor of the platform-specific implementation provided by mono. For example:

This works great on all platforms - except Xamarin Android/iOS where mono throws an exception because it can't find a matching constructor.

The thing is that the DisplayAttribute class has only the default constructor. The syntax being used to set the Name property of the attribute is supposed to use the default ctor, and then the Name property is explicitly set. This is a relatively old feature of C# - but I kind of suspect mono has a bug around this area, as it seems to be looking for a ctor that accepts a parameter when it should use the default ctor.

I am generally positive on this, with the same reservation I’ve had since rumors of this idea came up a couple years ago: Xamarin has been able to navigate and maintain good relationships with Apple and Google (and others) for some years now – releasing support for those platforms concurrent with Apple and Google releasing new versions of those platforms. It may be difficult for Microsoft to maintain comparable relationships with Apple and Google over time, because they aren’t a scrappy startup, they are a peer.

On the upside, what I hope comes out of this includes:

First, rolling Xamarin directly into Visual Studio, thus making it part of my existing MSDN subscription. Just think about the consequences if everyone who has an MSDN subscription (so everyone with Visual Studio 2013/2015 today) can all of a sudden build cross-platform .NET apps for Windows, iOS, Android, and OS X – at no additional cost.

One big thing holding Xamarin back in terms of widespread adoption is its cost. At $2k/developer it is prohibitive for a lot of scenarios, and that has been driving people to less productive and robust tools such as Cordova. But if we all get cross-platform .NET as part of our existing MSDN that radically changes the equation – in a way that favors the use of .NET.

Second, enabling Microsoft to provide UWP (XAML and APIs) on iOS, Android, and OS X. The “U” in UWP is “Universal” – and that’d have a lot more weight if it meant all the popular smart client development targets available today, not just the Microsoft ones. I imagine such a UWP would replace Xamarin Forms with the same XAML dialect we see on Windows 10 and Windows 10 Mobile, and obviously there’d need to be some serious work in creating WinRT API support (yes, WinRT “2.0” is really what’s underneath UWP) for these other platforms – so we won’t see this overnight – but the long-term implications are amazing.

Microsoft’s biggest single problem, especially on Windows phones, but also on Windows 10, is getting high quality apps that target these platforms. A truly universal UWP might help this problem by making .NET/UWP become the single most cost-effective way to build any smart client cross-platform app.

On the whole I am quite happy and excited – congratulations to the Microsoft and Xamarin people who put this together!

From around 1995 until 2010 there was really only one operating system for client computing: Windows.

Prior to 1995 there were a lot of options, though most not recognizable to users today: 3270 terminals, VT terminals, OS/2, Windows, DOS, CPM, and a bunch of others. Now most of these weren’t “client computing”, they were relatively dumb terminal technologies that provided access to a server (back then called a mainframe or minicomputer). Very much like today’s web browser (sans JavaScript).

Today we’ve returned to a chaotic landscape of client computing: browsers, Windows, iOS, OS X, Android, Linux (for the daring), and of course it isn’t like the pre-1995 technologies went away, they are just mostly emulated in Windows. What is interesting though, is that most of today’s client computing technologies do actually enable smart client software development. This includes the browser which can be used as a smart client technology via JavaScript development, even though the majority of browser “apps” are actually just colorful versions of 1990-era terminal-based computing where the processing is all on a server/mainframe/minicomputer/whatever-you-want-to-call-it.

What is interesting about this return to client-side chaos is that it has reopened the door for third party developer tools as a niche market.

In the early 1990’s there were quite a number of companies selling developer tools for other company’s platforms. Borland with C++, Delphi and TurboPascal, Gupta with SqlWindows, Powerbuilder, and a lot more.

When Windows became the dominant client computing platform most of these dev tools fell by the wayside (not that they went away, they just stopped being mainstream). This was because they couldn’t compete with Microsoft’s dev tools, which were always in sync with the platform in a way that was probably too expensive for third parties to match.

I think it is notable that our return to client computing chaos (or pluralism?) today has already led to numerous third party dev tool vendors that sell dev tools for other company’s platforms. Xamarin, PhoneGap, Telerik’s tools, and a lot more.

What is different to me is that in the early 1990’s I thought it was pretty obvious that Windows would become a dominant platform, and I tended to argue against using third party dev tools because I thought they’d have a rough go of it. As cool as Delphi was, I always recommended VB.

Today I’m not so sure. I don’t see any of today’s platforms becoming dominant in the foreseeable future. It is hard to imagine Windows returning to its monopoly status, but I can’t imagine iOS or Android or OS X displacing Windows as the primary corporate desktop computing environment either.

As a result we business developers need some way to build software independently of any particular platform or OS vendor, because we must assume all our business software will need to run on multiple platforms and OSes.

So today I find myself in the inverse of my early 1990’s stance, in that I’m reasonably convinced that building smart client software (at least for business) means using third party dev tools from vendors that aren’t tied to any one platform.

Of course I’ve spent the last 14 years in the .NET world, so naturally I gravitate toward a combination of Xamarin and Microsoft .NET as a way to use my C# and .NET knowledge across all platforms. I get to develop in Visual Studio on Windows where I’m most comfortable, and my resulting software runs on Android and iOS as well as on Windows Desktop, Phone, and WinRT.

As far into the future as I can see there’s no obvious platform/OS “winner”, so as a developer the question isn’t which platform to target, it is which third party dev tool reaches all platforms with a solid strategy that will stand out and thrive over the next many years.

There’s been a lot of exciting change in cross-platform development for C# developers over the past few months. Microsoft introduced the Universal Apps concept for WinRT (Windows 8 and Windows Phone 8.1), and Xamarin introduced Xamarin.Forms (Windows Phone 8, Android, and iOS).

Beneath the Universal App support in Visual Studio 2013 is a broader concept called a Shared Project. With the Shared Project Reference Manager add-in for VS13 you can reference these shared projects from any project, not just Universal App projects.

As a result, you can build a solution like this one:

This solution includes a Xamarin.Forms MobileApp, a Microsoft Universal App (based on the Hub control), a Windows Forms app, and a WPF app. All of these apps use non-UI code from the NonUICode.Shared project.

In fact, the Android, iOS, WinPhone, Windows, and WindowsPhone UI projects have basically no code at all. In the MobileApp all the UI code is in the MobileApp1.Shared project. In the WinRTApp all the UI code is in the HubApp1.Shared project.

The Windows Forms and WPF apps each have their own UI code. Windows Forms is its own thing, and although WPF uses XAML, it is an older dialect that doesn’t share enough in common with WinRT or Xamarin.Forms for sharing.

None of the UI projects contain any business logic or logic to call services. All that code is in the NonUICode.Shared project so it can be maintained just one time. The service calls use HttpClient, which is reasonably common across all the UI platforms, and for the few differences I’m using #if statements to accommodate the per-platform code. For example, here’s a bit of code from a shared viewmodel class:

The overall result is that with reasonable effort you can create an app that spans every type of smart client technology available today; from Windows Forms up to iOS. These apps can share all your business and service client code, and can often share a lot of UI code.

(fwiw, if you build your business logic with CSLA .NET it is a lot easier to create and maintain the shared business and service client code than if you try to build that code by hand)

A couple of us at Magenic have been spending some time looking into the new Xamarin.Forms technology.

It has some nice potential, but is clearly at the prototype stage more than the ready-for-use stage.

The good potential centers around the start of a XAML dialect they’ve created that describes common UI elements and concepts across iOS, Android, and Windows Phone 8 (Silverlight). Using this dialect you can’t get at all the features of each platform, but you can get at enough features to create standard data entry and data viewing forms like you’d need for a typical business application. And there’s always an easy escape hatch that allows you to build per-platform forms for when a common form just isn’t enough.

The bad points are areas I hope they’ll address soon so the technology becomes more useful for real work.

The first roadblock is the almost complete lack of documentation or samples showing how to use their XAML dialect. They have samples showing how to build forms in C#, but not in XAML. It reminds me of the first few months when Microsoft introduced XAML for WPF.

Perhaps it is because of the lack of XAML samples/docs, but it is a real struggle to figure out how to do things like async loading of data, full implementations of data binding against standard data binding types, etc.

I think this whole thing has potential. WPF was really rough when it was introduced, and eventually Microsoft improved the docs and samples and designer tools. And they eventually smoothed over the most egregious data binding issues, allowing the vast majority of existing .NET types to bind into WPF.

You can download the msi installer from the release page, or better yet add references to the framework via NuGet.

Version 4.5.600 includes support for iOS (via Xamarin) and for WinRT on Windows Phone 8.1 in the WinRT.Phone project. This also means you can use the new Universal solution/project type to build WinRT apps for Windows 8.1 and Windows Phone 8.1.

This prerelease also includes the new HttpProxy/Host and BrokeredProxy/Host data portal channels.

The Http data portal channel allows you to host the data portal server directly in ASP.NET MVC 4 or MVC 5 without the need for WCF. It relies only on the HttpClient library to invoke the server, so the client has no dependency on WCF - important for the new Windows Phone 8.1 programming model where WCF doesn't exist.

The Brokered data portal channel allows you to host the data portal server in .NET as a brokered assembly, thus available to a WinRT client app. This means you can build a WinRT app that makes data portal calls, where the "server-side" code is also running on the client device, but has access to full .NET. This will only work on Intel-based devices where full .NET assemblies can be deployed. It will only work with side-loaded apps, not apps from the Windows Store.

As well all know, portable class libraries are pretty cool, but are restricted by the “lowest common denominator” effect.

For example, CSLA .NET supports the use of DataAnnotations along with the richer CSLA rules engine.

In trying to create one of the new “Universal PCL” assemblies to support WinRT on Win8 and WP8 I ran into the fact that WP8 doesn’t support DataAnnotations.

“No problem” I thought, “we already have our own implementation for WP8 Silverlight, for Android, and for iOS. I’ll just use that code.”

Which worked insofar as that I have a Universal PCL Csla.dll that builds.

But it doesn’t work because I can’t actually use that Csla.dll from WinRT on Win8 because that WinRT already has DataAnnotations and so there are type collisions.

As a result it isn’t clear to me that I can actually create a Universal PCL for CSLA – at least not one that supports DataAnnotations across all platforms like I’m able to do if I create one assembly per target platform (like I’ve been doing since 2007 with Silverlight 2).

I guess this makes sense. The guidance around creating a PCL is that you have code that is simple enough that it doesn’t include any platform-specific implementations that would be solved easily using #if directives. The internal implementation of some parts of CSLA is far from simple, and we do use #if directives to optimize for and/or leverage features of each of the 9 platforms currently supported by CSLA (yes, we really provide business code portability across NINE different platforms).

My personal feeling is that I’d rather support all 9 platforms as efficiently as possible, rather than compromise one or more of them just to use a fancy and optional new concept like the Universal PCL.

(of course if Microsoft and Xamarin add DataAnnotations to Windows Phone 8.1, Android, and iOS then I wouldn’t need to implement it in CSLA and that would also solve this problem – so maybe someday :) )

This is an exciting pre-release because it now means you can reuse the same business logic code across all modern app client platforms and the desktop and the cloud. This is a “who’s who” list of supported platforms:

iOS

iPad

iPhone

Android

Phones

Tablets

Windows

WinRT (Windows 8)

WPF

Silverlight

Windows Forms

Windows Phone

Cloud and servers

Windows Azure

Windows Server

ASP.NET (MVC and Web Forms)

WCF

Web API

Linux

OS X

CSLA .NET allows you to easily create reusable business logic (authorization, validation, calculations, etc.) and to share a common app server with simple network configuration. I don’t know of any other open source C# framework that makes it possible for you to reuse the exact same business logic across all these different platforms.

Because the iOS support is new we are asking for your help. If you have the Xamarin tools for iOS please help us out by building some business code using CSLA and let us know if you find any issues (either on the forum at http://forums.lhotka.net or via the CSLA GitHub page.