Rockford Lhotka

 Wednesday, May 27, 2009

Since WPF came out there’s been one quirk, one “optimization” in data binding that has been a serious pain.

Interestingly enough the same quirk is in Windows Forms, but the WPF team tells me that the reason it is also in WPF is entirely independent from how and why it is in Windows Forms.

The “optimization” is that when a user changes a value in the UI, say in a TextBox, that value is then put into the underlying source object’s property (whatever property is bound to the Text property of the TextBox). If the source object changes the value in the setter the change will never appear in the UI. Even if the setter raises PropertyChanged, WPF ignores it and leaves the original (bad) value in the UI.

To overcome this, you’ve had to put a ValueConverter on every binding expression in WPF. In CSLA .NET I created an IdentityConverter, which is a value converter that does nothing, so you can safely attach a converter to a binding when you really didn’t want a converter there at all, but you were forced into it to overcome this WPF data binding quirk.

WPF 4.0 fixes the issue. Karl Shifflett describes the change very nicely in this blog post.

This should mean that I can remove the (rather silly) IdentityConverter class from CSLA .NET 4.0, and that makes me happy.

Wednesday, May 27, 2009 9:28:10 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, May 26, 2009

I have put a beta release of version 3.6.3 online for download. This version is now feature complete, and my plan is to release it around the next of next week. I'll only be changing this version for show stopping issues, otherwise this is the final code.

If you are using 3.6.x, you should download and test this version. There are important bug fixes in this version - please see the change logs for details. If you are developing Silverlight, WPF or Windows Forms applications (in particular), you'll almost certainly want some of these fixes!

There are minor new features as well, including

  • Named connections in the GetManager methods for ConnectionManager and similar types
  • ReadProperty() method in the ObjectFactory base class

But the primary focus is on fixing bugs and refining key usage scenarios.

Tuesday, May 26, 2009 11:41:52 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, May 19, 2009

I decided to try using Visual Studio 2010 Beta 1 to open CSLA .NET for Windows 3.6.3.

Unfortunately this isn’t as smooth as one would hope.

VS runs an upgrade wizard on the solution, but this breaks the project file. I had to manually edit the project file using notepad to remove a bunch of stuff in the configuration. How did I know what to remove? I created a brand new Class Library project for .NET 4.0 and compared the contents of that file to the Csla file…

Now that I could open the solution I figured it would just build. Unfortunately not.

Two references were broken: System.ComponentModel.dll and System.Runtime.Serialization.dll. Perhaps the project references them by version number, I’m not sure. I do know that the references were broken, so I removed and re-added the references to these files.

Next is an issue with the web service reference required for the old asmx data portal channel. I suspect the issue is that I need to update (or remove and re-add) the service reference to the web services host. But I am not entirely sure it is worth carrying this legacy channel forward (or the Remoting or Enterprise Services ones) into CSLA .NET 4.0 – WCF is the preferred solution after all, and it has been around for a few years. So at least for now I just removed the service reference, the web service proxy class in Csla.DataPortalClient and the web service host class in Csla.Server.Hosts.

The result is that the solution builds. I haven’t tried running (or building) the unit test project yet, and I suspect there’ll be a few issues there as well, but at least the basic build of Csla.dll is now possible.

Tuesday, May 19, 2009 10:34:55 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 18, 2009
 Tuesday, May 5, 2009

We interrupt the normal technical content of this blog to bring you an important news flash.

The Star Trek movie is awesome!!

Through a fortuitous accident, I and my sons were able to see a pre-screening of the movie this evening. We literally snuck in at the last minute.

I am a long-time trekkie. I love TOS and ST:TNG (with the usual caveats). DS9 was a sad rip-off of Babylon 5, Voyager was “Star Trek does Space 1999”, and Enterprise got good only after it was canceled (the last half-season was totally on track). And really I’m not really going to talk about the movies. Khan was great, and IV was fun, otherwise not so much…

