The final release of CSLA 4 version 4.5.20 is now available for download

http://www.cslanet.com/Download.html

It is also available via NuGet.

CSLA .NET is a software development framework that helps you build a powerful, maintainable business logic layer for WinRT (Windows 8), WPF, Web, service-oriented, Windows Phone, Silverlight, and workflow applications.

This new release adds support for Windows Phone 8 to the existing support for .NET 4, .NET 4.5, Windows Runtime (WinRT), and Silverlight 5.

It also includes some important bug fixes, and relatively minor enhancements in other areas of the framework. So if you are using any previous version of 4.5 you really should upgrade to this new release to realize these benefits.

One other note: this release uses a new WIX-based installer, and so it shouldn’t have the issues people encountered with the InstallShield-based installer used in the previous release. As always, I generally recommend using NuGet to include the assemblies in your projects, as that’s the simplest and most reliable approach.

First: CSLA .NET has moved to GitHub and has a new home page: www.cslanet.com

Second, the most recent beta version 4.5.12, is now available for download and through nuget. There are a couple bug fixes, and some server-side data portal enhancements to better support the use of IoC containers for creating business objects when using the encapsulated data portal model.

In summary, you can create an implementation of Csla.Server.IDataPortalInterceptor where you can implement code that runs at the very start and very end of every single data portal call. Then you can create an implementation of Csla.Server.IDataPortalActivator where you can assume responsibility for creating an instance of the requested business type, and for initializing the object instance (thus supporting property injection).

