Rockford Lhotka

 Friday, August 7, 2009

Welcome to the August edition of our Webinar Schedule!
We are pleased to introduce a series of exciting new webinars! For the month of August, we offer webinars on what Metrics Every Performance Testing Engagement Should Provide to Ensure Application Stability and on how to use SharePoint for Extranets. In collaboration with the Chicago Technology Executives Club, we are offering Business Dashboards - Developing a Culture of Intelligent Execution with Magenic's Dan English. In September, we begin a 5-part series on Silverlight Application Migration with Rocky Lhotka, Corey Miller, and Anthony Handley. We will cover the topics, Why Silverlight?, Windows to Silverlight, Web to Silverlight, Reimagining the UI in SIlverlight, and Silverlight: Service-oriented vs. n-tier. We are excited for you to attend these educational, cutting-edge webinars from our experts!

Magenic Webinars are complimentary and are designed as a resource for IT decision makers. Learn from our experts and have your questions ready for the Q&A at the end of each presentation. Register now for these exciting webinars!

Thursday, August 20th, 11:00 PT, 1:00 CT, 2:00 ET
Do you know how your application will perform when you go live?  Performance Testing will simulate how your application will perform with real life scenarios, enabling you to find and fix performance issues prior to launch. This will enable you eliminate risk and potential system down time, such as your customers not being able to access your website. This presentation will help guide you through the initiation, planning, and execution phases of your Performance Testing Engagement.

Thursday, August 27th, 11:00 PT, 1:00 CT, 2:00 ET
SharePoint 2007 seems to be everywhere. This webinar will offer a perspective on the key issues involved in leveraging the SharePoint platform for Extranets. Topics will include an overview and common pitfalls related to: Security, Authentication & Authorization, Architecture, Search, and Content Management.


We are excited to introduce our 5-part Silverlight Application Migration series beginning in September. Rocky Lhotka, Corey Miller, and Anthony Handley will be presenting this series. Click the picture above for full descriptions of each webinar and registration for the entire series or the webinars of your choice.

Wednesday, August 26th, 10:00 PT, 12:00 CT, 1:00 ET
In the current economic climate, it is more important than ever for business stakeholders to have a pulse on what is happening in their organization. Implementing an Executive Dashboard allows an organization to more effectively and efficiently execute on strategy, improve business processes and manage key company metrics proactively. This webinar is presented by Magenic's Dan English in conjunction with the Chicago Technology Executives Club.


Magenic Delivery Center About Us Careers Events



Friday, August 7, 2009 12:20:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, August 4, 2009

CSLA .NET 3.6 introduced the InvokeMethod component for Silverlight, which was intended to replace at least the basic WPF commanding functionality I tend to use to trigger actions on a CslaDataProvider when buttons are clicked. And it did that.

It turns out however, that with a few tweaks, InvokeMethod is much more broadly useful than just triggering actions on a CslaDataProvider. In a more general sense, InvokeMethod can be used to call a method on nearly any object in response to nearly any event being raised by a UI control.

I’ve been reworking InvokeMethod quite a bit over the past few days, and whatever I end up doing will be in CSLA .NET 3.8. And it will be a breaking change over the 3.6 and 3.7 functionality, which is unfortunate, but I think it is worth it.

This blog post is not the final word, just kind of a “state of the control” post to solicit thoughts and feedback as I work on version 3.8.

In the new model, InvokeMethod can still invoke methods on a CslaDataProvider, so no functionality is lost.

But in the new model, InvokeMethod can invoke methods on other arbitrary objects, as long as they can be described through a binding expression. In other words, any bindable object that has a method becomes a valid target. And the range of trigger events is much broader; in fact any event should now work, though I’ve only tested a handful of common events (click, doubleclick, selectionchanged, etc).

Using some data binding trickery I’ve made the Target property (used to be the Resource property) optional. If you don’t set the Target property, InvokeMethod will target the DataContext of the control to which it is attached. This is not so useful with a data provider model, but is very useful with a ViewModel model.

