CSLA .NET Version 3.0 is now available for download! Listen to the official announcement on .NET Rocks!

CSLA .NET 3.0 includes numerous enhancements and features of value to all CSLA .NET users, and of course version 3.0 adds support for Microsoft .NET 3.0 features like WCF and WPF.

You can use CSLA .NET 3.0 on either Microsoft .NET 2.0 or Microsoft .NET 3.0.

Features for everyone

CSLA .NET 3.0 includes enhancements useful to all CSLA .NET 2.1.4 users, including these highlights:

Validation rules

• PropertyFriendlyName – specify a friendly name to use when displaying broken rule text
• Format – specify a format mask to use when displaying broken rule numeric values
• StringMinLength – new validation rule method
• DecoratedRuleArgs – useful for code generation of AddBusinessRules() methods
• Fix bug with stopProcessing and rule priorities
• RegEx – rule method now supports options for dealing with null values

Authorization

• New CanExecuteMethod() functionality, similar to CanReadProperty() and CanWriteProperty()

Undo and Data binding

• If edit levels get out of sync an exception is thrown, making debugging of Windows Forms data binding much easier

Interfaces

• Cleaned up and rearranged interfaces to provide more consistency – making it easier to create UI frameworks on top of CSLA business layers

SmartDate

• Added TryParse() method
• Fix bug with CompareTo() method

SortedBindingList and FilteredBindingList

• Allow access to underlying source list

BusinessListBase

• Fix some bugs where ListChanged/CollectionChanged events were raised when they shouldn't have been. The result is that some data binding scenarios now work where they didn't, and in other cases performance is improved.

ProjectTracker\PTWin

• Reworked data binding code to address all known issues

See the change log for a complete list of changes.

Again, CSLA .NET 3.0 can be used without Microsoft .NET 3.0. If you want to build CSLA .NET 3.0 without installing the Microsoft .NET 3.0 runtime, you must define the NET20 symbol in project properties.

Microsoft .NET 3.0 Features

Of course the primary focus of CSLA .NET 3.0 is support for Microsoft .NET 3.0. Highlights include:

CSLA .NET

• WcfProxy – a data portal channel that uses WCF. You can transparently move from any existing data portal channel to WCF by using this new proxy.
• DataContract – support for using the WCF DataContract and DataMember attributes in your business classes
• WPF
  • CslaDataProvider – a data provider control that can create, fetch, save and cancel edits on a CSLA .NET business object. In some cases this can lead to code-less data entry forms!
  • Validator – a control that provides Windows Forms ErrorProvider-like behavior to WPF forms that are data bound to CSLA .NET objects.
  • Authorizer – a control that provides Windows Forms AuthorizeReadWrite-like behaviors to WPF forms that are data bound to CSLA .NET objects.
  • ObjectStatus – a control that exposes IsValid, IsSavable and other properties from a CSLA .NET business object so they can be used by XAML data binding.
  • IdentityConverter – a value converter that can be used to work around an issue with data binding and refreshing the UI.

The Csla solution is a Visual Studio 2005 solution. You can open and build the solution in Visual Studio 2005 if you have the Microsoft .NET 3.0 runtime installed on your workstation. Or you can use the NET20 symbol to allow compilation without the Microsoft .NET 3.0 runtime.

The Csla solution automatically upgrades when opened in Visual Studio 2008, and you can build the solution in Visual Studio 2008 if you are using that environment.

ProjectTracker\PTWpf

• Added new WPF UI with equivalent functionality to PTWin.

Note that this project is built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\PTWorkflow

• Added new Workflow UI to illustrate how a workflow can use CSLA .NET business objects

Note that this project is built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\PTWcfClient and PTWcfService

• Added a WCF service illustrating how to expose CSLA .NET objects through WCF/SOA
• Added a WCF client app illustrating how to call a WCF service

Note that these projects are built using Visual Studio 2008 (Orcas) Beta 1.

ProjectTracker\WcfHost

• Added a WCF host for the data portal

