Rockford Lhotka

 Thursday, May 25, 2006

According to Bookscan (a service which tracks book sales for all sorts of books), Expert C# 2005 Business Objects is number 365 and Expert VB 2005 Business Objects is number 385 among all computer books out there. This includes consumer-oriented computer books too, so these numbers are incredibly good. Programming books have a hard time competing with consumer books for sales volume after all.

What I find most interesting is that the VB sales are comparable to the C# sales. Obviously there really is a market for higher end VB programming books, which I think validates a view I've held for a long time, that the VB community was waiting for .NET to mature before moving forward. Clearly VS 2005 is triggering a non-trivial movement of VB developers into .NET, and these are hard-core professional developers who are looking for something beyond the reference-style and tutorial style books out there.

Like I said a few months ago, in .NET 1.1 the C# book outsold the VB book rather substantially. These numbers appear to show that the dynamic is changing, and I find that quite exciting!

Thursday, May 25, 2006 2:09:19 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I have two updates for CSLA .NET for those who are interested.

CSLA .NET version 1.53 is now available from This is a minor bug fix update to 1.52.

A beta of CSLA .NET version 2.0.1 is now available from This includes fixes for a number of bugs and errata (which you can find at, as well as some minor enhancements due to unforseen limitations around areas like threading and polymorphic child objects. If you get a chance to try 2.0.1 I would appreciate it. Barring any negative feedback from the community I expect to finalize it in about a week.

Thursday, May 25, 2006 2:01:38 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Saturday, May 13, 2006

I’ve run into a spot where I’m stuck, and I’m hoping someone has an idea.


CSLA .NET 2.0 includes an ASP.NET data source control: CslaDataSource. This works well, except for one issue, which is that it doesn’t refresh the metadata for your business objects unless you close VS 2005 and reopen the IDE.


The reason for this problem is that your business assembly gets loaded into memory so the data source control can reflect against it to gather the metadata. That part works fine, but once an assembly is loaded into an AppDomain it can’t be unloaded. It is possible to unload an entire AppDomain however, and so that’s the obvious solution: load the business assembly into a temporary AppDomain.


So this is what I’m trying to do, and where I’m stuck. You see VS 2005 has a very complex way of loading assemblies into ASP.NET web projects. It actually appears to use the ASP.NET temporary file scheme to shadow the assemblies as it loads them. Each time you rebuild your solution (or a dependant assembly – like your business assembly), a new shadow directory is created.


The CslaDataSource control is loaded into the AppDomain from the first shadow directory – and from what I can tell that AppDomain never unloads, so the control is always running from that first shadow directory. And then – even if I use a temporary AppDomain – the business assembly is also loaded from that same shadow directory, even if newer ones exist.


And that’s where I’m stuck. I have no idea how to find out the current shadow directory, and even if I do odd things like hard-coding the directory, then I just get in trouble because the new AppDomain thinks it has a different Csla.dll than the AppDomain hosting the Web Forms designer.


Here’s the code that loads the Type object within the temporary AppDomain:


    public IDataSourceFieldSchema[] GetFields()


      List<ObjectFieldInfo> result =

        new List<ObjectFieldInfo>();


      System.Security.NamedPermissionSet fulltrust =

        new System.Security.NamedPermissionSet("FullTrust");

      AppDomain tempDomain = AppDomain.CreateDomain(





        new System.Security.Policy.StrongName[] { });



        // load the TypeLoader object in the temp AppDomain

        Assembly thisAssembly = Assembly.GetExecutingAssembly();

        int id = AppDomain.CurrentDomain.Id;

        TypeLoader loader =


            thisAssembly.CodeBase, typeof(TypeLoader).FullName);

        // load the business type in the temp AppDomain

        Type t = loader.GetType(

          _typeAssemblyName, _typeName);


        // load the metadata from the Type object

        if (typeof(IEnumerable).IsAssignableFrom(t))


          // this is a list so get the item type

          t = Utilities.GetChildItemType(t);


        PropertyDescriptorCollection props =


        foreach (PropertyDescriptor item in props)

          if (item.IsBrowsable)

            result.Add(new ObjectFieldInfo(item));






      return result.ToArray();



