This is a bug fix release, with important fixes for some issues in version 4.0.0. If you are using CSLA 4, you should consider upgrading to 4.0.1 as soon as possible.

Please note that there are a couple potential breaking changes in 4.0.1:

If you are using private backing fields, your RegisterProperty() calls must now specify Relationships.PrivateField so CSLA knows you are using a private backing field. If you don't do this, you'll get runtime exceptions.

The Save() and BeginSave() methods now raise different (and more reliable) exceptions. If you are explicitly checking for NotSupportedException you will need to check for InvalidOperationException.

While I try to avoid adding breaking changes in point releases, these were important and I thought it better to get them out as early in the CSLA 4 life-cycle as possible.

Over the past couple years a lot of people (hundreds) have friended, or tried to friend me on Facebook. The result is that I have a fair number of “friends” I don’t know. I look at some of these names and wonder who these people are…

So I’m addressing that problem by creating a public persona page for my public persona:

Anyone can Like this page if they want to keep up to date with my professional life – writing, speaking, CSLA .NET, Magenic and so forth.

With this set up, I’ve started the tedious task of going through my Facebook “friends” list and removing anyone who’s name/face I don’t recognize. It turns out that Facebook’s UI is set up to add friends, not to remove or manage your friends list.

If you are one of these people, please don’t take offense – just go Like my Rockford Lhotka public persona page.

My personal area of focus is on application architecture, obviously around the .NET platform, though most of the concepts, patterns and techniques apply to any mature development platform.

Application architecture is all about defining the standards, practices and patterns that bring consistency across all development efforts on a platform. It is not the same as application design – architecture spans applications, while design is applied to every specific application. Any relevant architecture will enable a broad set of applications, and therefore must enable multiple possible designs.

It is also the case that application architecture, in my view, includes “horizontal” and “vertical” concepts.

Horizontal concepts apply to any and all applications and are largely orthogonal to any specific application design. These concepts include guidelines around authentication, authorization, integration with operational monitoring systems, logging, tracing, etc.

Vertical concepts cover the actual shape of applications, including concepts like layered application structure, what presentation layer design patterns to use (MVC, MVVM, etc), how the presentation layer interacts with the business layer, how the business layer is constructed (object-oriented, workflow, function libraries, etc), how the data access layer is constructed, whether broad patterns like DI/IoC are used and so forth.

In today’s world, an application architecture must at least encompass the possibility of n-tier and service-oriented architectures. Both horizontal and vertical aspects of the architecture must be able to account for n-tier and SOA application models, because both of these models are required to create the applications necessary to support any sizable suite of enterprise application requirements.

It is quite possible to define application architectures at a platform-neutral level. And in a large organization this can be valuable. But in my view, this is all an academic (and essentially useless) endeavor unless the architectures are taken to another level of detail specific to a given platform (such as .NET).

This is because the architecture must be actually relevant to on-the-ground developers or it is just so much paper. Developers have hard goals and deadlines, and they usually want to get their work done in time to get home for their kid’s soccer games. Abstract architectures just mean more reading and essentially detract from the developers’ ability to get their work done.

Concrete architectures might be helpful to developers – at least there’s some chance of relevance in day to day work.

But to really make an architecture relevant, the architect group must go beyond concepts, standards and guidelines. They need to provide tools, frameworks and other tangible elements that make developer’s lives easier.

Developers are like electricity/water/insert-your-analogy-here, in that they take the path of least resistance. If an architecture makes things harder, they’ll bypass it. If an architecture (usually along with tools/frameworks/etc) makes things easier, they’ll embrace it.

Architecture by itself is just paper – concepts – nothing tangible. So it is virtually impossible for architecture to make developer’s lives easier. But codify an architecture into a framework, add some automated tooling, pre-built components and training – and all of a sudden it becomes easier to do the right thing by following the architecture, than by doing the wrong thing by ignoring it.

This is the recipe for winning when it comes to application architecture: be pragmatic, be comprehensive and above all, make sure the easiest path for developers is the right path – the path defined by your architecture.

I started by getting the CSLA 4 codebase (from Silverlight) to compile in WP7.

As an aside – working with WP7 is really a smooth experience. The emulator works quite well, and the debugging experience is comparable to working with Silverlight. I can see where it would be hard to debug/test things requiring touch or other device hardware, but for basic app development the process is quite enjoyable.

Then I spent some quality time fighting with reflection. Over the years, as .NET has evolved alternatives for reflection, CSLA has adopted those alternatives; dynamic methods and now lambda expressions. The specific things CSLA is doing can’t be easily done using the DLR, or I’d consider using that approach.

But WP7 is based on Silverlight 3, which predates the cool stuff in Silverlight 4. That means that the lambda expression concepts used in CSLA 4 wouldn’t build in WP7 – so I basically put TODO comments in their place to get the codebase to compile. Then I went back through and dug up the older 3.x code and tried to just plug it in, replacing the TODO comments.

That turned out to be a little harder than I expected. As part of replacing reflection, we enhanced the functionality of some of the code in CSLA 4, and the 3.x code didn’t handle all the same scenarios. I don’t want my WP7 code to be incompatible with the .NET/SL implementations though, so this basically meant rewriting the 3.x reflection code to support the CSLA 4 functionality.

After a few hours of work all my dynamic method calling unit tests now pass (except for the one that proves that dynamic method invocation is faster than reflection – obviously that one has no meaning in WP7 at the moment). That’s a relief, as it means that essentially all the core functionality of CSLA 4 now works.

With the notable exception of the data portal. It isn’t clear yet what’s failing, but it appears to have something to do with type resolution. I know that Silverlight and .NET don’t work the same in this regard, and I’m beginning to suspect that either I need to revert some other code back to 3.x, or that WP7 doesn’t act the same as Silverlight 3 or 4.

In any case, this is all very encouraging. I am now quite confident that we’ll be able to take CSLA 4 business classes from Silverlight and run them in .NET or on WP7 without change. Just think about building a business class and knowing that it can be used to create Silverlight, ASP.NET MVC, WP7, WPF, WCF, Web Forms, Windows Forms and asmx interfaces! Too cool!!

When we created CSLA .NET for Silverlight it was long before Silverlight 2 shipped, and there was no workable unit test framework for Silverlight. Even today, it is tricky to test async methods and features with mstest in SL. Perhaps most importantly however, I wanted to have the same exact unit test code running in .NET and Silverlight – and that’s a level of parity that is hard to achieve.

And I have a few hundred unit tests for CSLA that rely on UnitDriven, so it isn’t a trivial thing to think about switching to something else – so it is important that UnitDriven work on WP7 too.

Fortunately Justin was able to get this done in an evening. It turns out that the only major change required was to the UI, because obviously the WP7 form factor is very space constrained compared to a full-size screen.

The end result is that there’s a preview release of UnitDriven that works on WP7 – you can download it from codeplex.

Most of my CSLA unit tests are passing at this point, which gives us some confidence that UnitDriven is working as expected. There are some UI issues still, especially with long test names and some scrolling issues.

But if you are looking for a way to write unit tests for your WP7 Silverlight code, and especially if you want to use the same unit test code on .NET, Silverlight and WP7, then UnitDriven is something you should consider.