So having watched the universe and characters I loved so much slowly dwindle and fade into utter drivel over the past many years, I had serious reservations about this new movie. Of course it is hard to imagine they could do more damage to the Star Trek universe, so I suppose there was nothing really to lose either.

On the upside, my hope was that this movie would do for Star Trek what the new Doctor Who did for that show, or the new Battlestar Galactica did for that show. There is evidence that the beloved content of my youth, when handled by competent, respectful and loving hands, can be given new and often better life now, with today’s special effects.

And my hope has been realized.

This movie treats the characters, the universe and the overall content and setting with respect. They took the setting and characters and breathed new life into them – capturing the humor, the interplay, the drive – the very essence of the original concept – and they created a movie for me.

A movie for the little kid who sat three feet in front of my Grandfather’s TV (because we didn’t get that channel at my house). But a movie for the person I am today, remembering what it was like to be that kid. Just like the new Doctor Who and BSG shows did with their original inspiration.

It has been many, many years since the words “These are the voyages of the starship Enterprise…” had the power to send chills up my spine. To make me smile, and to think that the future really is bright and wonderful.

At the end of this movie, when Leonard Nimoy speaks these words I felt these things like I did so many years ago, sitting on my Grandfather’s floor.

Tuesday, May 5, 2009 8:43:15 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 4, 2009

In working on MCsla I have learned quite a few things. Obviously I had to learn the ins and outs of MGrammar, MSchema, MGraph and the various related command line tools. But that’s not really the interesting part, because that sort of knowledge is specific to a bunch of unreleased tools and so is transitory.

What is more interesting is learning about the process of building a runtime that works off metadata. Which leads to learning about what metadata is needed for a runtime. Which leads to learning about how you get that metadata – where it comes from.

In my simplistic worldview I thought I’d create a single DSL to create metadata for my runtime. And this is what I’ve done in my MCsla prototype, but it really isn’t sufficient for any long-term real effort.


Because my DSL describes business objects. It doesn’t describe details about the UI, or about the data access layer (DAL) or any data mappings into the database. In my prototype I am inferring enough information from the metadata to create a basic UI, a limited DAL and some data mappings, but this is only useful for a prototype.

The conclusion I’ve come to is that any real CSLA .NET application runtime will require a number of related metadata schemes:

  1. Business object description
  2. UI description
  3. DAL description
  4. Data mapping description

If you create a single DSL to cover all these at once I think you’ll be in trouble. The trouble will come in at least two forms. First, this single DSL will almost certainly approach the complexity of C# or other 3GLs, and at that point why use a DSL at all? Second, such a DSL would almost certainly break down walls around separation of concerns. Let me talk about this second point further.

One of the primary strengths of CSLA .NET is that it encourages clear separation of concerns. The business layer supports numerous UI layers at one time – Web Forms, WPF, ASP .NET MVC, Silverlight, Windows Forms, WCF services, Workflows, etc. Similarly, the business layer doesn’t know or care how or where the DAL gets the data, as long as the DAL can provide create/read/insert/update/delete operations.

It is a virtual certainty that you’ll need a different DSL for ADO.NET EF than for raw ADO.NET (connection/command/datareader) data access layers. Similarly, you’ll probably need a different DSL to describe a web UI, as opposed to a XAML-based UI. The technology semantics are so different that it is hard to imagine a single DSL that encompasses both UI styles (at least one that is rich enough to make the end users happy).

As a result, I suspect we need a different DSL for each technology of each layer of the application architecture. And that’s OK, because it is a good bet that Microsoft will create a DSL for ADO.NET EF (as an example), so we don’t need to. That’ll probably cover at least item number 4 in my earlier list.

The role of the “DAL description DSL” is probably to map the items in the business DSL to the items in the data mapping DSL.

Already it becomes clear that some DSLs (like any DSL for ADO.NET EF, or for a framework like MCsla) will exist in their own world, for their own narrow domain. And that’s fine, because that is the point of a DSL.