Simple scenario

So an example of triggering an action on a ViewModel when a button is clicked:

<Button Content="Refresh"
        csla:InvokeMethod.MethodName="Load" />

When the button is clicked a Load() method is invoked on the current DataContext, which is probably a ViewModel class with a Load() method:

public class DataListViewModel : CslaViewModel<DataList>
  public void Load()

That’s the simplest example, and could be handled by commanding in WPF.

ListBox doubleclick scenario

A more interesting example is where the UI needs to do something in response to a doubleclick of an item in a ListBox. This is interesting because there’s a temporal issue where the user could select an item in the list, and not doubleclick on it ever, or for a long time. In my mind, the ViewModel would handle the doubleclick through a method that accepts the selected item as a parameter:

public void ProcessItem(Data item)

That implies that InvokeMethod can pass the selected item as a parameter, and in the current incarnation it can do this:

         ItemsSource="{Binding Path=Model}"
         ItemTemplate="{StaticResource DataList}"
         csla:InvokeMethod.MethodParameter="{Binding SelectedItem, RelativeSource={RelativeSource Self}}"/>

The ambient DataContext here is the ViewModel object, and you can see that the ListBox loads its items from the Model property (where the Model is a collection of Data objects). The only really interesting thing here is that the MethodParameter property is using binding to pick up the SelectedItem property from the UI control – so from the ListBox. This directly meets my requirement of being able to pass the selected item to the ViewModel method.

The ViewModel doesn’t care what type of UI control is used, as long as it gets a selected Data item. This also means the ViewModel is quite testable, because it is a simple method that accepts a strongly typed parameter.

MultiSelect ListBox scenario

This even works with a multiselect ListBox control (though my solution seems a bit messy).

Obviously this requires a Button or some other control outside the ListBox, since a multiselect ListBox doesn’t raise events quite the same way. The user gets to select arbitrary items in the ListBox, then click a Button to trigger processing of all selected items.

The ViewModel has a method to handle this:

public void ProcessItems(ObservableCollection<object> items)

And the XAML invokes this method from the Button (assuming the ListBox has an explicit name):

<Button Content="Process items"
        csla:InvokeMethod.MethodParameter="{Binding ElementName=DataListBox, Path=SelectedItems}"/>

Again, the ViewModel just accepts a (relatively) strongly typed parameter, not caring about the type of UI control that generated that value. There’s no real type-level coupling between the XAML and the ViewModel.

In all these cases the XAML knows nothing more than that there’s a Model to bind to, and some actions (methods) on the ViewModel that can be invoked.

And the ViewModel knows nothing more than that it is being invoked by something. XAML, a test harness, it doesn’t really matter, it just does its thing.

Whether this is “MVVM” or not, I think it is pretty darn cool :)

Tuesday, August 4, 2009 9:30:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

I’m trying to do something that seems like it should be so simple and obvious.

I have an attached property, MethodParameter, which I’m applying to a Button, but I’m binding to a ListBox control:

<Button Content="Process items"
        csla:InvokeMethod.MethodParameter="{Binding ElementName=DataListBox, Path=SelectedItems}"/>

This works, and does bind. But it appears to bind only when the Button control is instantiated, not when the Click event is handled.

In other words, the binding occurs. The user then interacts with the ListBox control and selects some items, and then clicks the Button. That triggers the Click event, which causes the InvokeMethod object to actually use the MethodParameter value.

However, at that point in time the binding appears to still be using the original collection from when the form was being loaded, and so the collection is empty.

If I actually examine the SelectedItems property it has multiple items of course – but it is a different collection than the one from when the form was loaded.

In other words, ListBox seems to create a whole new collection each time SelectedItems is invoked, and that’s apparently totally messing up data binding.

I don’t know if this problem is unique to ListBox, or if it is a broader problem with element binding, but it is making my life very unpleasant…

To solve this, I’m hijacking the binding process like this:

