Rockford Lhotka

 Friday, June 1, 2007

The WCF NetDataContractSerializer is an almost, but not quite perfect, replacement for the BinaryFormatter.

The NDCS is very important, because without it WCF could never be viewed as a logical upgrade path for either Remoting or Enterprise Services users. Both Remoting and Enterprise Services use the BinaryFormatter to serialize objects and data for movement across AppDomain, process or network boundaries.

Very clearly, since WCF is the upgrade path for these core technologies, it had to include a serialization technology that was functionally equivalent to the BinaryFormatter, and that is the NDCS. The NDCS is very cool, because it honors both the Serializable model and the DataContract model, and even allows you to mix them within a single object graph.

Unfortunately I have run into a serious issue, where the NDCS is not able to serialize the System.Security.SecurityException type, while the BinaryFormatter has no issue with it.

The issue shows up in CSLA in the data portal, because it is quite possible for the server to throw a SecurityException. You'd like to get that detail back on the client so you can tell the user why the server call failed, but instead you get a "connection unexpectedly closed" exception instead. The reason is that WCF itself blew up when trying to serialize the SecurityException to return it to the client. So rather than getting any meaningful result, the client gets this vague and nearly useless exception instead.

By the way, if you want to see the failure, just run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.NetDataContractSerializer
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

And if you want to see it not fail run this code:

    Dim buffer As New System.IO.MemoryStream
    Dim formatter As New System.Runtime.Serialization.Formatters.Binary.BinaryFormatter
    Dim ex As New System.Security.SecurityException("a test")
    formatter.Serialize(buffer, ex)

I've been doing a lot of work with the NDCS over the past several months. And this is the first time I've encountered a single case where NDCS didn't mirror the behavior of the BinaryFormatter - which is why I do think this is a WCF bug. Now just to get it acknowledged by someone at Microsoft so it can hopefully get fixed in the future...

The immediate issue I face is that I'm not entirely sure how to resolve this issue in the data portal. One (somewhat ugly) solution is to catch all exceptions (which I actually do anyway), and then scan the object graph that is about to be returned to the client to see if there's a SecurityException in the graph. If so perhaps I could manually invoke the BinaryFormatter and just return a byte array. The problem with that is in the case where the object graph is a mix of Serializable and DataContract objects - in which case the BinaryFormatter won't work because it doesn't understand DataContract...

In the end I may just have to leave it be, and people will need to be aware that they can never throw a SecurityException from the server...

Friday, June 1, 2007 11:34:14 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

A fellow Magenicon has also blogged in response to Fowler's comments about the .NET world.

Friday, June 1, 2007 8:57:49 AM (Central Standard Time, UTC-06:00)  #    Disclaimer

Strangeloop is one of the coolest products I've seen (not as cool as Surface, but that's hard to top :) ).

This product is an ASP.NET-aware device that does intelligent caching for web sites. It can do things that seem virtually impossible - it is that cool! Here's Richard Campbell's blog entry with more background.

If you have the need for a nearly transparent boost in performance for your ASP.NET web site, Strangeloop is something you should look at!

Friday, June 1, 2007 8:41:09 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Thursday, May 31, 2007

Martin Fowler’s recent blog post about Ruby and Microsoft has some good points. But he, like many outside the Microsoft space, make a faulty assumption about why there seems to be a lack of excitement in the Microsoft space.

I don’t believe the lack of excitement is because we’re all bored. Conversely, the lack of excitement is because we’re overwhelmed. Who has time to be excited? Not only do we all have real work to do with the technologies we have today, but on our doorstep is a mounting pile of new and potentially better technologies.

There’s certainly some truth to the idea that alpha geeks (or uber-geeks) live for the thrill of technology. But even most uber-geeks are finding the incredible pace of Microsoft product releases to be overwhelming.

We’re not just talking about pure dev tools, and perhaps that’s the problem. We’re talking about Biztalk Server, SharePoint Server, Microsoft Office itself and a whole bunch of other programmable server products. Each of these can be thought of as massive frameworks that a developer can tap into.

