I just received this email on November 2nd at 6pm.  I hadn’t heard a word of this prior.  Thanks for the warning…

Windows Azure CTP participant,

You are receiving this mail because you have an application or storage account in Windows Azure in the “USA - Northwest” region.  Windows Azure production applications and storage will no longer be supported in the ‘USA-Northwest’ region.  We will be deleting all Windows Azure applications and storage accounts in the “USA - Northwest” region on November 3rd.

To move your application/storage, first delete the project using the “Delete Service” button.  Then recreate it, choosing the “USA - Southwest” region.  (It may take a few minutes for your previous application and storage account names to become available again.)

Note that deleting your storage account will destroy all of the data stored in that account.  Copy any data you wish to preserve first.

If you would like help migrating your project or have any other concerns, please reply to this mail.

- The Windows Azure Team

I’ve heard some developers asking about UI testing lately.  Specifically, there have been some questions about what we did with NHProf.  So, I thought I would write a little bit about that here. 

There are a variety of different types of tests you can do.  In my experience some have a better ROI than others.  For example, we don’t do any UI testing with automation APIs.  Those are pretty painful, brittle tests to write and we haven’t worked in scenarios where they would really help us.  The two main types of UI testing we tend to do are Unit Tests of the View Model and Binding Validation Tests against the Views.

View Model Tests

There are many advantages in taking a View Model approach to building your UI.  When we build VMs we try and push as much of the UI state into our models as possible.  By doing this we “virtualize” our entire UI, allowing us to simulate a large percentage of the UI behavior without ever opening a Window or showing anything on screen.  This is great for testability.  It means, we can use simple state based unit tests to verify the behavior of our UI.  Here’s a simple example from NHProf:

public class StatementFilterTestFixture
{
    private readonly FilterServiceModel service;
    private readonly IList<IStatementSnapshot> statements;

    public StatementFilterTestFixture()
    {
        statements = new List<IStatementSnapshot>
                         {
                             create_a_statement(100, "hello"),
                             create_a_statement(200, "select * from something"),
                             create_a_statement(300, "select field1 from something"),
                             create_a_statement(400, "select monkey,ninja,pirate,robot from floating_island"),
                             create_a_statement(500, ""),
                         };

        service = new FilterServiceModel();
    }

    [Fact]
    public void Can_filter_by_both_duration_for_values_less_than_300_and_contains_text()
    {
        var filters = new ObservableCollection<IFilter>
                          {
                              new FilterByDuration
                              {
                                  Operator = ExpressionType.LessThan, 
                                Value = "300"
                              },
                              new FilterBySqlContains {Text = "something"}
                          };

        service.Filters = filters;

        Assert.Equal(1, statements.Where(x => service.FilterStatement(x)).Count());
    }
}

Binding Validation Tests

While the WPF/SL data binding mechanism opens the door to building rich View Models, it also introduces a new problem: potential binding expression errors.  Because we didn’t want to give up the productivity benefits of databinding and View Models, we chose to take some time to build a binding validation framework.  We then write simple tests to insure that there are no typos or silly mistakes in our binding expressions.  Here’s an example test from NHProf:

public class StatisticsDetailsTestFixture : ViewTestFixtureBase
{
    private readonly ValidationResult<StatisticsModel> bindings;

    public StatisticsDetailsTestFixture()
    {
        bindings = Validator.For<StatisticDetailsView, StatisticsModel>()
            .Validate();
    }

    [Fact]
    public void BindingsDoNotHaveErrors()
    {
        Assert.False(bindings.HasErrors, bindings.ErrorSummary);
    }

    [Fact]
    public void NameIsBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.DisplayName));
    }

    [Fact]
    public void StatisticsAreBound()
    {
        Assert.True(bindings.WasBoundTo(x => x.SortedStatistics));
    }
}

You can actually take this one step farther as José Romaniello has in testing his Chinook Media Manager.  Take a look at this sweet piece of code.

Hooray!!! I finally released Caliburn v1 to RTW and got the official site launched! This has been a long time coming and I could not have done it without the generous help and support of the .NET community, family and friends.  Many individuals contributed by finding bugs, submitting patches, recommending features or improvements and providing general support and encouragement.  I would like to call out a few special individuals (in no particular order) who contributed significantly:

• Michael Davis – For submitting numerous bug fixes and patches.
• Ryan Rauh – For creating the fabulous Prism integration module, which I believe makes Prism easier to use with Caliburn than without!
• Marco Amendola – For implementing several new features, fixing tons of bugs, submitting patches, writing demos and being an awesome help answering questions on the forums!
• Christopher Bennage – For fixing bugs, inventing and inspiring cool features, participating in the forums, believing in my vision and being willing to put this framework to the test on every WPF/SL application our company has built for the last several years.
• Anna Eisenberg – It goes without saying that my wife has been very gracious to me.  She has supported and believed in me and my work without faltering.  I love you!