This replaces the method of the same name from ObjectViewSchema in the book.


Notice that it creates a new AppDomain and then invokes a TypeLoader class inside that AppDomain to create the Type object for the business class. The TypeLoader is a new class in Csla.dll that looks like this:


using System;

using System.Collections.Generic;

using System.Text;


namespace Csla.Web.Design


  /// <summary>

  /// Loads a Type object into the AppDomain.

  /// </summary>

  public class TypeLoader : MarshalByRefObject


    /// <summary>

    /// Returns a <see cref="Type">Type</see> object based on the

    /// assembly and type information provided.

    /// </summary>

    /// <param name="assemblyName">(Optional) Assembly name containing the type.</param>

    /// <param name="typeName">Full type name of the class.</param>

    /// <remarks></remarks>

    public Type GetType(

      string assemblyName, string typeName)


      int id = AppDomain.CurrentDomain.Id;

      return Csla.Web.CslaDataSource.GetType(

        assemblyName, typeName);





Since this object is created in the temporary AppDomain, the business assembly is loaded into that AppDomain. The Type object is [Serializable] and so is serialized back to the main AppDomain so the data source control can get the metadata as needed.


This actually all works – except that it doesn’t pick up new shadow directories as they are created.


Any ideas on how to figure out the proper shadow directory are appreciated.


Honestly, I can’t figure out how this works in general – because obviously some part of the VS designer picks up the new shadow directory and uses it – even though the designer apparently doesn’t. I am quite lost here.


To make matters worse, things operate entirely differently when a debugger is attached to VS than when not. When a debugger is attached to VS then nothing appears to pick up the new shadow directories – so I assume the debugger is interfering somehow. But it makes tracking down the issues really hard.

Saturday, May 13, 2006 12:53:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 12, 2006

I just got back from Norway (so my body has no idea what time it actually is right now...), and one of the conversations I had while there was about data binding a TextBox to an object's property that is a Nullable<T> - like Nullable(Of Integer) or something.

Somehow I had expected that Windows Forms would have anticipated this (obvious) concept and would handle it. Not so...

Fortunately, as a result of this conversation, one of the people at the conference took some of the ideas we were tossing around and came up with an extender control to address the issue. Very nice!

Friday, May 12, 2006 7:57:52 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 5, 2006

There's a new online CSLA .NET forum, hosted by Magenic Technologies, with the Community Server software provided by Telligent.

As always, the home site for CSLA .NET is, where you can find news, answers to frequently asked questions and downloads of the framework and related resources.

This forum is a replacement for - which has served the community for a number of years. Unfortunately turns out to be rather unreliable and slow, so the forum had to be moved. If you are looking for older discussions you may want to check there. Associated with that forum is, which allows you to search the archive of that older forum.

But now we've got this new forum, which will hopefully overcome some of the limitations and reliability issues of MSN - so please make good use of the forum and enjoy!

Friday, May 5, 2006 10:01:52 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, May 3, 2006

My author copies of Expert VB 2005 Business Objects arrived on my doorstep today, meaning that the book is in print and is being delivered to booksellers right now. This means it should be available on bookshelves and from online sellers very, very soon.

Wednesday, May 3, 2006 7:37:30 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

Microsoft is holding an architect contest at Tech Ed this year. Click here for details.

Wednesday, May 3, 2006 8:44:59 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, May 2, 2006

You might wonder what’s up. I go and stir the pot by saying that software development is too darn hard, and that TDD is overhyped (and broadly misunderstood) and then disappear from the conversations.