public static object GetMethodParameter(UIElement ctrl)
  var fe = ctrl as FrameworkElement;
  if (fe != null)
    var be = fe.GetBindingExpression(MethodParameterProperty);
    var dataItem = be.DataItem;
    string path = be.ParentBinding.Path.Path;
    if (dataItem != null && !string.IsNullOrEmpty(path))
      var pi = Csla.Reflection.MethodCaller.GetProperty(dataItem.GetType(), path);
      return Csla.Reflection.MethodCaller.GetPropertyValue(dataItem, pi);
  return ctrl.GetValue(MethodParameterProperty);

Basically I’m using reflection to manually go get the property value of the target object. This works, but feels really wrong.

If we’re dealing with a nasty idiosyncrasy of the ListBox I can probably restrict this to only be messy when talking to a ListBox control, but I rather suspect ListBox isn’t the only issue.

I’ve tried all sorts of things on the binding expression - Mode=TwoWay and BindsDirectlyToSource=True. But they had no impact. It appears that the binding gets a reference to the property value when it is created and never knows enough to re-read the value later when I actually need it.

Any ideas?

Tuesday, August 4, 2009 9:13:49 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, July 31, 2009

There’s no DataContextChanged event in Silverlight. And that’s a serious problem for creating certain types of control, because sometimes you just need to know when your data context has been changed!

In my case I have the Csla.Silverlight.PropertyStatus control, which listens for events from the underlying data context object so it knows when to refresh the UI. If the data context changes, PropertyStatus needs to unhook the events from the old object, and hook the events on the new object. That means knowing when the data context has changed.

In version 3.6 we implemented a Source property and required that the data source be explicitly provided. That was unfortunate, but since it was our own property we could detect when the value was changed.

I recently did a bunch of research into this topic, trying to find a better answer. I’d rather hoped that Silverlight 3 would provide an answer, but no such luck…

It turns out that there’s a hack solution that does work. Actually there are a few, but most of them seem terribly complex, and this one seems somewhat easier to follow.

The basic idea is to create a data binding connection between your DataContext property and another of your properties. Then when DataContext changes, data binding will change your property, and you can detect that your property has changed. Rather a hack, but it works.

In its distilled form, the structure looks like this. First there’s the control class, which inherits from some framework base class:

public class PropertyStatus : ContentControl

Then there’s the constructor, which includes a handler for the Loaded event, which is where the real magic occurs:

public PropertyStatus()
  Loaded += (o, e) =>
    var b = new System.Windows.Data.Binding();
    this.SetBinding(SourceProperty, b);

When the control is loaded, a new Binding object is created. This Binding object picks up the default DataContext value. The Source property is then bound to this new Binding, which effectively binds it to the default DataContext. Definitely a bit of hackery here…

Obviously this means there’s a Source property – or at least the shell of one. I don’t really want a visible Source property, because that would be confusing, but I must at least implement the DependencyProperty as a public member:

public static readonly DependencyProperty SourceProperty = DependencyProperty.Register(
  new PropertyMetadata((o, e) => ((PropertyStatus)o).SetSource(e.OldValue, e.NewValue)));

I do have a private Source property, though I’ve never found that it is invoked (breakpoints in the get/set blocks are never hit):

private object Source
  get { return GetValue(SourceProperty); }
    object old = Source;
    SetValue(SourceProperty, value);
    SetSource(old, value);

The lambda in the static DependencyProperty declaration calls SetSource(), and this is my “data context changed” notification:

private void SetSource(object old, object @new)

I suppose this could be generalized into a base class, where SetSource() really raises a DataContextChanged event. I didn’t find the need for that, as I’ve only got a couple controls that need to know the data context has changed, and they inherit from different framework base classes.

The point being, with a little data binding hackery, it is not terribly hard to implement a method that is invoked when the data context changes. Not as nice as having the actual event like in WPF, but much nicer than forcing the XAML to explicitly set some data source property on every control.

(for those interested, this will be changed in CSLA .NET 3.7.1, and it will be a breaking change because the Source property will go away)