Note that this project is built using Visual Studio 2005 with the WCF extensions installed.

The ProjectTracker solution includes WcfHost, but does not include the other new projects. The reason for this is that the ProjectTracker solution is still a Visual Studio 2005 solution, while these other projects are built using Visual Studio 2008. The ProjectTracker solution upgrades automatically when opened in Visual Studio 2008, and in that environment you can add the remaining projects to the solution.

Migration

Migrating from version 2.1.4 to 3.0 should be relatively painless.

The only place you may encounter issues is that version 3.0 throws an exception if your edit levels get out of sync when using n-level undo. This may highlight pre-existing bugs in your UI code (especially in Windows Forms apps) that you should resolve. Look at the ProjectTracker\PTWin code for examples of the correct way to interact with Windows Forms data binding.

Migrating from 2.0.x to 3.0 has the same challenges as moving from 2.0 to 2.1. Version 2.1 introduced some significant, but important, changes to the handling of validation and authorization rules that can impact your business object code. See the CSLA .NET Version 2.1 Handbook for detailed information about version 2.1.

Migrating from 1.x to 3.0 will require some effort. There are many new features in 2.1 and 3.0 as compared to 1.x, and taking advantage of those features requires changes to your business objects and your UI code. You can look at the Expert C#/VB 2005 Business Objects books and the CSLA .NET Version 2.1 Handbook to get details around the scope of the changes.

Futures

I plan to write an ebook showing how to use the new features and enhancements in CSLA .NET 3.0. This ebook should be available in the third quarter of 2007 (probably September).

I’m working on CSLA .NET 3.5, based on Microsoft .NET 3.5 and focused on LINQ and various other new .NET features. Look for this in the first quarter of 2008.

I am also planning to update my Expert Business Objects books for Visual Studio 2008 and CSLA .NET version 3.5. This will probably come out in the second quarter of 2008.

You can see the roadmap here.

Just a quick reminder that the official 3 day CSLA .NET training roadshow continues through the summer. You can still attend in one of these cities:

• Orlando
• Chicago
• Washington, DC
• Dallas

The feedback from the classes so far has been excellent! I sat in on part of the class last week in Minneapolis, and I can see why. Miguel is a very good teacher, and his hands-on, continual lab style is a refreshing change from traditional powerpoint-heavy training.

CSLA .NET Version 3.0 Beta 2 is now available for download.

This is the final test release of version 3.0. Any changes between now and release will be bug fixes.

If you plan to upgrade please consider helping yourself and the community at large by downloading this version and testing it before July 5. Let me know about any issues through the forum.

CSLA .NET 3.0 provides support for Microsoft .NET 2.0 and 3.0.

If you want to build CSLA .NET 3.0 without .NET 3.0, you must define the NET20 symbol in the project properties.

CSLA .NET 3.0 includes enhancements useful to all 2.1.4 users, including these highlights:

Validation rules

·         PropertyFriendlyName – specify a friendly name to use when displaying broken rule text

·         Format – specify a format mask to use when displaying broken rule numeric values

·         StringMinLength – new validation rule method

·         DecoratedRuleArgs – useful for code generation of AddBusinessRules() methods

·         Fix bug with stopProcessing and rule priorities

·         RegEx – rule method now supports options for dealing with null values

Authorization

·         New CanExecuteMethod() functionality, similar to CanReadProperty() and CanWriteProperty()

Undo and Data binding

·         If edit levels get out of sync an exception is thrown, making debugging of Windows Forms data binding much easier

Interfaces

·         Cleaned up and rearranged interfaces to provide more consistency – making it easier to create UI frameworks on top of CSLA business layers

SmartDate

·         Added TryParse() method

·         Fix bug with CompareTo() method

SortedBindingList and FilteredBindingList

·         Allow access to underlying source list

ProjectTracker\PTWin

·         Reworked data binding code to address all known issues

See the change log for a complete list of changes.

Of course the primary focus of CSLA .NET 3.0 is support for Microsoft .NET 3.0. Highlights include:

·         WcfProxy – a data portal channel that uses WCF. You can transparently move from any existing data portal channel to WCF by using this new proxy.

·         DataContract – support for using the WCF DataContract and DataMember attributes in your business classes

·         WPF

o   CslaDataProvider – a data provider control that can create, fetch, save and cancel edits on a CSLA .NET business object. In some cases this can lead to code-less data entry forms!

o   Validator – a control that provides Windows Forms ErrorProvider-like behavior to WPF forms that are data bound to CSLA .NET objects.

o   Authorizer – a control that provides Windows Forms AuthorizeReadWrite-like behaviors to WPF forms that are data bound to CSLA .NET objects.

o   ObjectStatus – a control that exposes IsValid, IsSavable and other properties from a CSLA .NET business object so they can be used by XAML data binding.

o   IdentityConverter – a value converter that can be used to work around an issue with data binding and refreshing the UI.

ProjectTracker\PTWpf

·         Added new WPF UI with equivalent functionality to PTWin.

ProjectTracker\PTWorkflow

·         Added new Workflow UI to illustrate how a workflow can use CSLA .NET business objects

ProjectTracker\PTWcfClient and PTWcfService

·         Added a WCF service illustrating how to expose CSLA .NET objects through WCF/SOA

·         Added a WCF client app illustrating how to call a WCF service

ProjectTracker\WcfHost

·         Added a WCF host for the data portal

A CSLA .NET user, Aaron Nottestad, has been helping test 3.0 and ran into some issues when using the new WPF CslaDataProvider with editable objects. Thanks Aaron!

As a result, I had to do some work with CslaDataProvider, so it can manage the object’s entire lifetime from create/fetch through to save/cancel. If it can’t manage the lifetime, especially the save, then it can’t get the new object that comes back as a result of save. And if it doesn’t get that new object, then neither does data binding, so the UI controls end up editing an old instance of the object.

So the CslaDataProvider now has Save() and Cancel() methods that you can call to trigger saving or canceling of the business object. Also, as the object is created/fetched CslaDataProvider automatically calls BeginEdit() on the object.

This behavior is all optional, and is controlled by the ManageObjectLifetime property of the CslaDataProvider control. So if you want this behavior, you have to set that property to True. If you leave it at False (the default), then you must manage everything through code – though honestly you can’t manage editable objects through code while using CslaDataProvider. So maybe I should make the default be True? Hmm.

Anyway, this was easy enough to do and worked great. The resulting forms had exactly 4 lines of code – 2 to call Save() and 2 to call Cancel(). It occurred to me that there must be a way to avoid writing those 4 lines of boring code, and Aaron put me onto the RoutedCommand concept in XAML.

A RoutedCommand allows a control like a button or menu item to invoke a method on another control – purely through XAML. There are many examples out there about how this works to create standard Copy/Paste menu items that run against the current TextBox control, and that sort of thing. But none that I found which routed a command to a data provider control.

The reason turns out to be that the target of a command must be a UIElement, and data providers don’t inherit from that base class. Oops…

I thought I was stuck, because I really do want to route the command to CslaDataProvider in this case. However, I figured out a solution.

CslaDataProvider now has a read-only CommandManager property. This property exposes a “command manager” object which does inherit from UIElement and which does handle the Save and Undo routed commands. When it is created by CslaDataProvider, it is given a reference to the CslaDataProvider control, so it simply delegates all Save commands to the CslaDataProvider.Save() method and all Undo commands to CslaDataProvider.Cancel().

With that done, you can route a command from a button or menu item (or any other valid command source) to this CommandManager object, which effectively means you’ve routed the command to the CslaDataProvider control.

The CslaDataProvider gets declared like this:

    <csla:CslaDataProvider x:Key="ChildList"

                           ObjectType="{x:Type this:ChildList}"

                           FactoryMethod="GetList"

                           IsAsynchronous="False"

                           ManageObjectLifetime="True">

    </csla:CslaDataProvider>

