At the .NET Rocks Road Trip event in Charlotte, NC this week an attendee asked if there’d be a way to run the new Windows Store apps on Windows 7.

These are apps running on the new Windows Runtime (WinRT) platform.

Basically the question was whether Microsoft would issue an update so WinRT apps can run on Windows 7.

My answer, which got a great laugh, but is actually serious, is that Windows 8 is the update to Windows 7 that allows it to run WinRT apps.

I acknowledge that this answer is loaded with humor. But I am also serious in my answer.

I’ve been running Windows 8 full time for a few months now, and haven’t run into any issues with Windows 7 apps not working on Windows 8 (except for a couple odd-ball Steam games that I suspect break some Win32 programming rules). All my work software, all my business software, and my important games (Battlefield 3, XCOM, Supreme Commander, L4D2) all work fine on Windows 8.

Windows 8 turns out to be a slightly faster version of Windows 7, that can also run WinRT apps. Hence, Windows 8 is the upgrade to Windows 7 that allows you to run Windows Store apps.

This is a relatively minor update from the previous beta, with a small number of bug fixes. The big thing is that Tiago and Jonny put a lot of work into making sure the samples are all working with CSLA .NET 4.5.

Notice that the rule’s constructor sets the rule’s IsAsync property to true. This tells the CSLA rules engine that the rule will be async.

Also notice that the rule’s Execute method is marked with the async keyword, allowing the use of the await keyword within the method. In this example, the rule uses the data portal to asynchronously execute a command object by awaiting the ExecuteAsync method.

Because the rule has IsAsync true, the Execute method must call context.Complete to indicate that the rule has finished processing. If you don’t call context.Complete the CSLA rule engine will never process the rule’s result, and you’ll have a bug in your application.

The command object itself also uses the async keyword to implement the DataPortal_Execute method. Notice that this method returns a Task. The server-side data portal components are smart enough to detect when a DataPortal_XYZ method returns type Task, so the DataPortal_XYZ method is invoked correctly.

Within the DataPortal_Execute method I just use Task.Delay to create an artificial delay. This represents some long-running operation such as calling a slow web service, invoking an intensive oData query, or something like that.

The end result is that a business object can attach this CustomRule to a property, and the rule will run asynchronously. This is done in the business class’s AddBusinessRules method.

In your UI you can use helper components such as Csla.Xaml.PropertyInfo to determine that the property is running an async rule. For example, you might use XAML like this in WinRT:

The specific XAML syntax is a little different in WPF/Silverlight because the XAML language is more mature there than in WinRT. But the basic concept of building a rich user experience based on an async rule is the same across all smart client platforms.

I just checked in a series of data portal enhancements that have been on the wish list for a while. Mostly focused on pre- and post-processing behaviors.

The big one is that you can now provide an IInterceptDataPortal provider on the server to get Initialize and Complete notifications for every data portal call, allowing for logging/tracing and IoC scenarios. The logging/tracing is probably obvious, because these methods get a lot of detail about each data portal server invocation and you can do what you’d like with that data. The IoC scenario may be less obvious, but the Initialize method should provide you with a consistent way to create or retrieve your server-side IoC container so it is available for the duration of the server-side processing. I suspect most people will put the container instance in Csla.Application.LocalContext to ensure it is easily and consistently available to all code regardless of runtime environment (ASP.NET, pure .NET, WinRT, Silverlight).

The existing pre- and post-processing calls now all get a lot more data than they did before, so they should be more useful by far. The primary focus was on the Invoke, InvokeComplete, and InvokeException methods in factory objects, where the previous implementation was poor. In that context I did make a breaking change, because those methods are now passed a Csla.DataPortalEventArgs value as a parameter, instead of the more limited DataPortalContext they got before.

While I was doing this change though, I also increased the amount of data provided to the pre and post-processing DataPortal_XYZ and Child_XYZ style methods. So everyone gets an upgrade

