Rockford Lhotka

 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
 Friday, April 10, 2009

I’m working on a number of things at the moment. Most notably the CSLA .NET for Silverlight video series that will be available in the very near future (it turns out that creating a video series is a lot of work!). And of course I’m prepping for numerous upcoming speaking engagements, and I’d love to see you at them – please come up and say hi if you get a chance.

But I’m also working on some content around Microsoft Oslo, MGrammar and related concepts. To do this, I’m creating a prototype “MCsla” language (DSL) that allows the creation of CSLA .NET business objects (and more) with very concise syntax. I’ll probably be blogging about this a bit over the next couple weeks, but the goal is to end up with some in-depth content that really walks through everything in detail.

My goal is for the prototype to handle CSLA editable root objects, but covers business rules, validation rules and per-type and per-property authorization rules. Here’s a conceptual example:

Object foo
    // per-type authz
    Allow Create ("Admin");
    Allow Edit ("Admin", "Clerk" );

    // property definitions

    Public ReadOnly int Id;

    Public Integer Value {
       // per-property authz
       Allow Write ("Clerk" );
       // business/validation rules
       Rule MinValue (1 );
       Rule MaxValue (50 );

But what I’ve realized as I’ve gotten further into this, is that I made a tactical error.

A lot of people, including myself, have been viewing MGrammar as a way to create a DSL that is really a front-end to a code generator. My friend Justin Chase has done a lot of very cool work in this space, and he’s not alone.

But it turns out that if you want to really leverage Microsoft Oslo and not just MGrammar, then this is not about creating a code generator. And what I’m finding is that starting with the DSL is a terrible mistake!

In fact, the idea behind MOslo is that the DSL is just a way to get metadata into the Oslo repository. And you can use other techniques to get metadata into the repository as well, including the graphical “Quadrant” tool.

But my next question, and I’m guessing yours too, is that if all we do is put metadata into the repository, what good is that???

This is where a runtime comes into play. A runtime is a program that reads the metadata from the repository and basically executes the metadata.

I always had a mental picture of MOslo “projecting” the metadata into the runtime. But that’s not accurate. It is the runtime that “pulls” metadata from the repository and then uses it.

And that’s OK. The point is that the runtime is this application that interprets/compiles/uses/consumes the metadata to end up with something that actually does some work.


What I’m learning through this process, is that the DSL exists to service the metadata in the repository. But it is the runtime that defines the metadata. The runtime consumes the metadata, so the metadata exists to serve the needs of the runtime.

In other words, I should have started with the runtime first so I knew what metadata was required, so I could design a DSL that was capable of expressing and capturing that metadata.

The example MCsla code you see above is OK, but it turns out that it is missing some important bits of information that my runtime needs to function. So while the DSL expresses the important CSLA .NET concepts, it doesn’t express everything necessary to generate a useful runtime result…

So at the moment I’ve stopped working on the DSL, and am focusing on creating a working runtime. One that can execute the metadata in a way that the user gets a dynamically created UI (in WPF) that is bound to a dynamically created CSLA .NET business object, that leverages a dynamically created data access layer (using the CSLA .NET 3.6 ObjectFactory concept). I’m not dynamically creating the database, because I think that’s unrealistic in any real-world scenario. We all have pre-existing databases after all.

Once I get the runtime working (and it is close – here’s a screenshot of a simple object, showing how the dynamic WPF UI is running against an object with business rules, buttons bound to the CslaDataProvider through commanding and all the other nice CSLA features.


Not that my UI is a work of art, but still :)

I have a lot more to do, but it is now clear that starting with the runtime makes a lot more sense than starting with the DSL.

Friday, April 10, 2009 9:30:07 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, April 9, 2009

VS Live Las Vegas is coming up soon, and as a speaker I am able to provide a special discount code – kind of a perk for you reading my blog I guess :)


If you register for VS Live using code S9V03 you’ll get the all-access passport package for $400 off the standard price.

The conference has great content for developers, covering core .NET, VSTS/TFS, Silverlight, WPF, ASP.NET, Azure, Oslo and more. VS Live is one of the most respected independent technical conferences in the Microsoft space.

I’ll be talking about parallel and concurrent programming (from a practical, real-world perspective), techniques you can use to deal with the rapid pace of change in technology, and giving a workshop on building distributed applications using .NET 3.5 SP1 (so WPF, Silverlight, WCF, Windows Workflow – and of course a liberal dose of CSLA .NET).

As a nice bonus, the conference has a block of rooms at the Venetian Hotel for $99/night. This is one of the nicest hotels in Vegas, and normally you couldn’t touch a room for anywhere near this rate!

Thursday, April 9, 2009 5:17:42 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, April 7, 2009

Leveraging the Multi-Core Revolution

April 21, 11:00 PT, 1:00 CT, 2:00 ET
CPU Speeds are not doubling every 18 months anymore. Are we stuck? Not at all! Learn how you can increase your processing speed using systems, languages, and tools. We will cover how functional development techniques can deliver a competitive advantage to companies who are smart enough to see these changes coming. read more ...


Planning for Successful Outsourcing

April 30, 11:00 PT, 1:00 CT, 2:00 ET
Outsourcing is a popular strategy for decreasing the cost of supporting and maintaining business applications. Done right, it can be a successful strategy. Join Magenic as we discuss and dissect why outsourcing has gained the attention and approval of business and IT managers and how to navigate a pain-free transition.  read more ...

Tuesday, April 7, 2009 2:09:47 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, March 31, 2009

CSLA .NET 3.6.2 is now available for download.

This is the second point release of CSLA .NET 3.6, and it includes a number of bug fixes, but more importantly there are a number of new features and enhancements based on feedback from users of version 3.6 over the past four months.

Highlights include:

  • For both Windows and Silverlight
    • New methods on the ObjectFactory base class to better enable creation of a DAL object
    • Better support for lazy loaded fields, where an exception is thrown if the field is mis-used accidentally (thus reducing bugs)
    • ErrorDialog control for WPF and Silverlight to enable XAML-only handling of exceptions from CslaDataProvider
    • CslaDataProvider now has a Saved event to simplify some UI scenarios
    • RegisterProperty() now accepts a lambda expression to identify the property name, allowing the compiler to check the name, and avoiding the use of the string literal
    • MobileDictionary type, so you can create a dictionary that serializes between Silverlight and .NET
  • For Silverlight only
    • Better type name resolution, so you can now specify a type by "Namespace.Class, Assembly" without supplying the generic "Version=..." text
    • New InventoryDemo sample project (C# only right now - it is a work in progress)
    • Code snippets for async factory and data access methods

    On a related note, the first segment of my CSLA .NET for Silverlight video series is complete, and I’m nearly done with the web infrastructure for the download site. You can get a summary of the video series content on the CSLA .NET for Silverlight video download page.

    Once I get the store and download site complete, you’ll be able to purchase “early adopter'” access to the series – which means you’ll get access to each video segment as soon as it comes online. Look for this in the next couple weeks!

    Tuesday, March 31, 2009 3:59:43 PM (Central Standard Time, UTC-06:00)  #    Disclaimer