Well, so far in 2006 I completed the CSLA .NET framework (twice), finished two books, buried my last Grandmother, have been supporting my Mother through dealing with cancer (which has shut down her kidneys, so now she’s dealing with dialysis too), had the lower level of my house flood (with luck my office will be reclaimed for use late this week – at least my son has his bedroom back) and I’ve spoken at 9 events requiring travel (2 international). And things don’t look to change soon. I’m traveling 5 out of the next 7 weeks (1 international), and my Mom's chemo runs through the summer (fingers crossed).


In summary: I’ve been just a little busy, and blogging is comparatively quite low on the priority list. Certainly it falls below family, generating income and replacing carpets and walls.


It isn't that I meant to stir the pot and then disappear - but the universe decided to complicate my life in some unexpected ways. So I'm sticking my head up when I can, and I hope you understand that the frequency of my participation in any dialog is a bit restricted at the moment.


A while back I posted a blog entry suggesting that software is too hard. This was recently republished by Fawcette.


This generated a few emails from people saying that they agree; that their experience is like mine; that the process of analyzing business problems, then designing and building software to address them is fundamentally the same today as it was 15-20 years ago.


It has also generated some emails and comments from people who either disagree, or at least find the conclusion demoralizing or depressing.


Well, it was supposed to be depressing, so in that I feel quite comfortable.


Let’s face it. Most software basically collects data from users, stores that data and then displays the data back to the same, or other, users in a different format. This type of system is often called forms-over-data (or if you remember terminals it was screens-over-data, or if you are a web person maybe it is pages-over-data).


This is the software I’m saying is too darn hard. Why the hell is it so hard, does it take so much work, to create a data entry screen that dumps the data into a data store? And why can’t we just flip a switch to say we value performance over scalability, or scalability over security, or fault-tolerance over performance or whatever?


This is where I’m saying the Elvis/Einstein personas and our vendors have failed us.


In fact, I’d suggest we’re going the other way. We’re coming up with ways to further complicate the most common types of application by adding in SOA, TDD, WinFx and more.


Now let me be clear here. Most applications are mostly forms-over-data. Almost every application really does have some small bit of interesting complexity. In other words, out of perhaps 100 forms in an application, 1 or 2 might be more than simply forms-over-data. And of course, there are those precious few applications that are not forms-over-data, and you people working on those projects should consider yourselves truly fortunate!


So the problem is this: we get so wound up trying to figure out how to do that 1-2% of the application that is interesting that we complicate the hell out of the 98% that should be drop-dead trivial. We rule out tools, technologies and frameworks that could have trivialized the 98% because they can’t address the 2%. We adopt expensive methodologies to enhance productivity and/or quality because those methodologies are truly useful for that 2%. But then we apply the same ideas to the 98%, needlessly increasing the complexity and cost of something that should have taken precious little effort.


You can TDD/unit test/integration test until you are blue in the face. You can triple or quadruple the time and effort required to build a data entry form. And in the end you’ll still have a boring old data entry form. Worse yet, you can’t automate testing of the part that matters the most: the actual UI. The part that the user cares about typically remains untested until the users try it out themselves.


This is what frustrates me. See, I fully understand and support the idea that you should test the hell out of the 2% of the app that’s hard. Whether you write the tests before, during or after the development to me seems like a secondary question – but actually doing the unit and integration testing should not be optional. But I think that development of the bulk of the app, the trivial forms-over-data part, should be so automated that we don’t actually “develop” it and thus don’t need to do any sort of low-level unit testing, or probably even integration testing.


Again, let me be clear. It is this forms-over-data stuff that’s too hard. It is this stuff we’ve been building basically the same way for at least 20 years. Why? I don’t know.


This problem space isn’t that big or hard. Yet we keep rehashing it over and over and freakin’ over again. Now we’re going to rehash it with SOA and WPF, with a sprinkle of workflow just to make it really hard.


Given that we actually need to code forms-over-data, of course we feel the need to tell people to do unit testing. If you code it, you should test it. Since people struggle with the discipline to write the tests during or after development, TDD is helpful in that it (maybe) provides the discipline to write the tests first. But again, the key is that if you write it you must test it.