Friday, July 31, 2009 3:41:57 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

The current contender for the pattern to displace IoC as “the trendy pattern” is MVVM: Model-View-ViewModel.

MVVM, often called the ViewModel pattern, has its origins in Silverlight, and to a lesser degree WPF has murky origins (maybe Expression Blend, Smalltalk or from aliens in the 8th dimension). It applies well to Silverlight and WPF, because those environments use XAML to describe the actual user presentation, and there’s a very valid desire to avoid having any code-behind a XAML page. A traditional MVC or MVP model isn’t sufficient to accomplish that goal (at least not efficiently), because it is often necessary to have some “glue code” between the View and the Model, even when using data binding.

The challenge is that some Models aren’t shaped correctly to support the View, so something needs to reshape them. And ideally there’d be some way (WPF commanding or similar) to “data bind” button click events, and other events, to some code other than code-behind. The idea being that when a user selects an item in a ListBox, the code that runs in response isn’t in the code-behind.

The idea behind ViewModel is to create a XAML-friendly object that sits between the View and the Model, so there’s a place for what would have been code-behind to go into a testable object. The ViewModel becomes the container for the code-behind, but it isn’t code-behind. Clearly the ViewModel object is part of the UI layer, so the architecture is something like this.


It turns out that there are various ways of thinking about the role of a ViewModel. I think there are two broad approaches worth considering.

ViewModel as Sole Data Source

You can set up the ViewModel to be the sole data source for the View. In this case the ViewModel exposes all the properties and methods necessary to make the View function. This can work well with an anemic Model, where the Model is composed of a bunch of dumb data container objects (think DataTable, DTO and most entity objects).

With an anemic data-centric Model it is common to reshape the Model to fit the needs of the View. And since the Model is anemic, something needs to apply any business, validation and authorization rules and it surely won’t be the Model itself.

Creating this type of ViewModel is non-trivial, because the ViewModel must use containment and delegation (a concept familiar to VB6 developers) to literally wrap, reshape and alter/enhance the behavior of the underlying Model.


Every Model property must be reimplemented in the ViewModel, or the View won’t have access to that property. The ViewModel must implement INotifyPropertyChanged, and very possibly the other data binding interfaces (IDataErrorInfo, IEditableObject, etc).

In short, the ViewModel will almost certainly become quite large and complex to overcome the fact that the Model is anemic.

What’s really sad about this approach, is that the end result will almost certainly require more code than if you’d just used code-behind. Arguably the result is more testable, but even that is debatable, since the ViewModel now implements all sorts of data binding goo and you’ll need to test that as well.

ViewModel as Action Repository

Another way to think about a ViewModel is to have it be a repository for actions/commands/verbs. Don’t have it reimplement all the properties from the Model, just have it augment the Model.

This works well if you already have a rich Model, such as one created using CSLA .NET. If the Model is composed of objects that already fully support data binding and have business, validation and authorization rules, it seems silly to reimplement large chunks of that functionality in a ViewModel.

Instead, have the ViewModel expose the Model as a property, alongside any additional methods or properties exposed purely by the ViewModel itself.


Again, this presupposes the Model is powerful enough to support direct data binding to the View, which is the case with CSLA .NET business objects, but may not be the case with simpler DTO or entity objects (which probably don’t implement IEditableObject, etc).

The value to this approach is that the ViewModel is much simpler and doesn’t replicate large amounts of code that was already written in the Model. Instead, the ViewModel augments the existing Model functionality by implementing methods to handle View requirements that aren’t handled by the Model.

For example, the Model may be a list of objects that can be bound to a ListBox control in the View. When the user double-clicks an item in the ListBox it might be necessary for the UI to navigate to another form. Clearly that’s not a business layer issue, so the Model knows nothing about navigation between forms. Typically this would be handled by a MouseDoubleClick event handler in code-behind the XAML, but we want no code-behind, so that option is off limits.