Finally, the data portal no longer returns the business object to the client when an exception happens – at least by default. Up to this point the data portal has always returned the business object from the server to the client via the DataPortalException, but almost no one actually uses that value. By not returning it, we save a bunch of network traffic and improve performance. If you want the value, you can configure the data portal to use the older behavior. So this is a breaking change, but one with an easy workaround.

CSLA 4 version 4.5.2 is now online. This is Beta 1 of the 4.5 release, and is the start of the beta process. I expect to release a number of betas in relatively short order between now and the end of October. My plan is to have a final release before Windows 8 GA.

You can get this beta release from nuget (show unreleased versions), or via the installer from the CSLA download page.

This release supports .NET 4, .NET 4.5, WinRT, and Silverlight 5.

This beta release is a major change over the previous preview releases.

CSLA now fully supports the new WinRT platform for Windows 8 development.

The data portal now supports async/await on the client and on the server. Additionally, the .NET, WinRT, and Silverlight data portal implementations are now the same. There is no longer a “Silverlight data portal”. To make this happen, the data portal pipeline underwent major changes. This includes a number of breaking changes.

The MobileFormatter is now available for use by .NET applications (not just Silverlight and WinRT). This might allow .NET apps to run in partial trust, and certainly allows .NET apps to use the same data portal channel/endpoint as a WinRT or Silverlight app.

Jonny has done a lot of work on the business rules engine. There shouldn’t be any real breaking changes, but there are a lot of good new features.

BusinessBase metastate properties (such as IsDirty) are now bindable – they raise PropertyChanged as you’d expect. This enables some XAML scenarios, but be careful because WinRT XAML doesn’t notice when the DataContext has changed, so you can run into some strange issues when saving an editable object in WinRT.

Johann put a lot of work into the nuget release process, allowing us to use nuget for prereleases like this one, and to create a nuget package with code templates for use in your projects.

We now support .NET 4.5 and 4.0 with CSLA 4.5, so you can use the same CSLA 4.5 on existing .NET 4 machines, on Windows Azure, and also use it on .NET 4.5 machines. A 4.5 client can talk to a .NET 4 server and visa versa.

WinRT now includes language resources.

A number of changes were made to the Windows Forms CslaActionExtender type.

Be aware that the .NET 4 and Silverlight 5 environments now require that you use the Async Targeting Pack from Microsoft (typically via nuget) so that CSLA and your code can use the async/await keywords and related functionality.

The Enterprise Services, Remoting, and asmx data portal channels have been removed. If you need these wire transport technologies you can create your own proxy and host types based on the version 3.8 code (perhaps they’ll end up in CslaContrib at some point).

The namespaces for proxy and host types that included “Silverlight” in the namespace now use the term “Mobile” instead. For example, Csla.Server.Hosts.IWcfPortal is now Csla.Server.Hosts.Mobile.IWcfPortal.

The client-side ProxyMode concept is now eliminated entirely, and you should use the same RunLocal attribute in Silverlight as you do in .NET.

All client-side DataPortal_XYZ methods in Silverlight are now different, and no longer accept a callback handler parameter. Instead, code all client-side DataPortal_XYZ methods for Silverlight just as you would for .NET.

Please direct any comments, suggestions, bug reports, or other feedback to the CSLA forums.

Most of the work Magenic does for our customers centers around enterprise app development. That’s another way of saying ‘line of business’ or LOB apps in most cases.

Most enterprise and LOB apps will never be placed into the Windows Store for deployment. They’ll typically be deployed from corporate servers to the devices (tablets, ultrabooks, laptops, desktops) of employees. In the mobile world this is called “side-loading”, but that’s just jargon for deploying apps without using a public store.

The process for Windows RT (ARM devices) seems to be more polished than for Intel devices, and that is rather strange. But still, Intel devices can be enabled to side-load apps via domain policy or a command line script.

The important thing to understand is that you can side-load enterprise or LOB apps to all editions of Windows 8.

As I’ve said before, if you want to write Windows apps that can run on any Win8 device, you should be targeting WinRT as your development platform.