And at the same time, it becomes clear that we’ll need to create cross-DSL DSLs to bridge the gaps between different DSLs. So that hypothetical “DAL description DSL” would be specific to both MCsla and the data mapping DSL.

To put it another way, it seems to me that we’re looking at two types of DSL. “Real” domain languages, and “glue” domain languages. Domain languages that target a specific domain, and domain languages that target the gap between other domain languages.

I suspect the end result, is that to create a comprehensive runtime, the runtime will need to pull in metadata for each layer of the application, and for the description on how the layers interact. And a developer will need to learn 4 or more DSLs to describe the various layers of the application. And tooling will need to evolve to validate the various inter-connected bits of DSL code so we aren’t left catching mis-matched bits of DSL input at runtime.

To summarize: this DSL/runtime stuff is very cool, but it seems to me that it will take years of maturation before everything comes together in a really productive manner.

One caveat: clearly you could limit the flexibility of the architecture/runtime and simplify the problem space and thus this multi-DSL issue. My fear though, is then you are no different from CASE and many other similar failed concepts of the past – so that seems rather uninteresting to me.

Monday, May 4, 2009 11:27:11 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

The 4th video in the CSLA .NET for Silverlight video series is now available. This is 65 minutes of in-depth content covering the creation of 2-, 3- and 4-tier applications using CSLA .NET for Silverlight.

If you’d like to get a better idea of the structure, style and quality of the video series you can download a FREE promotional montage. This promotional video includes lecture and coding content, providing an example of everything you’ll see in the full video.

The N-Tier Architecture segment covers a lot of ground, including these topics:

  1. How to share code files and objects between a Silverlight client and .NET server
  2. How to have server-only and client-only sections in your business layer
  3. How to configure an ASP.NET server for the Silverlight data portal
  4. How to configure the Silverlight client to use a remote data portal
  5. How to use the MobileFactory attribute to create an observer object to validate inbound client requests on the web server
  6. How to set up the web server to act as a "bridge", routing all client calls to a real application server behind a second firewall

Purchase the video series at

Download the content from

Buy before June 1 to take advantage of a special early adopter offer: $100 savings off the regular purchase price. That's a 33% savings!

Monday, May 4, 2009 9:04:11 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, April 22, 2009

One of the issues I’ve been struggling with in building MCsla is that the mgx tool that is used to compile a DSL into M doesn’t output valid M in all cases.

A couple of the issues are simply unsolvable (I mentioned these in my last blog post as well).

  1. If your grammar includes any Boolean values, they come out as ‘ true’ and ‘false’ (including the single quotes), when they should come out as true and false (no quotes).
  2. If your grammar includes any lists of values, a single-item list generates invalid M, while multi-item lists generate valid M (though I’m not sure you can describe the result using an MSchema – but at least the result is “valid”).

As I say, these problems are “unsolvable” because the M rendering API is what creates the bad result, and that’s a black box.

The solution, such as it is, requires taking the text output, the M code, and doing some text processing to fix the issues. In the olden days I’d have whipped up an awk script to do this, but these days C# is the tool (even if it is a lot more verbose). Here’s the code I’m using to fix the two issues – kind of a post-processor to the mgx tool:

public static class MFix
  /// <summary>
  /// Fix single-quote and single-list-item
  /// issues with a generated M file.
  /// </summary>
  /// <param name="fileName">Path to the file to fix</param>
  public static void FixFile(string fileName)
    var output = new System.Text.StringBuilder();
    File.ReadAllLines(fileName).ToList().ForEach((line) =>
    File.WriteAllText(fileName, output.ToString());

  /// <summary>
  /// Fix single-quote issue with M generated by
  /// mgx.exe.
  /// </summary>
  /// <param name="input">One line of text input.</param>
  /// <returns>Fixed line of text from input.</returns>
  private static string FixQuotes(string input)
    var sb = new System.Text.StringBuilder(input.Length);
    int state = 0;
    for (int i = 0; i < input.Length; i++)
      var sub = input.Substring(i, 1);
      if (sub == "\"")
        if (state == 0)
          state = 1;
          state = 0;
      else if (sub == "\\" && state == 1)
        if (i < input.Length - 1)
          sb.Append(input.Substring(i, 1));
      else if (sub == "'" && state == 0)
        // do nothing and eat next char if it is a ' '
        if (input.Substring(i, 1) != " ")
    return sb.ToString();

  /// <summary>
  /// Fix single element array issue with M generated by
  /// mgx.exe.
  /// </summary>
  /// <param name="input">One line of text input.</param>
  /// <returns>Fixed line of text from input.</returns>
  private static string FixSingleNode(string input)
    var trm = input.TrimStart();
    if (!trm.StartsWith("=")) return input;

    var pos = input.IndexOf("=");
    var sb = new System.Text.StringBuilder(input.Length);

    sb.Append(input.Substring(0, pos));
    sb.Append(" {");
    sb.Append(input.Substring(pos + 1, input.Length - pos - 1));
    sb.Append(" } ");

    return sb.ToString();

It is kind of ironic that I had to write a subset of an M parser to fix issues with the M generator API.

Wednesday, April 22, 2009 5:43:02 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, April 21, 2009

Working with Microsoft Oslo, the goal is to enable the creation of a domain specific language (DSL) using MGrammar, so a developer can write code in that grammar, compile the code into M and then load that M into the Oslo repository.

This is turning out to be a bigger challenge that you’d expect, though I think that’s largely because I’m dealing with such early builds of all the Oslo tools.

The tool chain for compiling DSL source into M is this:

  1. Use mg.exe to compile the MGrammar
  2. Use mgx.exe to compile the DSL source against the grammar to create M
  3. Use m.exe to compile the M
  4. Use mx.exe to load the compiled M (an mx file) into the repository

Unfortunately this breaks down at step 2, because mgx.exe has some issues.

The first issue I encountered was that mgx creates hierarchical M, not relational M. What’s the difference?

Relational M is defined by an MSchema where child entities define foreign key relationships to their parent. This is the normal model you’d find when creating any relational database.

Hierarchical M is defined by an MSchema where parent entities define relationships with their children. This is more like what you’d find in XML, and doesn’t completely map to a normal relational model. While it is true that this type of MSchema can result in valid SQL table definitions, you can’t define all the relationship restrictions you’d normally want to have in your database.

The thing is, M code itself must match the shape of the MSchema you want to use. So if you define your entities using a relational MSchema, the M must also be relational. Conversely, this means that when mgx generations hierarchical M, you must use a hierarchical MSchema to map that M metadata into your database (or the Oslo repository).

This is an unfortunate limitation, that hopefully will be resolved at some point.

The second and third issues I encountered appear to be bugs in mgx. But not just in mgx – they are bugs in the underlying API, so even if you try to write your own “mgx replacement” (which is what I’m doing btw), the API that helps you generate M will create invalid M output.

The two bugs are:

  1. When a node has a Boolean value, true comes out as ‘ true’ and false comes out as ‘ false’. The single quotes and space after the first single quote should not be there, but that’s what gets output. Oddly enough, Int32 and other primitive types work fine – just Boolean types seem to be broken.
  2. When a list of items is output, and that list contains one item, the output is invalid M. Multiple items or no items in the list work fine – just the single-item case is broken.

The only solution I’ve found for these bugs is to do a post-processing step on the resulting M – literally doing text processing to identify and fix the issues. Again, hopefully these issues get resolved in the API itself, so valid M gets produced by mgx or any other tool using the API.

The fourth issue, and the reason I’m writing my own mgx replacement, is that my MCsla grammar allows arbitrary placement of various elements, like authorization and business rules within a property:

Public string Name {
  Allow Write (“Admin”, “Supervisor”);
  Rule StringRequired;
  Deny Read (“Guest”);

Because the grammar allows arbitrary placement, the resulting M is a collection of mixed types of entity. In other words, the compiled M is effectively invalid, because the M parser can’t figure out whether the collection contains auth rules, or business rules (because it contains both).

I really have two choices – either change my grammar to put auth rules and business rules in different block structures, or at least to require one to come before the other. Or write my own mgx replacement to rearrange the nodes of the compiled DSL code into discrete collections of homogeneous types.

Since I don’t want to “ruin” my pretty grammar, I’m trying to fix the nodes by creating my own mgx replacement. And this seems quite realistic, though it doesn’t address the first three issues in any way – those are still problematic.

Tuesday, April 21, 2009 7:54:06 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, April 17, 2009

I have the first three segments of the CSLA .NET for Silverlight video series available now, and so I'm extending a special pre-purchase offer to anyone who wants to get access to the content as it becomes available.

Buy now and save $100 off the regular purchase price. This special offer gives you immediate access to the first three video segments, and will give you access to the remaining video segments as they become available. You can be among the first to have access to this great content!

You can get an idea of the video style with this promo:

Here is a summary of all seven video segments:

In this video you will become familiar with the CSLA .NET framework's vision, goals and overall scope. You will be introduced to the various architectures supported by CSLA .NET for Silverlight, and the requirements necessary to build Silverlight and CSLA .NET for Silverlight applications.

The Basics
This video details the basic steps of creating a CSLA .NET business object that interacts with a server-side web service to get its data. The process of using data binding to connect the object to the Silverlight UI is also covered. At the end of this video you will understand all the basic steps and coding structures necessary to build a simple CSLA .NET for Silverlight application.

Client-only Architectures
This video covers the various client-only scenarios supported by CSLA .NET for Silverlight, including true client-only applications and “edge” applications that interact with remote services. This video builds on The Basics to dive deeper into the various options for building client-only applications.

N-tier Architectures - coming soon
In this video you will learn how to build 2-, 3- and 4-tier applications using CSLA .NET for Silverlight. CSLA .NET allows your UI, business object and data access code to remain the same in all these configurations, but there are numerous configuration options and choices you can make to optimize how your application works in each of these scenarios.

Business Object Types - coming soon
In this video you will learn how to implement each of the business object stereotypes supported by CSLA .NET. These include editable objects, lists of objects, read-only objects, read-only lists, name/value lists, command objects and more. At the end of this video you will understand the purpose behind each stereotype, and the coding structure to use when building business objects for each stereotype.

N-tier Data Access - coming soon
This video details the various options supported by CSLA .NET for data access in n-tier scenarios. You will learn how to put data access code into your business class, or into a separate data access assembly, along with the pros and cons of each technique. You will also learn about the ObjectFactory attribute and base class, that can be used to create pluggable data access layers for an application.

Authentication and Authorization - coming soon
In this video you will learn about the various authentication and authorization techniques supported by CSLA .NET for Silverlight. Authentication options include Windows, ASP.NET Membership Provider and custom authentication. Authorization is the same as CSLA .NET for Windows, and includes per-property and per-type authorization, along with Silverlight UI controls to simplify the creation of your interface

Friday, April 17, 2009 9:03:51 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 16, 2009

Microsoft is hosting a recap of key MIX09 content in Minneapolis (really Plymouth) on May 8.

ugMIX: .NET User Group & Silverlight User Group

The really cool part? This is at a theater and everyone will get to see the new Star Trek movie after the technical content.

How cool is this??? See some cool Silverlight and other tech content, and then watch a private screening of the new movie?

And I know that a lot of local Microsoft experts will be attending as well – you know, the people that live in the area and organize our user groups, write books and do a lot of speaking. So this is also an opportunity to hang out with “people in the know” :)

See you there! Live long and prosper!

(though I still wonder if I’ll get past seeing Syler every time Spock is on screen…)

Thursday, April 16, 2009 10:08:08 AM (Central Standard Time, UTC-06:00)  #    Disclaimer