Since neither the View nor the Model can handle this double-click scenario, it is clearly in the purview of the ViewModel. Assuming some way of routing the MouseDoubleClick event from the XAML to a method on the ViewModel, the ViewModel can simply implement the method that responds to the user’s action.

This is nice, because the View remains pure XAML, and the Model remains pure business. The presentation layer concept of navigation is handled by an object (the ViewModel) who’s sole job is to deal with such presentation layer issues.

Routing XAML Events to a ViewModel

Regardless of which kind of ViewModel you build, there’s a core assumption that your XAML can somehow invoke arbitrary methods on the ViewModel in response to arbitrary actions by the user (basically in response to arbitrary events from XAML controls). WPF commanding gets you part way there, but it can’t handle arbitrary events from any XAML control, and so it isn’t a complete answer. And Silverlight has no commanding, so there’s no answer there.

When we built CSLA .NET for Silverlight, we created something called InvokeMethod, which is somewhat like WPF commanding, but more flexible. In the upcoming CSLA .NET 3.7.1 release I’m enhancing InvokeMethod to be more flexible, and porting it to WPF as well. My goal is for InvokeMethod to be able to handle common events from a ListBox, Button and other common XAML controls to invoke methods on a target object in response. For the purposes of this blog post, the target object would be a ViewModel.

The ListBox control is interesting to work with, because events like SelectionChanged or MouseDoubleClick occur on the ListBox control itself, not inside the data template. There’s no clear or obvious way for the XAML code to pass the selected item(s) as a parameter to the ViewModel, so what you really need to do is pass a reference to the ListBox control itself so the ViewModel can pull required information from the control in response to the event. In my current code, the solution looks like this:

<ListBox ItemsSource="{Binding Path=Model}"
         ItemTemplate="{StaticResource DataList}"
         csla:InvokeMethod.Resource="{StaticResource ListModel}"

Notice that the ItemsSource is a property named Model. This is because the overall DataContext is my ViewModel object, and it has a Model property that exposes the actual CSLA .NET business object model. In fact, I have a CslaViewModel<T> base class that exposes that property, along with a set of actions (Save, Cancel, AddNew, Remove, Delete) supported by nearly all CSLA .NET objects.

For the InvokeMethod behaviors, the ListModel resource is the ViewModel object, and it has a method called ShowItem(), which is invoked when the ListBox control raises a SelectionChanged event:

public void ShowItem(object sender, object parameterValue)
  var lb = (System.Windows.Controls.ListBox)sender;
  SelectedData = (Data)lb.SelectedItem;

The ShowItem() method gets the selected item from the ListBox control and exposes it via a SelectedData property. I have a detail area of my form that is databound to SelectedData, so when the user clicks an item in the ListBox, the details of that item appear in that area of the form. But the ShowItem() method could navigate to a different form, or bring up a dialog, or do whatever is appropriate for the user experience.

The point is that the SelectionChanged, or other event, from a XAML control is used to invoke an arbitrary method on the ViewModel object, thus eliminating the need for code-behind the XAML.

Why this isn’t Ideal

My problem with this implementation is that the View and ViewModel are terribly tightly coupled. The ShowItem() implementation only works if the XAML control is a ListBox. It feels like all I’ve done here is moved code-behind into another file, which is not terribly satisfying.

What I really want is for the XAML to pick out the selected item – something like this pseudocode:

<ListBox ItemsSource="{Binding Path=Model}"
         ItemTemplate="{StaticResource DataList}"
         csla:InvokeMethod.Resource="{StaticResource ListModel}"

Where “Element” refers to the current XAML control, and “SelectedItem” refers to a property on that control.

Then the ShowItem() code could be like this:

public void ShowItem(object parameterValue)
  SelectedData = (Data)parameterValue;

Which would be much better, since the ViewModel is now unaware of the XAML control that triggered this method, so there’s much looser coupling.

There’s no direct concept for what I’m suggesting built into XAML, so I can’t quite do what I’m showing above. The “{}” syntax is reserved by XAML for data binding. But I’m hopeful that I can make InvokeMethod do something similar by having a special syntax for the MethodParameter value, using characters that aren’t reserved by XAML data binding. Perhaps:


Or maybe more elegant would be a different property:


Anyway, I think this is an important thing to solve, otherwise the ViewModel is just a more complicated form of code-behind, which seems counter-productive.

Friday, July 31, 2009 9:44:09 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, July 27, 2009

Who’d have thought I’d get spammed by my own ads?

On a couple of my sites (this blog and my forum) I use Google adSense to generate ads. That helps pay for my Internet costs and helps keep CSLA .NET free, which is good.

As a provider of technical content on both my forum and blog, I rather expect that I’ll get reasonably targeted ads – that’s the whole point of Google’s “context sensitive” rule-the-world marketing engine after all…

So I was entirely taken aback this morning, when I received an email from a forum user that included a screen shot of a buxom young lady as part of an ad on my site. In fact, I rather suspected some proxy agent between his client and my server did some ad replacement or something – I mean who would think Google would put near-porn content on my technical forum?

Well it turns out that Google really would put near-porn on my technical forum.

It turns out that the advertiser in question is apparently working around the edges of Google’s policies – or may have crossed them and Google has just ignored it for a month or more – I really don’t know.

Thanks to help from fellow users of Google (not Google themselves – they are apparently too busy “doing no harm” to help us stop them from doing harm), I think I have the ads filtered out.

However, I no longer trust Google adSense, and I wasted enough time on this to pretty much eat any income I’ve generated thus far from having their ads on my site… I figure I’ll leave their ads online in the hopes that Google gets a clue and addresses the issue – but next time something like this happens my “filter” solution will almost certainly be to just drop Google entirely, and look for a more reputable ad provider.

Monday, July 27, 2009 1:35:00 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, July 21, 2009

I have released CSLA .NET version 3.7, with support for Silverlight 3.

This is really version 3.6.3, just tweaked slightly to build on Silverlight 3. It turns out that the Visual Studio upgrade wizard didn’t properly update the WCF service reference from Silverlight 2 to Silverlight 3, so I had to rereference the data portal service. I also took this opportunity to fix a couple minor bugs, so check the change logs.

  1. If you are a CSLA .NET for Windows user, there’s just one minor change to CslaDataProvider, otherwise 3.7 really is 3.6.3.
  2. If you are a CSLA .NET for Silverlight user, there are a couple minor bug fixes in CslaDataProvider and Navigator, and 3.7 builds with Silverlight 3. Otherwise 3.7 is 3.6.3.

In other words, moving from 3.6.3 to 3.7 should be painless.

Downloads are here:

At this point the 3.6.x branch is frozen, and all future work will occur in 3.7.x until I start working on 4.0 later this year.

Tuesday, July 21, 2009 9:45:08 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Sunday, July 19, 2009

Every year Magenic gives its employees a cool tech gift around the holidays. This year it was a Kindle 2, and so I’ve been using mine for several months now and have some thoughts.

On the upside, the Kindle allows me to bring a number of books with me everywhere I go. This is very nice, given how much I travel for work, and the fact that I do most of my reading while sitting in airplanes.

Also, I like the form factor of the device, including the size, shape and weight. And the screen is easy on the eyes. I really think I read faster on the Kindle than with a paper book because of the clarity, consistency and the nice way the device moves forward from page to page.

But there are some things I dislike too.

I like to share books. My wife and I have a respectable library in our home, and we’re constantly loaning books to friends. And borrowing books in return – it is a great way to interact socially and share common interests.

The Kindle entirely destroys the concept of book sharing. With a real book I spend $8-$25 to get something I can read and share with friends. With the Kindle I pay the same price, but only I can read the result. All I can do is tell my friends it was good, or not.

As a content creator, I suppose I should be cheering on the idea of books that can’t be shared, but I’m afraid I’m a reader first, and author second, and this is a really serious drawback for me. To the point that, since getting the Kindle, I’ve purchased a couple paper books because I know I’ll want to share them. Obviously I didn’t waste the money to buy them on the Kindle too, as that seems rather silly to me, so there I was back to lugging around paper books on the airplane.