I would also like to thank the codeplex users MichaelDBang, Bezieur, p_matyjasek and davidpadbury for their patches and participation in the forums.  And, as always, if I left someone out, I sincerely apologize.  (I’m going to do a better job of tracking this stuff for v2…)

In addition to the release build and the official site, we’ve added a gallery of applications and related projects to our new documentation.  In the coming months I am going to be extending this documentation with additional articles in my MVVM series as well as some cool tutorials.

For those of you who have never heard of Caliburn, it is a UI framework designed to aid in the development of WPF and Silverlight applications. Caliburn implements a variety of UI patterns for solving real-world problems. Patterns that are enabled by the framework include MVC, MVP, Presentation Model (MVVM), Commands and Application Controller.  Here’s a bullet point list of what Caliburn gives you that you don’t get from WPF/SL out of the box:

1. Extends databinding to methods, making MVVM architectures simple and intuitive.
2. Adds pre/post execution filters and rescues to MVVM actions.
3. Simplifies asynchronous programming through a powerful implementation of Coroutines.
4. Provides base classes supporting common UI roles such as Screen Activator, Screen Conductor, Screen Collection and Application Controller.
5. Encourages a convention over configuration approach to architecting solutions.
6. Supports TDD by providing a powerful databinding validation framework for WPF.
7. Enables use of the same API for WPF and Silverlight architectures

Here’s a more detailed explanation of its key features:

Actions

Actions extend the databinding capabilities of WPF/SL by enabling a UI to bind not only to data but to methods as well. Caliburn provides a consistent API for wiring events, gestures, and attached events to methods on a presentation-related class. This type of method binding removes much of the glue code involved in building an MVP or Presentation Model (MVVM) architecture. In addition to basic execution of methods, Caliburn's action mechanism can pass data from the UI into the methods as parameters and bind return values back to the UI. A filter mechanism (similar to ASP.NET MVC) exists for decorating methods. Filters can affect the availability of a given action through the UI, which can be represented by automatically disabling, hiding or collapsing controls. Caliburn can also automatically execute methods asynchronously, and execute callbacks. It does all the thread marshalling for you. If that's not enough power, you can take advantage of Caliburn's Coroutine implementation through actions as well.

Commands

Caliburn's command implementation is an alternative to WPF's and supplies very useful functionality that is altogether missing from Silverlight. As you might expect, it is an implementation of the Command Pattern.. Commands are built on top of Actions and thus share many of the same features, including multiple input parameters, filters and automatic asynchronous execution. Additionally, commands can be created in hierarchies, such that a parent command can execute multiple child commands. The parent command's availability can also be affected by its children in various ways. There are two types of composite commands available out of the box, but the mechanism is extensible.

Application Model

Caliburn supports UI architectures based on MVP and MVVM through its various implementations of the IPresenter interface. Often times, these types of architectures involve tricky UI lifecycle issues such as handling activation, deactivation and shutdown semantics for various UI components. The basic logic for handling these scenarios is found in Caliburn’s Presenter, PresenterManager, MultiPresenter, MultiPresenterManager and Navigator classes. By composing these classes you can create a hierarchical model representing the entire runtime state of your application. In Silverlight, you can even use the browser as an Application Controller with Caliburn’s support for deep linking. By using these classes as a starting point, you can very quickly get up in running with an MVP or MVVM architecture.

Conventions

Convention over configuration is a way to leverage a great deal of a framework's power without having to go through tons of tedious configuration or setup code. Caliburn has basic conventions around view discovery, binding of actions and building-up of hierarchical View Models. These are all implemented through well-known services which are easily replaceable or extendable with your own conventions.

Testability

One of the goals of Caliburn is to make it easier to build applications right. To this effect, Caliburn has features geared around unit testing. There is currently rich support for testing databindings in WPF and a simple fluent interface for verifying change notification on model objects. Unit tests for view bindings give the developer the confidence they need to refactor their models, knowing that they will be aware of broken bindings before they run the application. Not only will they be aware that the bindings are broken, but Caliburn’s binding validator will tell you exactly where the problem is in the UI hierarchy and what the specific error was.

Utilities

Various utility classes and extension methods are provided as part of Caliburn. The most popular of which is the Execute static class, which enables a developer to easily execute code on a background thread or on the UI thread.

Caliburn has come a long was since I first started working on it about three years ago and we are not finished yet.  I’ve got a host of ideas for v2 and now is a great time to get started.  Download the framework.  Start using it to build UI’s, give me feedback and help us make it even better in v2!

With Much Gratitude (and hoping this makes your work a little easier),

Rob Eisenberg