That’s on top of the peripheral dev tools like VSTS and TFS and all the various versions of Visual Studio Developer/Test/whatever. (Fowler is right on this one – few if any organizations divide their people into such rigid roles and Microsoft did a bad thing by defining their SKUs the way they did.)

Then there are the major platform-changers like AJAX and Silverlight. And the related tooling like Expression Blend and the rest of the Expression Suite. Like it or not, developers are almost certainly going to have to learn not only these technologies, but these not-really-designed-for-the-developer type tools. You can’t build a meaningful WPF or Silverlight app without using Blend. Sorry, but there it is.

If that isn’t enough to get a person scared, then there are the actual dev tools. A new version of Visual Studio (code-named Orcas) is mere months away, just as many people are moving to VS 2005. A new version of .NET (3.0) is already out, and yet most people have barely looked it. And along with VS Orcas will come .NET 3.5, which is in many ways a bigger change than 3.0!!

For application architects the challenges here are tremendous. How to exploit the productivity gains offered by all these new and upcoming technologies, and yet mitigate the risks they entail. Is it cheaper, for a given project, to use Windows Workflow or Biztalk Server? How much time could be saved by switching an application’s file store over to SharePoint Server, but what’s the cost in terms of learning that new API/framework?

Given the broad lack of real-world experience with these new technologies, there’s no realistic way to know what the cost/benefit will be for any given technology. Even those of us “in the know” are barely aware of the true value propositions and risks they pose.

At the same time, it is a faulty assumption to think that we’re not excited. Like a great many people in the Microsoft space, I am very excited about the upcoming language features in C# and VB! There’s absolutely no doubt in my mind that LINQ will literally transform the way we write code.

And then there’s the Dynamic Language Runtime (DLR) coming in Silverlight, along with VBx and other dynamic languages like Ruby and Python. Take all the incredible coolness of VB 9 with LINQ and the related language enhancements, then add a liberal coating of fantastic dynamic language features (beyond the ones VB has had since day 1) and who wouldn’t be excited!?!

But at the same time, you’ll have to forgive the vast majority of developers if they see all this as a double-edged sword. Any major change comes with a price: a period of weeks or months of reduced productivity. For an alpha/uber geek this might be weeks, but it is still a productivity killer.

I don’t know what it is like outside the Microsoft world, but in our world we are busy, busy, busy!! A few weeks or months of reduced productivity to become proficient at WPF, WCF, WF, LINQ and all the other new language features is a hard pill to swallow. From a business planning perspective, the unknowns involved in such huge changes is very risky, and so is also a hard pill to swallow.

Yes, every single one of these technologies is totally awesome! Having spent a lot of time with WPF over the past few weeks, I can say that it is a serious productivity killer, and yet I haven’t had so much fun building a UI in years. Given another few weeks I imagine I’ll be building WPF UI’s just as fast as I can with Windows Forms, but those UI’s will be far more flexible and will require substantially less code to write.

Personally, I want to build my WPF app and then run it on a Microsoft Surface platform. Welcome to the world of Star Trek!! :)

Thursday, May 31, 2007 6:19:41 PM (Central Standard Time, UTC-06:00)  #    Disclaimer

The CSLA .NET community has been very fortunate, in that people from all over the world have contributed their time and effort to build CSLA resource files for many languages. In CSLA 3.0 I added some new resource strings, and so there is a need to add some new translations to each language's resx file.

If you are willing to update (or create a new) resx file for your language that is very kind. You will gain the benefit of having the proper translations, as will your fellow countrymen.

You can also get the resx files from here:

The English file is called Resources.resx, and it is the master list.

For most language files, this view should give the differences since version 2.0:

Knut Vonheim kindly put together a spreadsheet listing the new, obsolete and continued values for the resource file. It may be helpful for anyone doing more translations. You can get it from:

Not all language files have been kept in sync at all times, so you may want to check your specific language to make sure it is completely correct and complete.

Once you have updated your language's resx file, please EMAIL THE RESX to rocky (at) lhotka (dot) net.

For reference purposes, I have created a wiki page with the list of languages for CSLA 2.0 and 3.0

I'll keep updating this location as I get translations from people and add them to CSLA 3.0. Right now, the following languages are complete:

CSLA 3.0

CSLA 2.0

·       en (default)