The other major problem I have with the Kindle is the same one I have with buying music online.

While Amazon (and music vendors) portray the transaction as a “purchase”, it is really a “lease”.

I’ve lost several CDs worth of music over the years, as a music vendor went out of business and their licenses expired and the music I “bought” was rendered unplayable. I’ve long since decided that I’ll never buy DRM “protected” music. Such a “purchase” is a hoax – a total scam. Personally I think it should be illegal to portray it as a purchase transaction (false advertising or whatever), but I guess we live in a laissez-faire enough world that it is up to each of us to get ripped of a few times before we rebel against the dishonest corporate entities.

I hadn’t really thought about the Kindle being in the same category until I read this recent article. It turns out that Amazon can yank your license to read a book if they desire. And of course it is true that if Amazon folds, or gets bored with the Kindle idea, that all the books I “purchased” will disappear.

With music I’ve been paying a monthly fee to the Zune service to lease access to all the music they have. And that makes me reasonably happy, because it is an honest, up-front transaction that is what it says it is. I get access to amazing amounts of music as long as I keep paying my lease. If I stop paying, or if the Zune service goes away, the music disappears. This makes me happy overall, and I view this as a reasonably value.

Maybe Amazon should do this with the Kindle too. Be more honest and up-front about the nature of the transaction and the relationship. Charge a monthly fee for access to their entire online library of books, and have the books disappear off the device if/when I stop paying the monthly fee.

Of course this still doesn’t solve the problem where I can’t share books I “purchase” with my friends, I still don’t know of a good solution to this issue.

Sunday, July 19, 2009 5:35:26 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, July 10, 2009

You’ve probably noticed that Microsoft released Silverlight 3 today. More information can be found at

I’ve put a very stable beta of CSLA .NET 3.7 online as well

Version 3.7 is really the same code as 3.6.3, but it builds with the Silverlight 3 tools for Visual Studio 2008. So while I’m calling it a beta, it is really release-quality code for all intents and purposes.

If you are a Windows/.NET user of CSLA .NET, you’ll find that all future bug fixes, enhancements and so forth will be in version 3.7. Version 3.6.3 is the last 3.6 version.

If you are a Silverlight user of CSLA .NET, and continue to use the Silverlight 2 tools, 3.6.x is still for you, but I plan to address only the most critical bugs in that version – and I’m not currently aware of anything at that level. So 3.6.3 is really the end for Silverilght 2 as well.

In short, 3.7 is now the active development target for any real work, and you should plan to upgrade to it when possible.

Friday, July 10, 2009 11:46:31 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Wednesday, July 8, 2009

I’ve observed, in broad strokes, a pattern over the past 20 years or so.

At one time there was DOS (though I was a happy VAX/VMS developer at the time, and so didn’t suffer the pain of DOS).

Then there was Windows, which ran on DOS (sadly I did have to deal with this world).

Then we booted into Windows, which had a “DOS command prompt” window, so DOS ran on Windows (and the world got better).

Windows lasted a long time, but then came .NET, which ran on Windows.

I always expected that we’d see the time come when we’d boot into .NET, and Windows would run on .NET.

I no longer think that’s likely. Which is too bad, because that would have been cool.

But in the late 1990’s there was the very real possibility that the browser would become the OS. The dot-bomb crash eliminated that debate, robbing the browser-based company’s of their funding and allowing Windows, Linux and Mac OS to continue to dominate.

In the past 2-3 years though, we’ve seen something different. Flash/Flex/Air, Silverlight and Google Gears have shown that the “browser as the OS” idea didn’t go away, it just went to sleep for a while.

Now I’ll suggest that there are really two camps here. There’s the Google camp that really wants the browser as the OS. And there’s the Adobe/Microsoft camp (can I put them together?) that realizes that the technology of the web is really a stack of hacks, and that it is high time to move on to the next big thing. My bias is clearly toward the next big thing, and has been since the web started being misused as an app platform in the 1990’s. They are proposing the mini-runtime-as-the-OS concept, using the browser as a simple launch-pad for the real runtime.