But what I’m saying is this: we shouldn’t code this stuff!!! Forms-over-data should be automated.


Scott Bellware saysSoftware development isn't too hard.  Software development is fun.  It's a challenge - of that there's no doubt.  And sometimes it's a tiger that won't be tamed.” And he’s right – at least in terms of that complex 2% of most applications. But no experienced developer is going to find forms-over-data “fun” after 15-20 years. And no amount of Extreme Agile anything is going to change the fact that what businesses mostly want is to have their computers store and regurgitate data.


I’m working with a client now who’s designing an application that is virtually all forms-over-data. And just like countless applications before this, more time is spent discussing the “plumbing” issues – the use of ORM, WPF, WCF, WF, ADO.NET, WinFS, ASP.NET, LINQ, Windows Forms, XHTML, Javascript, layers, tiers, patterns – than is spent discussing the business issues. You know, the whole reason for writing the damn app in the first place!


Trying to pull the client out of the alphabet soup of techno-babble that is today’s technology, so we can actually discuss the business needs and thus determine how to proceed is like pulling teeth. Books from people like Eric Evans and David West are great tools – if you can get people to step out of techno-land and into a productive level of discussion.


But then there’s that ugly 2% of the app again. Every time you talk about the truly interesting bits of the app, there’s so much worry about whether the “technology can handle it” that the conversation instantly devolves into an argument about whether the COM interop overhead in Enterprise Services will be a roadblock or some equivalent. WTF?!?


And worse. Even after you fight through that – continually bringing the dialog out of the murky depths of techno-babble and into a level where OOD is possible – the technical powers-that-be want to apply the complex technology needed for the complex parts of the app back into the trivial forms-over-data parts.


“We need consistency.” “If it can solve the hard parts, it can sure handle the easy parts.” “Someday we might need to scale higher.” “What if we want to reuse the data someday?”


So the forms-over-data must be written using overly complex technologies (for forms-over-data anyway). Thus it must be written by hand. Thus it must be tested. Thus it costs many times what it should have cost.


And the most irritating consequence? All that time and money wasted on complicating the forms-over-data reduces the amount of time and money available to address the parts of the app that are actually hard, or interesting – or fun.



Just over 20 years ago I was an intern for a summer while in college/university. The IT director told me in no uncertain terms that I was wasting my time getting a degree in Computer Science. “They’ve got this new thing called CASE” she said. “In a few years anyone will be able to program computers.”


Her presupposition was that CASE would actually trivialize software development to the point that “normal people” (presumably business analysts) would be able to create applications. Obviously that didn’t happen, much to my relief.


But it does make me wonder why there’s so much excitement around Software Factories and DSLs, since they look terribly close to CASE… Perhaps, lurking deep in the bowels of the Software Factory concept, there’s some differentiating factor that will allow it to succeed where CASE merely limped along to a slow, agonizing death.


I hope so. Because it seems to me that Software Factories and/or DSLs are the only area of technology active today that might address the fact that software (at least the forms-over-data majority) is too darn hard to build.


Maybe, just maybe, forms-over-data will be automated by some of these Software Factory ideas, so we can just slap out that 98% of the application and spend our time on the fun parts: that interesting and truly complex 2%.


In the meantime, I’ve got to get back to designing a 3D rotating, infinitely scalable form to enter customer data (to keep the user from losing interest in their dead-end data entry job, and in case the company quadruples in size every month for the next decade)…

Tuesday, May 2, 2006 2:16:42 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 1, 2006

One of the most important "features" of CSLA .NET is the vibrant community that surrounds it. I am humbled by, and very appreciative of, the amount of time and effort people put into this community - helping other people more effectively learn and use the concepts from my books.

The most recent examples? Updates to several of the major community contributions for CSLA .NET 2.0:

Permanent links to these contributions are, along with general errata and other information, at the CSLA .NET 2.0 home page:

Monday, May 1, 2006 7:21:14 AM (Central Standard Time, UTC-06:00)  #    Disclaimer