Along with this, the data portal now allows you to use interfaces instead of concrete types (assuming you've supplied an IDataPortalActivator of course):

var obj = Csla.DataPortal.FetchAsync<IPersonEdit>();

In this example, the 'obj' reference might be any type that implements IPersonEdit, and the actual concrete type is determined by your IDataPortalActivator implementation. The default implementation is to create an instance of the supplied type, so the supplied type must be a concrete type. As a result, no existing code is affected by this change.

In a recent email thread I ended up writing a lengthy bit of content summarizing some of my thoughts around the idea of automatically projecting js code into an HTML 5 (h5js) browser app.

Another participant in the thread mentioned that he’s a strong proponent of separation of concerns, and in particular keeping the “model” separate from data access. In his context the “model” is basically a set of data container or DTO objects. My response:

-----------------------------

I agree about separation of concerns at the lower levels.

I am a firm believer in domain focused business objects though. In the use of “real” OOD, which largely eliminates the need for add-on hacks like a viewmodel.

In other words, apps should have clearly defined logical layers. I use this model:

Interface
Interface control
Business
Data access
Data storage

This model works for pretty much everything: web apps, smart client apps, service apps, workflow tasks (apps), etc.

The key is that the business layer consists of honest-to-god real life business domain objects. These are designed using OOD so they reflect the requirements of the user scenario, not the database design.

If you have data-centric objects, they’ll live in the Data access layer. And that’s pretty common when using any ORM or something like EF, where the tools help you create data-centric types. That’s very useful – then all you need to do is use object:object mapping (OOM) to get the data from the data-centric objects into the more meaningful business domain objects.

At no point should any layer talk to the database other than the Data access layer. And at no point should the Interface/Interface control layers interact with anything except the Business layer.

Given all that, the question with smart client web apps (as I’ve taken to calling these weird h5js/.NET hybrids) is whether you are using a service-oriented architecture or an n-tier architecture. This choice must be made _first_ because it impacts every other decision.

The service-oriented approach says you are creating a system composed of multiple apps. In our discussion this would be the smart client h5js app and the server-side service app. SOA mandates that these apps don’t trust each other, and that they communicate through loosely coupled and clearly defined interface contracts. That allows the apps to version independently. And the lack of trust means that data flowing from the consuming app (h5js) to the service app isn’t trusted – which makes sense given how easy it is to hack anything running in the browser. In this world each app should (imo) consist of a series of layers such as those I mentioned earlier.

The n-tier approach says you are creating one app with multiple layers, and those layers might be deployed on different physical tiers. Because this is one app, the layers can and should have reasonable levels of trust between them. As a result you shouldn’t feel the need to re-run business logic just because the data flowed from one layer/tier to another (completely different from SOA).

N-tier can be challenging because you typically have to decide where to physically put the business layer: on the client to give the user a rich and interactive experience, or on the server for more control and easier maintenance. In the case of my CSLA .NET framework I embraced the concept of _mobile objects_ where the business layer literally runs on the client AND on the server, allowing you to easily run business logic where most appropriate. Sadly this requires that the same code can actually run on the client and server, which isn’t the case when the client and server are disparate platforms (e.g. h5js and .NET).

This idea of projecting server-side business domain objects into the client fits naturally into the n-tier world. This has been an area of deep discussion for months within the CSLA dev team – how to make it practical to translate the rich domain business behaviors into js without imposing a major burden of writing js alongside C#.

CSLA objects have a very rich set of rules and behaviors that ideally would be automatically projected into a js business layer for use by the smart client h5js Interface and Interface control layers. I love this idea – but the trick is to make it possible such that there’s not a major new burden for developers.

This idea of projecting server-side business domain objects into the client is a less natural fit for a service-oriented system, because there’s a clear and obvious level of coupling between the service app and the h5js app (given that parts of the h5js app literally generate based on the service app). I’m not sure this is a total roadblock, but you have to go into this recognizing that such an approach compromises the primary purpose of SOA, which is loose coupling between the apps in the system…

I have released a beta of CSLA .NET: version 4.5.11, working toward a final release in a few weeks.

CSLA .NET is an open source software development framework that helps you build a reusable, scalable, and maintainable object-oriented business layer for your applications.

This update includes a few interesting features/changes.

1. Adds support for Windows Phone 8 (WP8) development on the Windows Phone Runtime (WinPRT) platform
2. Simplifies support for ASP.NET MVC 3 and ASP.NET MVC 4, as well as ADO.NET EF 4 and 5 by splitting functionality into separate assemblies and nuget packages
3. Changes the local data portal to have the same behavior as a remote data portal for async calls; specifically this means that the local data portal automatically shifts all async requests onto a background thread from the thread pool
4. Transactional attribute now allows you to set the isolation level
5. Various bug fixes

You can get this prerelease version from nuget in Visual Studio, or you can download the new Wix-based installer from the CSLA download page.

I am pleased to announce the final release of CSLA 4 version 4.5 with support for the following platforms:

• .NET 4.5
• Windows Runtime (WinRT)
• .NET 4
• Silverlight 5

The new release is available via nuget and the CSLA download page.

This release includes a number of important features and changes, including:

• Support for Windows Runtime (WinRT), so you can simply recompile your existing CSLA .NET business classes for WinRT with little or no changes required to migrate to the new platform
• Support for the new async and await keywords in .NET 4.5 (and in .NET 4 and SL5 via the async targeting pack)
• Enhancements to the business rules engine
• Enhancements to Windows Forms support via the Csla.Windows namespace

The entire CSLA .NET dev team has put a lot of work into this release, and we hope you enjoy it and find it useful!

CSLA 4 version 4.5 release candidate 1 is now online via installer and nuget.

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.

My plan is to release version 4.5 by the middle of next week.

CSLA 4 version 4.5 supports the async and await keywords across all platforms (WinRT, .NET 4.5, .NET 4, Silverlight 5).

You can use these async features to implement async rules in the CSLA rules engine. Here’s one such rule:

public class CustomRule : Csla.Rules.BusinessRule
{
  public CustomRule(Csla.Core.IPropertyInfo primaryProperty)
    : base(primaryProperty)
  {
    InputProperties.Add(primaryProperty);
    IsAsync = true;
  }

  protected async override void Execute(Csla.Rules.RuleContext context)
  {
    var cmd = new LongRunningCommand();
    cmd = await DataPortal.ExecuteAsync(cmd);
    context.AddInformationResult("Rule complete: " + cmd.Output);
    context.Complete();
  }

  [Serializable]
  public class LongRunningCommand : CommandBase<LongRunningCommand>
  {
    public static readonly PropertyInfo<string> OutputProperty = RegisterProperty<string>(c => c.Output);
    public string Output
    {
      get { return ReadProperty(OutputProperty); }
      private set { LoadProperty(OutputProperty, value); }
    }

    protected new async Task DataPortal_Execute()
    {
      Output = "Before delay";
      await Task.Delay(3000);
      Output = "After delay";
    }
  }
}

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:

<StackPanel Orientation="Horizontal">
  <TextBox Text="{Binding Path=Name, Mode=TwoWay}"/>
  <TextBlock Text="{Binding ElementName=NameInfo,Path=RuleDescription}" Foreground="Yellow"/>
  <ProgressRing IsActive="{Binding ElementName=NameInfo,Path=IsBusy}"/>
  <csla:PropertyInfo Name="NameInfo" Source="{Binding}" Property="Name"/>
</StackPanel>

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 have put CSLA 4 version 4.5 beta 2 online as we continue toward the planned final release of version 4.5 on or before Oct 26.

Version 4.5.3 is available via nuget and from the CSLA download page.

The change log contains a list of all changes. Highlights include:

1. Substantial changes to CslaActionExtender for Windows Forms
2. Substantial (and some breaking) changes to pre- and post-processing methods around the data portal
3. Added the ability to global implement pre- and post-processing handler to server-side data portal to enable logging/tracing and IoC scenarios

At this point we are feature complete, so any releases between now and final release will be bug fixes or stabilization.

Version 4.5 supports the following platforms:

• .NET 4 (with async targeting pack)
• Silverlight 5 (with async targeting pack)
• .NET 4.5
• WinRT

If you are using any of these platforms, please download and test this new release. Here are some notes regarding upgrading from version 4 to 4.5.

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.

1. CSLA now fully supports the new WinRT platform for Windows 8 development.
2. 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.
3. 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.
4. 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.
5. 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.
6. 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.
7. 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.
8. WinRT now includes language resources.
9. 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.

Be aware that the data portal has breaking changes, especially for Silverlight users. Some highlights of breaking changes:

• 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.

Check out the new logo graphics for CSLA 4 version 4.5!

Thank you to Sandra Fougerousse for creating these updated Windows 8 style logo graphics!

For those who are wondering, I expect to put a beta of version 4.5 online shortly after August 15 (when Windows 8 and Visual Studio 2012 final bits are available). That will start the beta cycle, with a planned release of version 4.5 around the end of October (if not sooner). I’m very exited to get CSLA .NET for WinRT into the hands of app developers!

I want to summarize some of the more major changes coming to the data portal in CSLA 4 version 4.5. Some of these are breaking changes.

I’ve done four big things with the data portal:

1. Added support for the new async/await keywords on the client and server
2. Merged the .NET and Silverlight data portal implementations into a single code base that is now common across WinRT, .NET, and Silverlight
3. Removed the public virtual DataPortal_XYZ method definitions from Silverlight, because it can now invoke non-public methods just like in .NET. Also, all local Silverlight data portal methods no longer accept the async callback handler, because they now support the async/await pattern
4. Remove the ProxyMode concept from the Silverlight data portal, because the RunLocal attribute is now available on all platforms

All four have some level of breaking change.

Adding comprehensive support for async/await changes the way .NET handles exceptions. Although I’ve worked to keep the top level exceptions consistent, the actual exception object graph (nested InnerExceptions) will almost certainly be different now.

Merging the .NET and Silverlight data portal implementations introduces a number of relatively minor breaking changes for Silverlight users. Though if you’ve created custom proxy/host pairs or other more advanced scenarios you might be more affected than others. There may also be unintended side-effects to .NET users. Some might be bugs, others might be necessary to achieve platform unification.

Removing the public virtual DataPortal_XYZ methods from BusinessBase and BusinessListBase will break anyone using the local Silverlight data portal. The fix is minor – just change the public scopes to protected. This change shouldn’t affect anyone using .NET, or using a remote data portal from Silverlight.

Removing the async callback parameter from all Silverlight client-side DataPortal_XYZ methods will break anyone using the local Silverlight data portal. The fix is to switch to the new async/await pattern. The code changes are relatively minor, and generally simplify your code, but if you’ve made extensive use of the client-side data portal in Silverlight this will be a pretty big change I’m afraid.

Similarly, removing the ProxyMode concept from the Silverlight data portal is a breaking change for people using the local Silverlight data portal. Again, the fix is pretty simple – just add the RunLocal attribute to the DataPortal_XYZ (or object factory) methods as you have always done in .NET.

On the upside, the coding patterns for writing code in .NET, WinRT, and Silverlight are now the same.

For example, a DataPortal_Fetch method on any platform looks like this:

private void DataPortal_Fetch(int id)

or like this

private async Task DataPortal_Fetch(int id)

The data portal will automatically detect if your method returns a Task and it will await the method, allowing you to use the await keyword inside your DataPortal_XYZ methods.

Similarly, all platforms can now write this client-side code:

var obj = await CustomerEdit.GetCustomerAsync(123);

or the older event-style code:

CustomerEdit.GetCustomer(123, (o, e) =>
  {
      if (e.Error != null)
          throw e.Error;
     else
          obj = e.Object;
  });

Only .NET code can use the synchronous approach:

var obj = CustomerEdit.GetCustomer(123);

This is one of the few platform-specific concepts left in the data portal.

What is really cool is that the client and server sync/async concepts can be mixed (as long as you know what to expect).

I expect all client-side data portal code to switch to the async/await versions of the methods, and so I’ve made them the mainline path through the data portal. The synchronous and event-based async methods use async/await techniques behind the scenes to do implement the desired behaviors.

There is a lot of variety in how you can invoke an awaitable method like FetchAsync. The specific async behaviors you should expect will vary depending on how you invoke the method. For example, there’s a big difference between using the await keyword or the Result or RunSynchronously methods:

var obj = await CustomerEdit.GetCustomerAsync(123);

var obj = CustomerEdit.GetCustomerAsync(123).Result;

The former is async, the latter is sync. The former will return a simple exception (if one occurs), the latter will return an AggregateException containing the simple exception. This has little to do with CSLA, and nearly everything to do with the way the async/await and task parallel library (TPL) are implemented by .NET.

Finally, I do need to state that the actual network transport (typically WCF) used by .NET, Silverlight, and WinRT aren’t the same. This is because WCF in .NET is far more flexible than in Silverlight or WinRT. And because the WCF client-side proxies generated for Silverlight use event-driven async methods, and in WinRT the proxy is task-based.

The data portal hides these differences pretty effectively, but you should understand that they exist, and as a result there may be subtle behavioral differences between platforms, especially when it comes to exceptions and exception details. The success paths for creating, fetching, updating, and deleting objects are identical, but there may be edge cases where differences exist.

All in all I am quite pleased with how this is turning out. I’ve put a massive amount of work into the data portal for 4.5, especially around unifying the implementations across platforms. I suspect there’ll be some issues to work through during the beta testing phase, but the end result is a far more consistent, maintainable, and streamlined codebase for all platforms. That will benefit all of us over time.

I have put an early version of CSLA 4 version 4.5 (version 4.5.1) online. This is a stable alpha release that supports:

• Microsoft .NET 4.5
• WinRT Metro style apps on Windows 8
• Silverlight 5

You can get it from the CSLA download page.

This version doesn’t currently support Windows Phone, mono, or Android because all work is being done using Visual Studio 2012. We’ll reintroduce support for those platforms as everything gets supported on VS12.

• This 4.5 release has the same functionality as version 4.3.12, plus some functionality we’ve added only to 4.5. Most notably:
• The .NET and WinRT data portal now supports the new async/await keywords through methods like CreateAsync and SaveAsync
      var obj = Csla.DataPortal.FetchAsync<CustomerEdit>(id);
• The ViewModelBase class for WPF and WinRT now has an InitAsync method so you can await initialization of the viewmodel object
      var vm = await new MyViewModel().InitAsync();
• Enhancements to business rule processing

See the 4.5 change log for more detail.

Because this is an alpha release, you should expect more changes as we improve support for .NET 4.5 (most notably ASP.NET Web Forms, MVC, and Web API), and for WinRT/Metro.

At the same time, this should be a reasonably stable release, especially on .NET where the platform is also stable. It is also reasonably stable on WinRT/Metro, though there are more changes involved there so there could be more bugs.

Please direct feedback to the CSLA forums.

The final release of a CSLA 4 update is now available (version 4.3.12) .

You can get it from the CSLA download page or via nuget.

One cool thing with nuget, is that (thanks to work by Johann Hough) the debug symbols are now available on a symbol server. This means you can step through the CSLA code while debugging if desired (and if you deployed CSLA to your project via nuget).

This release is an update to the previous version 4.3 that includes several bug fixes and a few new features. Most notably:

• Fixed a concurrency bug with the data portal
• Fixed a XAML data binding bug with the PropertyInfo control
• Substantial bug fixes and enhancements to the Windows Forms CslaActionExtender control
• Better exception messages when methods/properties can’t be found

There are others as well – see the change log for details.

A beta release of a CSLA 4 version 4.3 update is now available (version 4.3.11) .

You can get it from the CSLA download page.

This is an update to the existing version 4.3 code that includes several bug fixes and a few new features. Most notably:

• Fixed a concurrency bug with the data portal
• Fixed a XAML data binding bug with the PropertyInfo control
• Substantial bug fixes and enhancements to the Windows Forms CslaActionExtender control
• Better exception messages when methods/properties can’t be found

There are others as well – see the change log for details.

I expect the beta period to last about two weeks, followed by a final release of this 4.3 update.

I’ve been spending quite a bit of time working with WinRT over the past couple weeks. Specifically prepping for next week’s Visual Studio Live! and VS Connections conferences.

As part of this process, I have a super early version of CSLA 4 version 4.5 that builds and (mostly) runs on WinRT. I’d done a lot of the work months ago when the Windows 8 developer preview came out, so getting it to work on the consumer preview took only a couple hours.

The only new feature I’ve added so far is support for the new async and await keywords for WinRT data portal code. I still need to add async/await support for the .NET data portal. I might refine some of my implementation, but right now I can use async/await to call the data portal in WinRT, and that’s cool!

The primary observation I want to make right now though, is that business classes created using CSLA 4 that target Silverlight will now recompile for WinRT with no code changes required. I took the entire ProjectTracker business library project and just recompiled it for WinRT and it works – unchanged.

If you want direct reuse of your business logic from .NET/Silverlight to WinRT, you should consider using CSLA 4.

Because I did add the async/await data portal support, I chose to add async factory methods to my business classes, alongside the existing .NET and Silverlight factory methods. From a porting/reuse perspective this is not necessary, but in terms of writing new code for .NET 4.5 and/or WinRT I think we’ll all tend to write these async factory methods.

In short, I added code like this:

#if WINRT
    public async static System.Threading.Tasks.Task<ProjectList> GetProjectListAsync()
    {
      return await Csla.DataPortal.FetchAsync<ProjectTracker.Library.ProjectList>();
    }
#endif

This allows the viewmodel or other presentation layer code to retrieve business objects like this:

var obj = await ProjectList.GetProjectListAsync();

No need for async callback handlers or the other messy goo from a typical WPF/Silverlight application. Of course WPF 4.5 will be able to use the await keyword too, so only SL/WP7 will still require the callback handler model when all is said and done.

Although these are early days, and I am still working through all the features of CSLA .NET to make sure they work on WinRT, it is nice to know that data binding, business/validation rules, and the data portal are all functional already. I expect to still do some work around authorization rules, and the local data portal implementation – but the vast majority of CSLA 4 functionality is already working just fine on WinRT and that makes me very happy!

At a time when many organizations are moving from Windows XP or 2000 to Windows 7, the last thing a lot of people want to think about is Windows 8. At the same time, it is incredibly clear that the future of client computing is undergoing a major shift thanks to the rapid growth of iPad and other tablet devices. Windows 8 is not only the next desktop operating system from Microsoft, but it is also Microsoft’s answer to this substantial shift toward low-power touch-based client devices.

This change impacts not only the operating system, but the underlying application development model. The new Windows Runtime (WinRT) development platform represents an evolution for .NET developers, and a significant shift for non-.NET developers.

Realistically, enterprises should expect two things. First, the enterprise desktop/laptop platform will most likely continue its shift to Windows 7, and may remain on Windows 7 for many years. Second, the enterprise is already forced to deal with iPad and other tablet devices, and they’ll need to deal with (or embrace) Windows 8 tablets in the same way.

To the first point, I think it unlikely that most organizations will roll out Windows 8 on a broad scale to desktops or laptops. Most organizations are just now moving from XP/2000 to Windows 7, only because those ancient operating systems will soon be entirely unsupported. It is not realistic to think that organizations will immediately move from Windows 7 to Windows 8. It is more realistic to think that they’ll be on Windows 7 for 5-10 years, and will then move to “Windows 11” or something along that line.

As a result, organizations will be building and maintaining applications using Microsoft .NET (WPF, Silverlight, Windows Forms) for many years to come. There is no WinRT for Windows 7, so that new development platform will be off limits for mainstream enterprise application development targeting the desktop/laptop space in the foreseeable future.

To the second point, the reality that end users in organizations will acquire and use tablets on their own, if not supplied by the organization, is already happening. The flood gates are open, and organizations are now left to deal with the results. A chaotic landscape composed of iPads, random incompatible Android devices, and soon Windows 8 devices.

This is where things get interesting. Windows 8 on Intel devices can run the same .NET applications as a desktop or laptop. They can also run WinRT applications, which (when built using .NET) are extremely similar to Silverlight applications. Windows 8 on ARM devices will only run WinRT applications.

iPad and Android devices require completely different application development using tools unlike .NET. No code or functionality sharing between existing .NET desktop/laptop applications and these platforms is possible. Truly embracing these platforms means building up duplicate development staff for Objective C and Java, or switching entirely away from traditional smart client development to a pure HTML5 model. Sadly, HTML5 isn’t compatible across all these devices either, so even that isn’t an obvious solution.

In reality, it might be less expensive for organizations to buy employees Windows 8 tablets than to pay developers to re-implement applications across multiple platforms, and to then support those multiple implementations over time. In fact, I suspect it will almost always be cheaper to spring for a few Windows 8 tablets than to pay for duplicate software development and maintenance forever.

To achieve the broadest reach, Windows 8 apps should target WinRT. That allows the apps to run on Intel and ARM devices. As I mentioned earlier, when using .NET to build WinRT applications, the development model is very similar to Silverlight. This means that existing WPF and Silverlight developers will have a relatively easy time shifting to WinRT, and substantial amounts of Silverlight application code will often just work on WinRT.

Frameworks such as CSLA .NET provide even more cross-platform compatibility. For example, the business logic code for applications written using CSLA 4 that target Silverlight will just recompile for WinRT, usually with no changes required at all. The vast majority of business logic from WPF or Windows Forms applications written using CSLA 4 will also just recompile for WinRT.

In summary, Windows 8 represents a major factor in enterprise application development strategy. In the short term, it might offer a lower-cost way to get users onto tablets without the high cost of duplicate software development, or dealing with the cross-platform HTML5 issues. In the long term, WinRT appears to be Microsoft’s new strategic development platform, so organizations need to be considering how to move to this platform over a period of years.

I am pleased to announce the release of CSLA 4 version 4.3. It is available from the CSLA download page and from nuget.

This release adds support for Silverlight 5.

Silverlight 4 is still supported. The assemblies are in a Silverlight4.zip file in the bin folder created by the setup program in your Program Files folder or other install location.

Other major enhancements include:

• New binary serialization scheme for MobileFormatter resulting in substantially smaller data flowing across the data portal from Silverlight and Windows Phone client applications. The ProjectTracker sample application has been updated to use this new scheme – look at the app server web.config and the SilverlightUI and WpUI app.xaml.cs files to see how the client and server configuration is handled.
• Numerous enhancements to the business rules subsystem. See the change log for more information.
• Bug fixes to address some specific data portal issues. See the change log for more information.
• CommandBase now supports managed properties.

With this version, CSLA 4 now supports the following platforms:

• Microsoft .NET 4
• Windows Forms
• ASP.NET Web Forms
• ASP.NET asmx services
• WPF
• WCF services
• ASP.NET MVC 3
• Silverlight 5
• Silverlight 4
• Windows Phone 7.5
• Mono
• OS X
• Linux
• Mono for Android

The source code also includes a version of CSLA 4 that builds for WinRT (Windows 8) Consumer Preview. This is largely untested, but does demonstrate that existing business classes (especially those built for 3- and 4-tier deployments in Silverlight) can be simply recompiled for use in WinRT applications. Consider this a preview of CSLA 4 version 4.5, coming later this year with support for .NET 4.5 and WinRT.

A beta release of CSLA 4 version 4.3 is now available from here:

www.lhotka.net/cslanet/download.aspx

The big change in this beta release is that the Silverlight projects are now bound to Silverlight 5.

I plan to write a document describing how to undo the very few changes required to support Silverlight 5, so if you want to back-port the code for Silverlight 4 you'll be able to do so on your own. This document will be available within the next couple weeks - before the 4.3 release.

The really big change came in the previous alpha release: MobileFormatter now allows much more efficient creation of the serialized byte stream, resulting in much smaller amounts of data sent over the network between a Silverlight/Windows Phone client and an app server. This same technology will be used in the WinRT codebase as well.

My plan is to release 4.3 on or before Feb 29.

That will allow us to branch 4.3 in svn so the primary codebase can focus on version 4.5 with support for .NET 4.5 and WinRT.

The 4.3 release will go into maintenance mode - meaning we'll address bugs, but don't plan any more feature changes.

I have posted an alpha version of CSLA 4 version 4.3.0 for download from the CSLA download page.

Although Jonny has been extremely busy with a number of bug fixes and some feature changes, I think the biggest change in this alpha release is a major optimization of the MobileFormatter.

MobileFormatter is used to serialize object graphs on Silverlight and Windows Phone. It is used by the data portal, and n-level undo (if you use that feature).

Until now, I have recommended that you use compression on the byte stream that flows over the data portal, because the XML created by the MobileFormatter is often quite large. It compresses efficiently, and we’re quite efficient about what we put into the byte stream, but it is just plain big.

Sergey did some really nice work for version 4.3, allowing the use of alternate reader/writer objects so the data can be serialized into something other than XML. Specifically, he created binary reader and writer objects that are around 70% more efficient in terms of byte stream size. That’s about as much as you could expect to get with compression!

The result is that you can probably avoid the CPU intensive overhead of compression and still get a small byte stream to transfer over the network.

The CSLA 4 version 4.3.0 change log includes a discussion of the configuration settings you need to change to use the new reader/writer objects.

This is a non-breaking change, because the default is the same behavior as in 4.2. But this is a big change and we really appreciate your help in testing the new reader/writer objects to ensure they work across a wide range of applications.

I am pleased to announce that the Using CSLA 4: Windows Phone ebook is now available for purchase.

If you purchased the Using CSLA 4 ebook series you already own the book, and can download it now.

This ebook (in PDF format) demonstrates how to create a Windows Phone 7 (WP7) application that uses a business layer created using CSLA 4. This ebook also demonstrates the use of the MVVM (Model-View-ViewModel) design pattern in a way that is very complementary to the capabilities provided by CSLA .NET business objects, resulting in an application that is easy to build and maintain with clear separation of concerns between the XAML-based view, the interface control code in the viewmodel and the model composed of CSLA-based business objects. This ebook also makes use of the open-source Bxf MVVM UI framework.

The ebook includes a sample application demonstrating the concepts and techniques discussed in the book.

Here’s the high level content outline:

1. Introduction
2. Windows Phone
   1. About Silverlight
   2. Windows Phone Application Model
   3. Silverlight Navigation
   4. ApplicationBar Control
   5. Overview of XAML
3. MVVM Design Pattern and CSLA 4
   1. MVVM Design Pattern overview
   2. Bxf MVVM Framework
   3. Main Shell Implementation
   4. CSLA .NET Windows Phone features
4. Business and Data Access Layers
   1. Responsibility-driven design
   2. Domain overview and implementation
5. Application Implementation
   1. Windows Phone project setup
   2. Main shell implementation
   3. User scenarios

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.

One of the primary goals for CSLA 4 version 4.3 (the next version we’ll be creating) is to improve the performance of the MobileFormattter that is used for Silverlight and Windows Phone applications. This is made all the more important, because it will also be used in WinRT applications in the future.

Sergey (a CSLA dev team member, and Magenic colleague) has been doing some heavy research into this area, and we’d originally thought to do the changes as part of the 4.2 release. It turns out that doing a really great job of optimization will require some breaking changes – at least for people who aren’t using managed backing fields. So we are deferring the bigger changes until 4.3.

In the meantime, Sergey has blogged about how to improve performance of MobileFormatter in 3.8 and 4 (4.0, 4.1, or 4.2). These are changes you can make to your CSLA codebase now if you want some of the performance benefits without waiting for the “big change” that’ll come in 4.3.

Disclaimer: I know nothing. The following is (hopefully) well educated speculation on my part. Time will tell whether I’m right.

I really like Silverlight. I’ve been a strong proponent of Silverlight since 2007 when I rushed to port CSLA .NET to the new platform.

In fact, Magenic provided me with a dev and test team to make that transition happen, because we all saw the amazing potential of Silverlight.

And it has been a good few years.

But let’s face reality. Microsoft has invested who-knows-how-much money to build WinRT, and no matter how you look at it, WinRT is the replacement for Win32. That means all the stuff that runs on Win32 is “dead”. This includes Silverlight, Windows Forms, WPF, console apps – everything.

(this is partially in answer to Mary-Jo’s article on Silverlight 5)

I wouldn’t be surprised if Silverlight 5 was the last version. I also wouldn’t be surprised if .NET 4.5 was the last version for the Win32 client, and that future versions of .NET were released for servers and Azure only.

Before you panic though, remember that VB6 has been “dead” for well over a decade. It died at the PDC in 1999, along with COM. But you still use VB6 and/or COM? Or at least you know organizations who do? How can that be when it is dead??

That’s my point. “dead” isn’t really dead.

Just how long do you think people (like me and you) will continue to run Win32-based operating systems and applications? At least 10 years, and many will probably run 15-20 years into the future. This is the rate of change that exists in the corporate world. At least that’s been my observation for the past couple decades.

Microsoft supports their technologies for 10 years after a final release. So even if SL5 is the end (and they haven’t said it is), that gives us 10 years of supported Silverlight usage. The same for the other various .NET and Win32 technologies.

That’s plenty of time for Microsoft to get WinRT mature, and to allow us to migrate to that platform over a period of years.

I don’t expect WinRT 1.0 (the Windows 8 version) to be capable of replacing Win32 or .NET. I rather expect it to be pretty crippled in many respects. Much like VB 1.0 (and 2.0), .NET 1.0 and 1.1, Silverlight 1 and 2, etc.

But Windows 9 or Windows 10 (WinRT 2.0 or 3.0) should be quite capable of replacing Win32 and .NET and Silverlight.

If we assume Win8 comes out in 2012, and that Microsoft does a forced march release of 9 and 10 every two years, that means 2016 will give us WinRT 3.0. And if we hold to the basic truism that Microsoft always gets it right on their third release, that’ll be the one to target.

I think it is also reasonable to expect that Win9 and Win10 will probably continue to have the “blue side” (see my Windows 8 dev platform post), meaning Win32, .NET, and Silverlight will continue to be released and therefore supported over that time. They may not change over that time, but they’ll be there, and they’ll be supported – or so goes my theory.

This means that in 2016 the clock might really start for migration from Win32/.NET/Silverlight to WinRT.

Yes, I expect that a lot of us will build things for WinRT sooner than 2016. I certainly hope so, because it looks like a lot of fun!

But from a corporate perspective, where things move so slowly, this is probably good news. Certain apps can be ported sooner, but big and important apps can move slowly over time.

What to do in the meantime? Between now and 2016?

Focus on XAML, and on n-tier or SOA async server access as architectural models.

Or focus on HTML 5 (soon to be HTML 6 fwiw, and possibly HTML 7 by 2016 for all we know).

I’m focusing on XAML, creating a CSLA 4 version 4.5 release that supports .NET 4.5 on servers, Azure, Windows (Win32), and Windows (WinRT). And Silverlight 5 of course.

In fact, the plan is for a version 4.3 release to support Silverlight 5, then version 4.5 with support for .NET 4.5 and WinRT.

I suspect that you can use Silverlight or WPF as a bridge to WinRT. The real key is architecture.

1. An n-tier architecture is fine, as long as the data access layer is running on a server, and the client uses async calls to interact with the server. WinRT requires a lot of async, at a minimum all server interactions. Silverlight forces you to adopt this architecture already, so it is a natural fit. WPF doesn’t force the issue, but you can choose to do “the right thing”.
2. You can also build your client applications to be “edge applications” – on the edge of a service-oriented system. This is a less mature technology area, and it is more costly. But it is also a fine architecture for environments composed of many disparate applications that need to interact as a loosely coupled system. Again, all service interactions by the edge applications (the ones running on the clients) must be async.
3. Or you can build “hybrid solutions”, where individual applications are built using n-tier architectures (with async server calls). And where some of those applications also expose service interfaces so they can participate as part of a broader service-oriented system.

I favor option 3. I don’t like to accept the cost and performance ramifications of SOA when building an application, so I’d prefer to use a faster and cheaper n-tier architecture. At the same time, many applications do need to interact with each other, and the requirement to create “application mashups” through edge applications happens from time to time. So building my n-tier applications to have dual interfaces (XAML and JSON for example) is a perfect compromise.

The direct users of my application get n-tier performance and maintainability. And the broader organization can access my slower-moving, standards-based, contractual service interface. It is the best of both worlds.

So do I care if Silverlight 5 is the last version of Silverlight?

Only if WPF continues to evolve prior to us all moving to WinRT. If WPF continues to evolve, I would expect Silverlight to, at a minimum, keep up. Otherwise Microsoft has led a lot of people down a dead-end path, and that’s a serious betrayal of trust.

But if my suspicions are correct, we won’t see anything but bug fixes for WPF or Silverlight for many years. I rather expect that these two technologies just became the next Windows Forms. You’ll notice that WinForms hasn’t had anything but bug fixes for 6 years right? The precedent is there for a UI technology to be “supported, stable, and stagnant” for a very long time, and this is my expectation for WPF/SL.

And if that’s the case, then I don’t care at all about a Silverlight 6 release. We can use WPF/SL in their current form, right up to the point that WinRT is stable and capable enough to act as a replacement for today’s Win32/.NET applications.

I have put the slides from my DevCon talks online:

• PRODEV04 – Distributed Architecture
• VS01 – Build a Mobile App with CSLA
• VS02 – Unit Testing Across Platforms

The demos I used in these talks are all part of the CSLA 4 version 4.2 download, or the related Samples download. All are on the CSLA download page.

If you would like more information about CSLA .NET, visit the Frequently Asked Questions page, or look at the ebooks and videos available from my store.

CSLA 4 version 4.2 beta 2 is now available for download on the CSLA download page.

This beta update includes a small number of bug fixes, and some enhancements:

1. The Windows Phone projects now build for WP 7.5 "Mango"
2. Csla.Xaml.PropertyInfo can now be used in a control template
3. MobileFormatter can now be used for undo/clone operations on .NET
4. Samples are now built against the 4.2 assemblies
5. Several WPF/SL samples now use PropertyInfo, and have been styled to look better (thanks Aaron!)

At this point I expect the 4.2 release to occur by the end of November. There may or may not be another beta release depending on your feedback with this beta.

With all the new terminology and conceptual surface area that comes with the OS code-named “Windows 8”, I’ve been struggling to come up with clarity as I discuss the technology. In the absence of true clarity from Microsoft, we’re left to interpret that they’ve said and come up with our own consistent terminology.

Here’s my current thinking:

• Windows 8 – the new operating system that runs in a “dual mode”: Desktop (Win32) and WinRT
• Win32 – the OS API that supports today’s applications in Win8
• WinRT – the new OS API that supports future applications
• Metro – a user experience design language often used when building WinRT applications

If I’m right, this is important, because people will ultimately be building business applications on WinRT. Those apps may or may not be strictly “Metro”, but by running on WinRT they’ll gain the benefits of the new runtime API, services, and application model.

People talk about “Metro apps”, but even in the Microsoft samples there are apps running on WinRT that violate those standards left and right. So it is extremely clear that WinRT apps might or might not be “Metro”.

Additionally, it seems pretty reasonable to think about building Silverlight or WPF apps, even today, following the Metro standards. Some of that might require a lot of work (at least until third party control vendors create some new components for us), but it is surely possible.

So you could argue that "Metro apps” might transcend WinRT. In fact, Metro is also used to describe Windows Phone apps, and they are mostly written in Silverlight.

So I think there are “WinRT apps”, and this includes any/all apps written on the WinRT API.

Then there are “Metro apps” that are probably a WinRT app, that also follows the Metro user experience guidelines.

This terminology helps a lot when talking about .NET, present and future.

Right now, today, we have some flavors of .NET:

• .NET Full profile
• .NET Client profile
• Silverlight
• Windows Phone

It seems to me that Windows 8 just adds a new option:

• .NET WinRT profile

As I think about the future of CSLA .NET, for example, this is how I approach the issue. We’ve already put in a lot of work to make the framework support the existing flavors of .NET (plus mono, mono for iOS, and mono for Android). Much of that effort lays the necessary groundwork for also supporting this new WinRT flavor of .NET.

This past weekend Magenic hosted a CSLA .NET Code Mastery event. A full day of free training on CSLA 4. It was a great time, and we had a room full of wonderful attendees. The content from the event is now online:

• Download the Atlanta Code Mastery content

Watch for more Magenic events in the future! (www.magenic.com)

Agenda from this past event:

1. CSLA .NET intro - Rocky Lhotka

Topic will give attendees a high level overview of CSLA as an application framework. Key moving parts of CSLA will be covered, along with answering the most important question: Why use CSLA? Roles of business objects, data portal, rules, authentication and authorization will be covered in principal.

2. Business object design - Eric Blackwell

Session will concentrate of best practices for designing business objects. Single responsibility principal and maintainability will be covered in light of using CSLA. Key aspects of good CSLA business layer will be covered in detail, including properties, rules, data portal, data access, business method and validation. Particular attention will be paid to structuring classes and relationship between classes. Designing based on use cases will be an important aspect of the session.

3. Business, validation, and authorization rules - Tim Price-Williams

This session will be a deep dive into the world or rules. Topics such as validation rules, user authentication and authorization will be covered. Distinction between validation and business rules be drawn. Important key scenarios will be covered, such as synchronous and asynchronous rules, client / server rules, object creation and save scenario from rules perspective. Custom and built-in rules be covered in detail. A pattern for typical business rule/methods will be illuminated.

4. Data portal and n-tier architecture - Rocky Lhotka

This topic will cover in details all possibilities that CSLA provides when abstracting communication channels between client and server components. Difference between local and remote data portal will be discussed. Various configuration patterns will be highlighted along with usage scenarios for each one. Multi-tier deployment as it relates to data portals will be covered, as well as using external data sources instead of CSLA data portal in client only scenarios.

5. Data access - Travis Brown

This session is all about data access technologies and how they relate to CSLA data portal access. The topic will include patterns for abstracting data access for business objects to promote maintainability. Discussion of Microsoft technologies for data access will take place as well.

6. XAML and MVVM - Sergey Barskiy

This session will concentrate on using CSLA as business layer in XAML based user interfaces. Taking Silverlight as an example, session will highlight how CSLA base classes can be used to facilitate communication between UI and business objects. Adaptability of CSLA business layer to seamlessly alter user interface based on rules be will covered. Patterns for wiring business objects for Silverlight environment will be part of the discussion.

7. ASP.NET MVC - Mitch Gordon

This session will concentrate on using CSLA as business layer in ASP.NET MVC based user interfaces. The discussion will include CSLA provided base classes that will allow developers write less code. The session will illuminate patters for maintaining authentication and authorization rules between server calls. Patterns for adapting UI based on user rights will be discussed.

There is no BackgroundWorker (BW) component in WinRT. Although that is arguably a good thing, I have CSLA .NET code that relies on this component. I can’t eliminate the BW from CSLA, because I need to continue to support .NET, Silverlight, and Windows Phone, even as I add support for WinRT.

Because .NET/SL/WP7 don’t (yet) have the async/await keywords, and WinRT doesn’t have BW, I need to come up with a solution that leaves existing code/behavior alone, and yet provides comparable behavior in WinRT.

To resolve this issue, I’ve created a BackgroundWorker type for WinRT. This type hasn’t gone through extensive testing, but it is a good start at least:

http://www.lhotka.net/cslacvs/viewvc.cgi/core/trunk/Source/Csla.WinRT/Threading/BackgroundWorkerBCL.cs

//-----------------------------------------------------------------------

// <copyright file="BackgroundWorker.cs" company="Marimer LLC">

//     Copyright (c) Marimer LLC. All rights reserved.

//     Website: http://www.lhotka.net/cslanet/

// </copyright>

// <summary>Implementation of old BCL BackgroundWorker ported to WinRT.</summary>

//-----------------------------------------------------------------------

using System;

using System.Collections.Generic;

using System.Linq;

using System.Text;

using System.Threading.Tasks;

using Windows.UI.Core;

using Windows.UI.Xaml;


namespace System.ComponentModel

{

  public class BackgroundWorker : DependencyObject

  {

    private CoreDispatcher _dispatcher;


    public BackgroundWorker()

    {

      _dispatcher = this.Dispatcher;

    }


    public void CancelAsync()

    {

      if (!WorkerSupportsCancellation)

        throw new NotSupportedException();

      CancellationPending = true;

    }


    public bool CancellationPending { get; private set; }


    public event ProgressChangedEventHandler ProgressChanged;


    public void ReportProgress(int percentProgress)

    {

      ReportProgress(percentProgress, null);

    }


    public void ReportProgress(int percentProgress, object userState)

    {

      if (ProgressChanged != null)

        _dispatcher.Invoke(CoreDispatcherPriority.Normal,

          (sender, args) =>

          {

            ProgressChanged(this,
new ProgressChangedEventArgs(percentProgress, userState));

          },

          this, null);

    }


    public bool WorkerReportsProgress { get; set; }

    public bool WorkerSupportsCancellation { get; set; }

    public bool IsBusy { get; set; }


    public event DoWorkEventHandler DoWork;

    public event RunWorkerCompletedEventHandler RunWorkerCompleted;

    protected virtual void OnRunWorkerCompleted(RunWorkerCompletedEventArgs
e)

    {

      if (RunWorkerCompleted != null)

        RunWorkerCompleted(this, e);

    }


    public void RunWorkerAsync()

    {

      RunWorkerAsync(null);

    }


    public async void RunWorkerAsync(object userState)

    {

      if (DoWork != null)

      {

        CancellationPending = false;

        IsBusy = true;

        try

        {

          var args = new DoWorkEventArgs
{ Argument = userState };

          await Task.Run(() =>

          {

            DoWork(this, args);

          });

          IsBusy = false;

          OnRunWorkerCompleted(new RunWorkerCompletedEventArgs
{ Result = args.Result });

        }

        catch (Exception ex)

        {

          IsBusy = false;

          OnRunWorkerCompleted(new RunWorkerCompletedEventArgs
{ Error = ex });

        }

      }

    }

  }


  public delegate void DoWorkEventHandler(object sender, DoWorkEventArgs e);


  public class DoWorkEventArgs : EventArgs

  {

    public DoWorkEventArgs()

    { }


    public DoWorkEventArgs(object argument)

    {

      Argument = argument;

    }


    public object Argument { get; set; }

    public bool Cancel { get; set; }

    public object Result { get; set; }

  }


  public delegate void RunWorkerCompletedEventHandler(object sender, RunWorkerCompletedEventArgs
e);


  public class RunWorkerCompletedEventArgs : EventArgs

  {

    public RunWorkerCompletedEventArgs()

    { }


    public RunWorkerCompletedEventArgs(object result, Exception error,
bool cancelled)

    {

      Result = result;

      Error = error;

      Cancelled = cancelled;

    }


    public Exception Error { get; set; }

    public object Result { get; set; }

    public bool Cancelled { get; set; }

  }

}

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.

Magenic is hosting a Code Mastery event in Atlanta on October 8, and I am one of the speakers.

This is a day of free CSLA 4 training, with content created and presented by people who use CSLA to build applications, and by people (Sergey and myself) who are instrumental in creating and maintaining the framework.

Sign up now, I suspect seats will go fast!

I have been giving quite a lot of thought to the WinRT migration path. What is the outlook for taking a Windows Forms, WPF, or Silverlight app into WinRT/Metro in Windows 8?

The amount of effort required for any given application may vary radically, depending on the architecture used when building the application, and how well that architecture was implemented in the actual code. And it is obviously important to understand how much client-side application code uses .NET features that aren’t in WinRT, or that are substantially different in WinRT.

And of course I tend to look at this from a CSLA .NET perspective   If you use CSLA 4 today, and you adhere to the architecture and coding structures recommended when using CSLA, most or all of your business layer code will probably move to WinRT without change.

So, rather simplified, and CSLA-centric, here’s a set of process flows:

Although the first decision point is “Using CSLA?”, you could replace that with “using a architecture/framework that abstracts all business, validation, authorization, data access and other application logic away from the UI, exposing a model that supports data binding and async server interactions”. Although I’m obviously biased, there are absolutely other architectures that offer the same layered abstraction to keep all business and data logic out of the presentation layer. And that’s really what’s required.

In the final analysis, if you have any business or data logic in your code-behind, or you aren’t using data binding to connect your existing UI views to some sort of business objects, you have some work ahead of you to get to that point.

Essentially all non-CSLA Windows Forms apps I’ve ever seen will require a complete rewrite. Most use DataSet objects, and therefore require total rework. And most use a lot of code-behind, and therefore require total rework. And a lot of them use numerous windows and modal dialogs, so the user workflow will require a complete rethink.

A surprising number of WPF apps are written much like Windows Forms apps, with code-behind, etc. Those apps will require much the same effort to migrate as Windows Forms. But if you’ve written your WPF app using MVVM, even without something like CSLA, and have strictly avoided code-behind, the migration probably won’t be too bad.

The big thing is that a lot of WPF apps aren’t written to assume async server interactions, and updating code to handle that can be a lot of work. WPF apps written using CSLA may already be using the async features in CSLA, and so can avoid this issue entirely. Worst case, if you are already using CSLA synchronously, the changes to move to async aren’t overwhelming.

If you have a Silverlight app, you are in the best position of anyone, because you are already using async server interaction, and can’t have made the mistake of using the DataSet. And if you are using MVVM without any code-behind your migration will probably be quite smooth.

If you are also using CSLA, then your existing business layer will probably translate to WinRT without change.

As I mentioned in a previous WinRT post, Windows 8 is years away for most organizations. At the same time, I do think that WinRT/Metro will be used for business app development.

Quite a number of people are mistakenly saying that “Silverlight is dead”, when in reality Silverlight has never been more important.

What are you going to use to build business apps in the years between now and when Win8 is available in your organization?

You might consider using the technology that appears to offer the easiest migration to WinRT… And that is Silverlight (plus MVVM and CSLA 4 ).

A number of people have asked about the future of CSLA .NET on WinRT (and Windows 8 and Metro).

(fwiw, you can always check out the CSLA roadmap to see what I’m planning)

The short answer is that (when Win8 comes out) I expect to have a CSLA 4 version 4.5 release that supports .NET 4.5, along with WinRT.

These are two different things.

.NET 4.5 builds apps that run on the Win8 desktop, not in Metro. I imagine .NET 4.5 will also support Win7, but I don’t know for sure. I was able to build the existing CSLA 4 version 4.2 code in .NET 4.5 without change. But I do expect that some changes will be required to take advantage of .NET 4.5 features.

For example, ASP.NET Web Forms is getting a major facelift in 4.5, as is ASP.NET MVC. It is reasonable to expect that CSLA will need to accommodate those changes – though the bulk of the impact should be in the Csla.Web and Csla.Web.Mvc projects.

Whether there are any interesting changes to WPF or Windows Forms is, at this point, something I haven’t explored.

WinRT is closer to Silverlight than full .NET, but it isn’t Silverlight either. I spent a couple hours this evening starting the port of CSLA 4 version 4.2 to WinRT.

1. I started with the Csla.Silverlight project, because it is closest to what will work in WinRT
2. I added the DataAnnotations implementation from Csla.Wp, because WinRT doesn’t have DataAnnotations
3. WinRT is also missing both INotifyDataErrorInfo and IDataErrorInfo – so it isn’t clear how any validation errors can be reported to the UI from a business object (I hope they have some solution)
4. I still need to add the WCF data portal service reference to the Csla.WinRT project, but it appears that the data portal is essentially the same as in SL

What remains are a couple relatively big issues that require some research:

1. The BackgroundWorker component doesn’t exist in WinRT, and we’ll need to either rewrite it or switch everything to the new async/await model
2. The .NET Type type is quite different in WinRT, so a lot of MethodCaller code needs to be changed to use the new WinRT type system

The MethodCaller issue is, I suspect, just a matter of learning and using the new type system. But this reveals an interesting fact: anyone using System.Reflection in their code (even for simple things) is probably going to need to make changes to move to WinRT.

The BackgroundWorker issue is more interesting. At first glance it seems obvious that we’d want to move to the async/await model. And I would – except that this model doesn’t exist in .NET 4, Silverlight 4, Silverlight 5, WP7, or WP7.5.

Silverlight 5 and WP7.5 are the challenges here, because they’ll be widely used concurrently with .NET 4.5 and WinRT over a period of months or years.

1. If we require the use of async/await, then CSLA 4.5 could not support SL 5 or WP7.5 (this violates one of the key value statements of CSLA .NET)
2. If we use async/await in .NET/WinRT, then you can’t have compatible object code between .NET/WinRT and SL/WP (this violates one of the key value statements of CSLA .NET)
3. If we re-implement BackgroundWorker in WinRT, then CSLA and your business code is unaffected, but you won’t be able to use async/await when you interact with the async data portal or async business rules
4. If we support the use of async/await on .NET/WinRT, but also support BackgroundWorker then you get to choose whether to write cross-compatible code, or code that works on 4.5/WinRT only

Clearly options 1 and 2 won’t work. So we have to explore re-implementing BackgroundWorker in WinRT. Presumably we’ll use async/await inside our BackgroundWorker replacement, but we’ll keep the external interface consistent. I hope this is possible – I’m just thinking out loud at this point.

In the medium timeframe option 4 has to be the goal. In the long run I think it is safe to assume that some future version of SL and some future version of Windows Phone will support async/await. When all the then-current Microsoft platforms support the model we’ll drop BackgroundWorker entirely.

Regardless, I am quite pleased by just how far I was able to get in just a couple hours work. I have the Csla.WinRT project structure in place, and have narrowed down the problem areas to:

1. We need some validation error notification model to replace IDEI and INDEI
2. We need a BackgroundWorker replacement
3. We need a MethodCaller update

When you think about the breadth of scope of the CSLA 4 framework, I’m pretty amazed that we only have three problem areas to address for the core framework.

We’ll also need to create a Csla.Xaml.WinRT assembly with some UI helpers (that’s probably how we’ll solve the validation error issue for example). I haven’t explored how much of the existing Csla.Xaml concepts will carry forward – but I suspect Csla.Xaml.WinRT will be very much like the existing Csla.Xaml.Wp project.

The final draft of the Using CSLA 4: ASP.NET MVC ebook is now online, and available for purchase.

If you own the Using CSLA 4 ebook series, you already own this new ebook and can download it from http://download.lhotka.net/Default.aspx?t=UsingCsla4.

If you are buying the ebooks individually, the new book is now available for purchase from http://store.lhotka.net.

This ebook also includes a code download, containing the latest ProjectTracker codebase. This includes the Mvc3UI project: an ASP.NET MVC 3 application built using the CSLA .NET business layer.

I am pleased to announce that the Using CSLA 4: Data Portal Configuration ebook is available for purchase in draft form.

Owners of the Using CSLA 4 ebook series can also download the updated ebook draft.

This ebook (141 pages in PDF format) covers the use of the CSLA 4 data portal technology, which enables flexible n-tier deployments of your applications in 1-, 2-, 3- and 4-tier physical configurations. The ebook covers the use of the data portal in .NET smart client, Silverlight, WP7, and ASP.NET web applications.

The ebook also covers the authentication techniques supported by CSLA .NET, including Windows integrated domain or Active Directory authentication, the use of the ASP.NET MembershipProvider model and custom authentication against your own security data store.

The ebook includes a complete set of sample applications demonstrating the concepts and techniques discussed in the book.

Here is a high level list of the content in this ebook:

1. Data Portal Deployment
   1. Data portal concepts
   2. Deployment options
   3. Using the local channel
   4. Using the WCF channel
   5. 4-tier Silverlight and WP7 deployment
2. Data portal configuration reference
3. Serialization
   1. .NET serialization
   2. MobileFormatter
4. Custom data portal proxies
   1. Supporting multiple application servers
   2. Dynamically switching between online and offline mode
5. Authentication models
   1. Custom authentication
   2. ASP.NET membership authentication
   3. Windows authentication

Dunn training will be holding their next CSLA training class in Atlanta, June 21-23.

If you are gearing up to use CSLA .NET and want some solid classroom training to get started, this is the way to go!

I have been working on the Using CSLA 4: Data Portal Configuration ebook, part of the Using CSLA 4 ebook series. One section of the book covers the use of Windows Azure as the application server, where the server-side components of the CSLA .NET data portal and your application will run.

Perhaps the most interesting part of that section of the ebook is that there’s no meaningful difference between hosting in Windows Azure and hosting in IIS on an on-premise Windows Server. In fact, the only difference at all is that the project in Visual Studio is an Azure ASP.NET Web Role project instead of an Empty ASP.NET web project.

This is because Windows Azure allows WCF services to host in a web role in the same way IIS hosts WCF services. When using the WCF data portal channel, the server components are accessed through a standard WCF endpoint – nothing special or fancy. That means any place you can host WCF, you can host the data portal.

In my example solution, there’s also a Silverlight client app. It is part of that same Web Role app, so a user simply navigates to the web page in Azure that hosts the Silverlight app. The Silverlight app runs on the client, and uses the data portal to interact with the server-side components of the application running in Azure.

There is some potential value to hosting the data portal (your application server) in Windows Azure.

There’s the obvious scalability benefit. Because the data portal is stateless, and typical server-side business code in a CSLA application is also stateless, there is no problem with just adding more web role instances to the app. If more capacity is required on the server, just change the Azure configuration and just like that you have more capacity.

The business code running in Azure typically implements persistence. Another value of running the application server in Azure is that the application can store its data in SQL Azure. Pretty comparable to SQL Server, but based in the cloud. In that way, the entire app can be cloud-based, with the Silverlight client using client-side CPU and memory resources, while the rest of the app scales happily in Azure.

Alternately, the application could store its data in Azure Storage. That isn’t a relational data store, but does offer some interesting super-scaling capabilities that may be quite valuable.

In the end, perhaps the most notable thing to consider is this: when building an application using CSLA and the data portal, it is entirely possible to switch between hosting in IIS to hosting in Azure, and back again, without changing anything except the application configuration.

Sure, if you use Azure-specific features in your business code (like Azure Storage), you can’t easily move off Azure. But if you stick with SQL Server or SQL Azure, and avoid Azure Storage, the .NET Service Bus, and other Azure-specific constructs, CSLA can help you build an app that can exploit Azure, without being locked into Azure forever.

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

Dunn Training is offering their CSLA 4 training class on April 11-13. The location is Atlanta.

Here’s a quote from their last class: "The willingness of our trainer to discuss how the material applied to our specific applications and situations allowed me to get an extraordinary amount of knowledge that I could put to real use immediately after taking the CSLA 4 training class."

This is a great class, so if you are looking for training on CSLA .NET, you should take a look at this opportunity.

The full draft of the Using CSLA 4: Data Access ebook is now online and available for individual purchase.

If you purchase, or have purchased, the Using CSLA 4 ebook series, you can also download this new ebook, because it is part of the series.

This 214 page ebook (in PDF format) covers the four data access models supported by CSLA .NET, focusing on the two models that provide the best maintainability and flexibility without incurring undo complexity.

The book walks through each business object stereotype, demonstrating how to implement the encapsulated invoke and factory implementation data portal models. It also demonstrates the use of ADO.NET, ADO.NET Entity Framework, and mock database access technologies.

The book includes several sample applications that provide complete implementations of persistence to accompany the concepts and techniques discussed in the book.

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 will be showcasing CSLA 4 at the Open Source Fest at MIX11. That’s Monday evening, April 11.

If you are attending MIX please stop by and say hello, it should be a good time!

Bxf and CSLA .NET both include a TriggerAction control. This control helps support the MVVM design pattern in WPF, Silverlight, and WP7 applications.

(Bxf is completely independent from CSLA – I donated TriggerAction from CSLA to the Bxf project a while back though, so this type is available from either framework)

The specific problem addressed by TriggerAction is the need to invoke a verb (method/command) on your viewmodel object in response to any arbitrary UI event. One common UI event is something like a button click event, though you can often use commanding in that case. But there are numerous other UI events from many controls other than buttons, and you might want to have one of those UI events cause the viewmodel to perform an action.

TriggerAction basically wires arbitrary UI events to methods on the current DataContext (usually the viewmodel object).

<bxf:TriggerAction TargetControl="{Binding ElementName=MyControl}"
                                           TriggerEvent="MouseOver"
                                           DataContext="{Binding Source={StaticResource vm}}"
                                           MethodName="MyAction" />

TriggerAction listens for the trigger event from the TargetControl. When it handles that event, it invokes the specified method (MethodName) on its current DataContext object. There’s nothing more to it.

To get TriggerAction working you need two things: source and target.

Source:

1. TargetControl must be set
2. TriggerEvent may be set (default is “Click”)

Target:

1. DataContext must be set (or inherited from the container)
2. MethodName must be set

Parameter (optional):

1. MethodParameter may be set (to a value or binding expression)
2. RebindParameterDynamically may be set to true (to force rebinding of MethodParameter to work around issues with certain control properties such as ListBox.SelectedItems)

The most common causes of failure when using TriggerAction are that the TargetControl isn’t set right, or the DataContext isn’t set right, and of those two the most common is that the DataContext isn’t what you think it is (that happens to me all the time).

The method TriggerAction invokes on the DataContext object can accept either 0 or 2 parameters:

public void MyAction()

or

public void MyAction(object sender, ExecuteEventArgs e)

The ExecuteEventArgs class is also defined in Bxf and CSLA. If you use TriggerAction from Bxf.Xaml, you must use ExecuteEventArgs from Bxf.Xaml. If you use TriggerAction from Csla.Xaml, you must use ExecuteEventArgs from Csla.Xaml.

If you are using Bxf and CSLA together it is important to understand that the ViewModel<T> class from Csla.Xaml uses the Csla.Xaml.ExecuteEventArgs type. If you are using the Bxf TriggerAction control, you’ll need to create your own viewmodel types from Csla.Xaml.ViewModelBase<T> to accept the Bxf.Xaml.ExecuteEventArgs type.

CSLA 4 is now available through NuGet, the package installer for .NET products.

• CSLA 4 on NuGet

This is thanks to Johann Hough (jaans on the CSLA forum) - thank you Johann!

The following packages are available:

• Core
• ASP.NET
• ASP.NET MVC
• Silverlight
• WPF
• Windows Phone
• Windows Forms

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.

I am pleased to announce the release of CSLA .NET version 4.1 with support for .NET, Silverlight and Windows Phone 7 (WP7).

You can download CSLA 4 version 4.1 at http://www.lhotka.net/cslanet/download.aspx

Although there are numerous new features in version 4.1, the primary focus of this release is Windows Phone 7. With CSLA 4 version 4.1 you can now author business classes that run unchanged across the entire .NET platform:

• Windows Phone 7
• Silverlight
• WPF
• ASP.NET MVC
• ASP.NET Web Forms
• WCF services (SOAP and REST)
• asmx web services
• Windows Forms

The ability to reuse your business layer on .NET, Silverlight and WP7 is incredibly powerful, enabling you to extend your application to users on Windows, the web, and now the phone.

You can learn how to use CSLA 4 to build scalable, flexible, and maintainable applications through the Using CSLA 4 ebook series. This ebook series is currently a work in progress and will be finished in the first half of 2011.

Dunn Training is offering a CSLA 4 training class on February 23, 2011 in Atlanta.

http://www.dunntraining.com/training/schedule.htm

If you are looking for CSLA .NET classroom training, this is a great opportunity. Here’s a quote from a student who attended the December class:

“Dunn’s CSLA training was phenomenal!!! It significantly advanced our team’s knowledge of CSLA and helped layout the roadmap for our future development. Mark Berry  holistically demonstrated how CSLA works with MVVM, Silverlight, WPF, Expression, OO Programming and Code Generators. He also successfully answered extremely challenging CSLA questions that were thrown at him during class. Our team is pretty knowledgeable with CSLA and the other technologies, but Mark took us to an entirely new level, sprinkled in some nice tips, tied it all together, and reenergized our team. The training was well worth the money.”

The completed first draft of the Using CSLA 4: Creating Business Objects ebook is now online and available for purchase.

If you’ve purchased (or now purchase) the Using CSLA 4 ebook series you’ll also have access to this new ebook.

This is book 2 of the series. The next book will be Using CSLA 4: Data Access, followed by Using CSLA 4: Security. These first four ebooks cover all the core concepts around using CSLA 4 to build your business layer, along with various options for building a data access layer and implementing authentication.

After these four are complete I’ll move on to ebooks covering how to use a CSLA .NET business layer to create applications with different types of UI, including Silverlight, WPF, ASP.NET MVC and Windows Phone 7 (WP7).

Here’s the top-level outline of the Creating Business Objects book’s contents:

1. Introduction

2. Key Object Concepts

1. Stereotypes

2. Serialization

3. Object Lifetime

4. Object Relationships

5. Object Identity and Equality

6. Platform Differences in .NET and Silverlight

7. Property Declarations

8. Method Declarations

9. Metastate

1. Project Types and Assembly References

2. Combining Project to Create Solutions

1. Editable Objects

2. Read-Only Objects

3. Execution Objects

4. Criteria Objects

5. LINQ Types

6. Windows Forms Types

1. Business and Validation Rules

2. Authorization Rules

For those who are wondering, the first ebook is almost through the editing process and the “draft” designation will then be removed.

I just put CSLA 4 version 4.1 beta 2 online for download. This is probably the last beta release of version 4.1, so please download and try it – I appreciate any help I can get in testing these releases.

http://www.lhotka.net/cslanet/download.aspx

The primary changes in beta 2 include:

1. Added a new Csla.Xaml.PropertyInfo control for WP7, WPF and Silverlight that is like PropertyStatus but totally non-visual. See the Samples\NET\cs\SimpleNTier solution’s WP7 UI project for an example of how this works
2. Created a copy of the DataAnnotations functionality for WP7; this is a nice concept that Microsoft didn’t put into WP7, so I ported the parts of System.ComponentModel.DataAnnotations required by CSLA .NET, so if you have classes using DataAnnotations attributes in .NET or Silverlight, that code will now work in WP7 as well
3. Laying the groundwork for a NuGet installer when 4.1 is released, so people will be able to download and install CSLA 4 via NuGet (thanks Jaans!)
4. Laying the groundwork for a vsix installer for Visual Studio templates, so when 4.1 is released we can add this to the Visual Studio gallery (thanks Jonny!)

I’ve also put an updated draft of Using CSLA 4: Creating Business Objects online at http://download.lhotka.net/Default.aspx?t=UsingCsla4

This ebook is incomplete, but I’m providing work-in-progress drops of the book as I work on it. People who’ve purchased the entire Using CSLA 4 ebook series (from http://store.lhotka.net/) can download this pre-draft content. This new drop includes a lot more content than the previous drop – including the entire sections on declaring and implementing properties and methods, and a good start on the metastate fields/methods available from BusinessBase and other base classes.

Finally, I also put a top level type diagram online that is available to anyone who has purchased either the Using CSLA 4: CSLA .NET Overview ebook or the entire ebook series. It is available from the same download.lhotka.net web page.

Thanks to Russ Blair, there is now a time-based index available for the entire Core 3.8 video series.

The series can be purchased from http://store.lhotka.net.