But either way, the concept of a “client OS” has been fading for some years now in my view. Or conversely, the concept of “all my apps run in ‘the browser’” has been ascending steadily and rapidly over the past 2-3 years.

And I’m OK with this, because we’re not talking about reducing all apps to stupid browser-based mainframe-with-color architectures like the web has tried to do for over a decade.

No! We’re talking about full-blown smart-client technologies like Silverlight, where the client application can be an edge application in a service-oriented system, or the client tier of an n-tier application. We’re talking about the resurgence of the incredible productivity and scalability offered by the n-tier technologies of 1997-98. We’re talking about getting our industry back on track, so we can look back at 1999-2009 as nothing more than a “lost decade”.

(can you tell I think the terminal-based browser model is really lame?)

Does this mean that Windows, Mac OS and Linux become less relevant? I think so. Does this mean that Silverlight is the most important technology Microsoft is currently building? I think so.

Consider that Silverlight, in a <5 meg runtime, provides everything you need to build most types of powerful smart-client business applications. And consider that these applications auto-deploy and auto-update in a way that the user never sees the deploy/update process. Totally smooth and transparent.

Consider that you can write your C# or VB code and run it on the client. Or on the server. Or both (see CSLA .NET for Silverlight if you want to know more). You don’t need to learn JavaScript. You don’t need a totally different language and runtime on the client from the server. Silverlight provides a decent level of consistency between client and server, so you can reuse code, and absolutely reuse skills, knowledge and tools.

Google is totally on the bandwagon of course. Many people have seen their strategy for months, if not years. And we’re now seeing it come through, as they start to make their browser is the OS play in earnest.

What’s interesting to me, is that in either case – the browser-as-OS (Google) or the mini-runtime-as-OS (Silverlight) – leaves the previous generation OS concept (Windows/Mac/Linux) out of the loop.

Windows 7, perhaps the best version of Windows ever created, might be the last great hurrah for the legacy OS concept.

I mean all we need now is a Silverlight-based version of Office (to compete with Google Apps) and the underlying “OS” beneath Silverlight becomes rapidly irrelevant...

Wednesday, July 8, 2009 10:45:44 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

As anyone who’s used VB any time after 1994 knows, dynamic languages are really powerful for certain problems. Of course it used to be called “late binding”, but the point is that you can write code against a type you don’t know at development time (or compile time).

This concept is all the rage now, and it is fun (imo) to be able to nod sagely and say “Yes, I’ve been saying this for 14 years now.”

Not that I’d say that to Chris, but it is really nice that he is now an “it getter”*:

But the concept is really, really powerful. And many of the related concepts and capabilities that have come in more recent languages, including VB 9, 10 and C# 4, really enhance the capabilities of “late binding” and open up entire new scenarios.

This is along the lines of the C# people who talk about the couple features that are not in VB, and then dismiss XML literals as being of little or no value. That’s just ignorance talking. XML literals do for XML coding what dynamic languages do for using objects to abstract service/system boundaries.

I have been doing nearly all C# for over a year, but when I need to mess with XML I still create a VB project. Who’d choose to put themselves through the pain incurred in C# to do something that is so much simpler in VB?

In the end, my point is simple: don’t be a language bigot. Every language out there, VB, Python, C# and more, brings something unique and beautiful to the world. We can only hope that our language of choice (whatever that is for you) has an architect with an open mind, who is willing to bring the best ideas into each language…

(and yes, I hope that means things like XML literals, WithEvents and the Implements clause work their way into C# – because those concepts are really powerful and would benefit the language greatly)

Regardless, it is nice to see C# gaining “late binding”, which should provide great benefit a lot of people.


* thank you Steven Colbert

Wednesday, July 8, 2009 9:50:15 AM (Central Standard Time, UTC-06:00)  #    Disclaimer