·       da

·       es-ES

·       nl

·       ca-ES

·       no

·       pt

·       fr

·       de

·       km-KH


·       en (default)

·       bs

·       de

·       es

·       hr

·       it

·       pt-br

·       ro

·       ru

·       sr

·       sv

·       zh-CHS

·       il

·       da

·       es-ES

·       nl

·       ca-ES

·       no

·       pt

·       fr

Thank you for helping the CSLA community!

Thursday, May 31, 2007 7:44:02 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, May 29, 2007

I post this in the hopes that it will help prevent someone else’s pain. And because the search engines (live and google) never did give me any of these answers – they are totally clogged up with content from pre-release versions of Vista and with sites trying to sell or review mobile devices…

My wife has an HP 4150 – a wonderful little PDA. And a while back I put Vista on her laptop. Yesterday she tried to get it to sync, but Vista wouldn’t recognize the device. So she asked me for help, and there begins my tale of woe.

She was right, Vista would see the device through Explorer, so you could copy files back and forth, but the Windows Mobile Device Center (WMDC) wouldn’t see it at all.

After much time googling (see above) I gave up and went directly to the WMDC site – their home page never did show up in google (or… They say clearly that Windows Mobile 2003 is supported, and the HP 4150 clearly runs WM2003.

So now I’m perplexed. What could be wrong? Ahh! Perhaps there’s an update to the device from HP.

Go to and sure enough, there’s a ROM upgrade, which I downloaded.

By this point it was a little late, and I was a little frustrated that something so simple and obvious could be so hard. And the Microsoft page made no mention of any difficulties or challenges. No help with troubleshooting – or even any indication that troubleshooting would be required.

So I ran the ROM upgrade utility. On the Vista box. Stupid me. It started, and then failed. Leaving the IPAQ in a totally locked state. As long as the battery was in the device (I took the batter out a few times trying to reset things), the device was on a white logo screen showing a couple numbers (which I assume are hardware revision numbers or something).

At this point I appear to have a battery-powered paperweight, where once I had a PDA. Damn!

That was last night. Fortunately I have some awesome colleagues, and a couple of them replied to my email rant (I wasn’t happy).

Overnight I had left the battery out of the device. It apparently takes a few hours for some capacitors to discharge, and so at a colleague’s suggestion I put the battery back in this morning. Much to my relief the device rebooted with factory settings. Whew!

Then, following the suggestion from a Microsoft colleague, I ran the ROM upgrade from an XP machine. While the ROM upgrade utility will try to run on Vista, it won’t succeed – bad HP for not including an OS version check in such a critical utility!! One simple check like that would have saved me substantial trouble!

The upgrade works great from XP. Which is a lesson: if you decide to upgrade to Vista, make sure to keep at least one XP machine around for the next year or so, until these issues get ironed out. (A corollary to this is that if you only have one machine, you probably won’t want to go to Vista…)

It turns out however, that the ROM upgrade didn’t fix the sync issue. This is because Vista didn’t ship with the release version of WMDC. To get the release version of WMDC 6, you need to go to  and download the current version.

In theory I guess Windows Update is supposed to update WMDC for you, but in my experience that’s not true. I had to do force the upgrade manually.

Also, I still don’t know how to find out the version of WMDC you have installed on a machine. So I guess you could argue that everyone should go run that update just in case.

So let me recap. I did the following:

·         Tried to sync a WM2003 device with Vista (a supported activity, with no indication that there are issues from Microsoft’s web site) – this failed

·         Tried to do a ROM upgrade of the HP 4150 from Vista – this failed horribly

·         Found out that the device would reboot after a few hours without power (thankfully!)

·         Did the ROM upgrade from XP – successfully

·         Manually upgraded WMDC on Vista

·         Got the device to sync with Vista

Now my wife has a PDA again, which makes her happy. And that, of course, makes me happy.

And with any luck, this post will appear within the first few pages of a search about how to sync an HP IPAQ 4100 series (HP 4150) with Windows Vista through the Windows Mobile Device Center, and so can save someone else all the time and effort this process cost me…

Tuesday, May 29, 2007 8:46:32 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Monday, May 21, 2007

I have made CSLA .NET 3.0 Beta 1 available for download from the CSLA download page.

The changes in CSLA .NET version 3.0 are primarily focused on adding support for .NET 3.0 features: specifically WCF and WPF. No extra work was required to allow business objects to invoke WF workflows or to be used from activities in a WF workflow. There are also some very important bug fixes and feature enhancements that most people will want even when not using .NET 3.0.

There are no major or intentional breaking changes from version 2.1.4 to version 3.0.

CSLA 3.0 will work on .NET 2.0. You do not need .NET 3.0 to use this version. Obviously the WCF/WPF/WF features are only available to you if you have .NET 3.0.

The WCF support comes in two forms: a data portal channel, and comprehensive support for the DataContract/DataMember attributes. The data portal support comes in the form of a new data portal proxy, which is functionally equivalent to the CSLA 2.0 channels. In other words, upgrading to WCF is entirely transparent. The DataContract support is an optional configuration switch you can set in app.config/web.config to tell CSLA to use the WCF serializer rather than the BinaryFormatter. This affects n-level undo and cloning. If you want to use DataContract instead of Serializable on your business classes you must use this config switch.

The WPF support comes as a set of controls. These controls provide support for validation (like the Windows Forms ErrorProvider), authorization and a couple other key features. There is also a CSLA data provider control, allowing the creation of codeless XAML forms in some cases (for read-only data).

In addition to the .NET 3.0 support, there are some other functional enhancements to various areas. Here are some highlights:

  1. Validation RuleArgs are now more sophisticated, allowing for more expressive human-readable rule descriptions, and providing a better model for code generators when specifying arguments to be passed into a rule method.
  2. A number of bugs in BusinessListBase related to data binding scenarios have been fixed. Event handling for other list classes has been standardized as well. You will likely find that data binding to grids is much more reliable in 3.0 than in 2.1.4.
  3. SmartDate has some minor enhancements and bug fixes.
  4. N-level undo now detects when edit levels are out of sync and throws an exception. This helps locate and debug problems where nested begin/cancel/apply calls are out of order. While this feature will most likely cause some short-term pain as you find these issues, the result is that your code will behave properly.

For the complete list of changes, see the change log.

My plan is to leave this beta online for 2-3 weeks, followed by a second beta in mid-June and a release at the end of June. If you plan to move to CSLA .NET 3.0 within the next few months, please consider downloading and testing this beta. Let me know about any issues you find so I can resolve them for Beta 2.

Thank you!

Monday, May 21, 2007 7:00:02 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 11, 2007

Earlier I blogged about the fact that the Orcas Beta 1 VPC image doesn't have ASP.NET set up with IIS, so you have to do that. Unfortunately there are a couple other issues I've discovered. Here's the full list:

  1. IIS isn't configured for ASP.NET
  2. Windows authentication isn't enabled for the default web site in IIS - blocking the use of VS debugging until you enable it
  3. The default for a VS Orcas web site is to build for .NET 3.5. If you attempt to debug such a project (when it is set to run in IIS) you'll get an error dialog with a vague message about an authentication error. The reason for this is that ASP.NET only supports .NET 2.0. To resolve this, you must go into the web site's properties dialog and set its target .NET version to 2.0. You can still reference the 3.0 and 3.5 assemblies and use the new features, but VS must build to .NET 2.0 or you can't debug in IIS.

    But it isn't just the debugger - other features may not work properly either, possibly resulting in a "hang" when you try to access a page.

For those of you at my workshop at VS Live this past Sunday, this was why my web site wouldn't run properly in the VPC. Fortunately there is this workaround, but I hope Microsoft provides a more comprehensive solution in the release version, because it is quite confusing to have to set your build version back to 2.0 even though you are really building against 3.5...

Friday, May 11, 2007 9:01:33 AM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, May 4, 2007

I have put a test version of CSLA .NET version 3.0 up for download from the download page.

This release includes both VB and C# versions of CSLA .NET 3.0, though the WPF support in the VB version has undergone relatively little testing.

The C# ProjectTracker sample is relatively complete, though I'm still chasing down some WPF navigation issues, and may change it over to a Windows-based approach.

The VB ProjectTracker sample isn't as complete, but I've included it in the download nonetheless.

I expect that this is the last pre-release of the CSLA .NET 3.0 framework itself - the next release will be a beta release, and it is my hope to be done with 3.0 by the end of June. If you have the time and inclination, please download the framework and give it a try.

You should be aware that CSLA .NET 3.0 should work just fine on machines with only .NET 2.0, or with .NET 2.0 and 3.0 installed. It also works fine on Orcas Beta 1 (with .NET 2.0, 3.0 and 3.5 installed), though you'll have to upgrade the solution if you try to open it in VS Orcas.

Obviously if you only have .NET 2.0 installed, you can't use WCF or WPF. Attempting to use those features in CSLA .NET will result in compile or runtime errors. However, there are numerous bug fixes and enhancements to other areas of CSLA .NET that may benefit .NET 2.0 users. If you find that CSLA .NET 3.0 doesn't work for you under .NET 2.0 (without .NET 3.0 installed) please let me know so I can address any issues.

I am not aware of any breaking changes from CSLA .NET 2.1, so switching an existing project to use CSLA .NET 3.0 should be straightforward. If it is not, please let me know so I can either address or document any issues.

Friday, May 4, 2007 10:14:37 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Tuesday, May 1, 2007

This week Microsoft fully disclosed their plans for Silverlight. It is not only a way to build rich internet applications (RIAs), but it is a way to build them with .NET! This is very exciting news, and I hope that Microsoft follows through on their vision for Silverlight!!

With the support of Magenic, I've been researching the possibility of creating a CSLA Light which would run in an Internet zone sandbox, and in the even more restrictive Silverlight environment. The Silverlight 1.1 alpha available today doesn't have enough functionality to even come close to hosting something like CSLA, but Microsoft's plan for Silverlight should provide enough functionality to create a stripped down, client only version of CSLA.

That means no data portal, no Clone() method, and the requirement to implement GetState() and SetState() methods to support n-level undo (thanks to no private reflection). But it does mean that I should be able to provide the full validation, authorization, data binding and n-level undo capabilities of CSLA .NET in the CSLA Light version.

I also plan to provide the data portal interface so factory methods can remain consistent, but the back-end implementation will be quite different. (I can't do mobile objects due to no serialization, and I can't do the strongly-typed DP_XYZ calls due to no private reflection). The lack of a real data portal is pretty hard to take, but I haven't figured out a way to do it, so it is probably unavoidable...

I anticipate that around 80% of the code you'd write in a business object today will be the same in CSLA Light, perhaps even more.

Thanks to the compatibility between Silverlight and WPF/.NET itself, there are some other interesting possiblities for CSLA Light. Code written for Silverlight should always run in a less restrictive environment like WPF on Windows, or even XBAP/WPF in a browser. Due to this, CSLA Light will almost certainly work in those settings as well.

In any case, this will be a somewhat slow moving initiative, because I have to wait until Microsoft comes out with a release of Silverlight that supports key WPF features like data binding before I can get too far with the project...

Tuesday, May 1, 2007 4:25:03 PM (Central Standard Time, UTC-06:00)  #    Disclaimer
 Friday, April 27, 2007

The third pre-beta test release of CSLA .NET 3.0 is now available for download.

This release doesn't include any major changes from the previous release, but does include a set of bug fixes and stabilization.

This release does include an updated ProjectTracker application, which now includes:

  • PTWpf - the almost completed WPF UI for ProjectTracker
  • PTWorkflow - a simple workflow that makes use of CSLA-style objects in the activities
  • WcfPortal - a data portal host for the WCF data portal channel
  • PTWcfService - a WCF service interface, much like the older web service interface
  • PTWcfServiceClient - a Windows Forms client app for PTWcfService

Plus, of course, all the pre-existing Windows, ASP.NET and web service interfaces and data portal hosts.

This release is only available in C# at the moment. The WCF data portal channel for VB is complete, and is available directly from the svn repository. I'll port the remainder of the changes to VB once I'm more confident that they are stable (which should be in the relatively near future).

Friday, April 27, 2007 8:48:44 PM (Central Standard Time, UTC-06:00)  #    Disclaimer