Then the button controls get declared like this:

            <Button

              Command="ApplicationCommands.Save"

              CommandTarget="{Binding Source={StaticResource ChildList},

                              Path=CommandManager, BindsDirectlyToSource=True}"

              HorizontalAlignment="Left" IsDefault="True">Save</Button>

            <Button

              Command="ApplicationCommands.Undo"

              CommandTarget="{Binding Source={StaticResource ChildList},

                              Path=CommandManager, BindsDirectlyToSource=True}"

              HorizontalAlignment="Left" IsCancel="True">Cancel</Button>

The result is very cool: a form that can edit an object without the need to write any C# or VB code at all. Coupled with the CSLA .NET ValidationPanel to display validation results, you can create a highly interactive data edit form purely with XAML – and of course a CSLA .NET style business object doing all the work behind the scenes.

These new capabilities will appear in CSLA .NET 3.0 Beta 2 - hopefully later this week.

I’ve been spending some quality time with WPF and Visual Studio 2008 Beta 1 (Orcas) over the past few months. A couple observations I’ve made:

Observation ichi:

Putting code in a Page/Window constructor is bad. Yes, I know it is the “C# way”, but it is bad. The “VB way” of putting code in the Loaded event handler is better.

Why?

Because any exceptions thrown in the constructor prevent the page/window from loading at all, and you have to catch those exceptions in the code that is creating the page/window. In many navigation scenarios you can’t catch them, so the user gets an ugly WPF exception dialog.

However, if you do all your init work in the Loaded event handler, the page/window instance already exists. Navigation has already happened, so the “calling code” is no longer responsible for your page/window going haywire. Instead, you can actually handle the exception and show a nice dialog, explaining to the user what happened, and you can (if desired) navigate somewhere else or whatever.

Observation ni:

Handing control events with += or AddHandler is superior to using WithEvents/Handles. Yes, I am a strong advocate of WithEvents/Handles, and it is one of the major missing features in C#, but for WPF it turns out to be a negative.

Why?

Because the Handles clause links the name of the control to the code behind. The AddHandler or += approach, while less attractive in many ways, only couples the event name to the code behind.

In other words, when using Handles you get code like:

Private Sub Button1_Click(ByVal sender As Object, ByVal e As EventArgs) _
  Handles Button1.Click

While the AddHandler approach results in this code:

Private Sub SaveData(ByVal sender As Object, ByVal e As EventArgs)

The value of the second approach is that any control can route an event to SaveData(). It doesn’t have to be a button, much less Button1. It actually doesn’t even have to be a Click event. It could be almost any event.

The result is that the Presentation (XAML) is less coupled to the UI (VB/C# code) this way than when using Handles.

Unfortunately the Handles approach is more explicit and thus more readable (which is why C# should really get the Handles feature), so we’re left trading readability in order to gain loose coupling…

I posted previously about an issue where the WCF NetDataContractSerializer was unable to serialize a SecurityException object. Microsoft provided some insight.

It turns out that the constructor of the SerializationException object doesn't set the Action property to anything valid. Before you can serialize a SerializationException with NDCS you must explicitly set the Action property to a valid SecurityAction.

This does mean that NDCS is not compatible with the BinaryFormatter in this case, but at least there's a workaround/solution.

I've now updated CSLA .NET 3.0 to explicitly set the Action property any time a SecurityException is thrown, thus allowing the WCF data portal channel to return valid details about the nature of any exception.

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...

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

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!

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!! :)

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:

http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/cslavb/Csla/My%20Project/

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:

http://www.lhotka.net/cslacvs/viewvc.cgi/trunk/cslavb/Csla/My%20Project/Resources.resx?r1=1282&r2=1465

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:

http://www.lhotka.net/files/csla30/CSLAValues2.xvs3.0.xls

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

http://www.lhotka.net/wiki/default.aspx/LhotkaWiki/GlobalLanguages.html

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:

Thank you for helping the CSLA community!

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 live.com)… 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 hp.com 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 http://www.microsoft.com/windowsmobile/devicecenter.mspx  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…