in a recent email thread someone was wondering why component vendors are being so slow in coming out with grid controls for WPF/XAML.

One obvious reason is that grid controls are hard to build, and WPF/XAML is radically different from Windows Forms or Web Forms. But still, it is fair to wonder why these highly experienced control vendors haven't overcome that challenge.

I think the reason is that technology isn't the issue. At least not in the raw "learn how to use XAML" way. I think the real issue is much bigger!

Consider the incredible risk a vendor would assume by creating a grid control now.

Microsoft hasn’t come out with a WPF grid, and so there are no standard interfaces in .NET to support data binding to a grid. Certainly the current interfaces used by WPF are not nearly powerful enough to get in-place grid editing like we have in Windows Forms – and that’s a requirement if WPF is ever going to replace Windows Forms for business development.

Windows Forms and Web Forms both have benchmark grids from Microsoft. They set the standard, and define the core interaction used by data binding. The other vendors can then build around that core to do cool stuff. In particular, Windows Forms defines a whole set of powerful interfaces to allow in-place editing so the user can navigate freely in a grid, edit cells, add rows and delete rows – and press ESC to cancel changes to whatever row they are on. All features most users would consider critical to the in-place experience. The majority of those interfaces are not used by WPF today!! Nor does WPF have replacements for them. And if they do replace those interfaces then you can’t bind to a DataTable, which shuts out most developers from WPF again – probably a bad idea.

The WPF team has already shown that they’ll supersede existing interfaces (INotifyCollectionChanged was invented even though IBindingList was already there). So it is somewhat hard to predict where Microsoft might go in this regard. It is quite possible they’ll do the “worse of all worlds” and support the DataTable (all the existing Windows Forms interfaces) and invent a whole new model as well… (again, see INotifyCollectionChanged – invented for WPF, but IBindingList is also fully supported by WPF)

So in WPF the poor component vendors are really stuck. There’s no defined standard for this kind of data binding, so they need to invent it. They’ll each invent something different from the other vendors – and NONE of them will likely match whatever Microsoft eventually does. That means they are all in deep trouble when Microsoft does set the standard. And so are all consumers of those grids (all of us!).

This is very much like pre-ODBC database access, except in this case it is a very safe bet that “ODBC” is coming (in the form of some standard grid definition) and so investing in building a proprietary solution is a known dead-end. A waste of money and very likely a way to make many, many angry customers who may hate you forever.

Nasty business just now… :(

I have refreshed the CSLA .NET 3.5 download with much more recent code. (www.lhotka.net/cslanet/download.aspx)

The C# and VB versions of the framework and ProjectTracker are now very comparable. The only difference is that the VB framework doesn't have the LINQ extensions yet (though the C# version doesn't have the coolest parts yet either).

Some highlights:

1. All the new property/field/child management code is in both versions. The result is code reduction of ~35% per property and no more string literals for property names.
2. All the new child object code is in both versions. The result is no more plumbing code for child objects, "automatic" lazy loading support and consistent persistence for root and child objects.
3. Both versions have seriously enhanced type coercion that is used by the new property scheme and by DataMapper.
4. Both versions have much improved type casting for SmartDate, allowing much more flexible use of this type.
5. Check out the new ConnectionManager and ContextManager classes in Csla.Data for simplification of data access code with ADO.NET or LINQ.
6. ProjectTracker.Library now uses an external data access assembly, which was created using LINQ to SQL.

There are many other changes/enhancements/fixes - check out the change log for details. Or look at all the green items in the wish list, because that's all in 3.5.

I am still planning to do a beta release around January 25, so this is probably the last preview release before the beta.

I'm still working on a number of issues, and have more testing to do in general, but this is getting reasonably close to the final 3.5 feature set.

If you have comments/questions/concerns, please voice them now! Once the beta starts I'll be doing bug fixes only.

You are invited to join Magenic at a complimentary webinar,
designed as a resource for IT decision makers.
Listen in and bring your questions for the Q&A.

Get More from BI with Integrated Performance Management (January 9)
For business and IT managers that rely on business systems to form insightful decisions, we’ll show you how to take your BI systems to the next level with Microsoft Office PerformancePoint Server. view details

How to Break Through Software Development's Million-Dollar, 18-Month ROI Barrier (January 15)
There's no law that says custom software development projects must take 18 months and a million dollars to deliver ROI. There is a better way!  view details

How to Use CSLA .NET to make Building Object-Oriented Business Layers a Breeze (January 24)
In this technical overiew of CSLA .NET, Microsoft legend Rockford Lhotka expands on last month's webinar about the tremendous advantages of CSLA .NET. A must for technical professionals who want to master this development technique! view details

Magenic Delivery Center About Us Careers Webinars

I recently received this email:

Thank you very much for your insightful articles concerning 2 vs. 3 tier models.  It’s very refreshing to hear a view point that I’m aligned with.  Here at work I’m dealing with network Nazi’s who believe there is no cost of a middle tier and that there is only huge security rewards to reap.  I use your articles to support my point but I’m still not getting tremendously far.  I have yet to have anyone explain to me exactly how that middle tier is going to really add a significant enough amount of security that will warrant the high price to pay for employing a performance blasting middle-man.

There are two scenarios, though they are similar.

In the web, adding a middle tier has a very high cost, because the web server is already an app server. It already does database connection pooling across all users on that server. Adding an app server just adds overhead.

The only exception here is where the web server is serving up a lot of static content and only some dynamic content. In that case, moving the data access to another machine may be beneficial because it can allow the web server to focus more on delivering the static content. It is important to realize that the dynamic content will still be delivered more slowly due to overhead, but the overall web site may work better.

In Windows, adding a middle tier has a cost because the data needs to make two network hops to get to the user. Each network hop has a tangible cost. It would be foolish to ignore the cost of moving data over the wire, and the cost of serializing/deserializing the data on each end of the wire. These are very real, measurable costs.

In both cases the middle tier means an extra machine to license, administer, maintain, power and cool. It is an extra point of failure, extra potential for network/CPU/memory/IO contention, etc. These costs come with every server you add into the mix. Anyone who’s ever been a manager or higher in an IT organization has a very good understanding of these costs, because they impact the budget at the end of every year.

However, the security benefits of a middle tier are real.

In a 2-tier web model the database credentials are on the web server. Even if they are encrypted they are there on that machine. A would-be hacker could get them by cracking into that one machine.

Switching to a 3-tier model moves the database credentials onto the middle tier and off the web server. Now the web server has credentials to the app server, but not the database. A would-be hacker must crack first the web server, then the app server to get those credentials.

In a 2-tier Windows model the database credentials are on each client workstation. Even if they are encrypted they are there on those machines. A would-be hacker could get them by sitting at that machine - all it takes is a little social engineering and they're in. More likely, an employee may get the credentials and use Excel or some other common tool to directly access the database, bypassing your application. Oh the havoc they could wreak!

Switching to a 3-tier model moves the database credentials onto the middle tier and off the client workstations. Now the workstations have credentials to the app server, but not the database. A would-be hacker must crack into the app server to get those credentials. And end users are almost automatically shut out, because they would have to be a hacker to get to the app server to get the database credentials.

Way back at Tech Ed last year I was interviewed by my friend Ted Neward. The topic is CSLA .NET, and the interview ranges all over the place, from architecture, to the origin of the "CSLA" acronym to some of my thoughts on service-oriented architecture. It was long enough that they broke it into two parts. You can view or download them using the links below.

RSS Details

Component Based Scalable Logical Architecture - Part 1 (video)

Component Based Scalable Logical Architecture - Part 2 (video)

I've been working all day on this WPF/WCF application, mostly trying to figure out how to configure WCF to actually do what I want in terms of security and authentication. All those angle brackets from the config files have given me a splitting headache... WCF may be cool, but configuring even relatively simple security scenarios is ridiculously difficult.

And then distaster struck. As though fighting with WCF and SSL wasn't enough, VS 2008 decided to quit publishing my app for ClickOnce. In order to test this app, I need to publish for ClickOnce on my dev box, copy the results to a test server and then run the code on a test client (thankfully we live in an age of virtual machines!!).

So the failure to publish to ClickOnce brought me up short. The issue is that the WPF project wouldn't build. It would build and run fine in all other ways, but not when I tried to publish for ClickOnce. It had been publishing just fine, and then BOOM!

(The only thing I can think of is that I was publishing for online only, then I published for online/offline, and then I switched back to online only - maybe VS doesn't like that sort of waffling and wants me to be more decisive?)

The specific problem is that the .g.i.cs files for each XAML source file that should have been in the obj\Debug directory didn't get there. Google was no help - searching for "clickonce publish .g.i.cs obj\Debug could not be found" resulted in one hit - to an MSDN forums post that was unreachable (I kept getting an MSDN forums error page).

Build|Clean Solution had no effect. Shutting down and reopening VS had no effect. Rebooting the dev box had no effect.

Finally I thought to manually delete the obj and bin folders in the project directory. And for good measure I deleted the .user file and .suo file for the project and solution. Then I reopened the project and it how publishes just fine.

I love the holiday season! This is one of my favorite times of the year, especially in a year like this when Minnesota is actually having a real winter for a change (first time in seven years they say). We are on track for a white Christmas once again!

A few years ago I joined the Eden Prairie Optimist Club. This is a community service organization focused entirely on supporting and encouraging youth in positive ways. We provide funds to anti-drug programs and help to deliver food and clothing for those who can't afford it. We also offer scholarships through speech and essay contests and coordinate community activities like Take a Kid Fishing, Kite Flying Day, Firearms Safety classes and the annual Halloween party at the local shopping mall.

I joined the group because I felt horribly disconnected from the physical community in which I live. Magenic is a consulting company, which means the employees live in various cities around the country. Even those that live here in the Twin Cities live scattered throughout the metro area, and only a few live near me. And given all my writing and speaking, I am at least as connected to friends and colleagues from around the globe as I am to people within Magenic.

Not that I'm complaining! I absolutely love the fact that I can go almost anywhere in the world and know that there are people there with whom I've at least traded emails if not met in person. Living the virtual lifestyle is a wonderful thing! I think that if more people made more connections around the globe it would help them break out of their petty little religious/nationalistic/dogmatic/tribal/factional world views and understand that mankind is more alike than different.

As wonderful as it is to be connected to people around the world, I also think it is important to remain in touch with the local, non-virtual world. With the people that physically surround me and my family. I may have less in common with many local people from the perspective of career or interests, but I have more in common in terms of local concerns like civil discourse, roads, taxes, parks and schools. The quality of my life and the lives of my family flows, in large part, from this local community. The Optimists provide a nice way to stay connected, and to contribute, to this community in which I live.

Our only fundraiser is selling Christmas trees each December.

Personally I love it. Most people coming in to buy a tree are in good cheer - or at least one is in each group. Often one spouse is enthused, and the other has been dragged there, but the kids are always having a great time :)  Most of our business is repeat business - people who buy their tree from us either because they want the money to go to youth, or because we just have good trees. The majority of people are regular local citizens, but some are also local personalities like sports stars, politicians or civil servants.

There's no doubt that it takes a lot of time because we're open every evening and all day on weekends. All staffed by people with jobs and families of their own, along with (especially this year) a ton of youth volunteers from the local schools. And it can be hard work (some of the bigger trees are really heavy, even for a big guy like me). But the end result is well worth it - smiling happy faces of kids (and often adults), and the knowledge that all the money we bring in will go back into some pretty darn cool youth programs over the next year.

Having done this for three years now, I can say that I'm getting what I wanted - a connection to the people I live with in my community, and a way of making that community a better place.

Happy Holidays everyone!

I rather expected this - a bit of confusion around .NET versions and related CSLA .NET versions.

Microsoft started the whole thing by calling .NET 2.5 version 3.0. Oops, did I say that out loud? :)

But it is true. From a .NET programming perspective, 3.0 is purely additive over 2.0. Thus it is really hard to see why it is a major version.

Especially when .NET 3.5 has a much bigger impact on day-to-day use of .NET, but is just a point release... If anything, this should have been .NET 4.0, but it isn't and so now we're all royally stuck in the land of confusion.

Nothing to do but make the best of it.

I know several people and organizations who ignored .NET 3.0, but are now looking to move to .NET 3.5. Effectively "skipping" 3.0, though the reality is that their move to 3.5 is also a move to 3.0. Personally I think that's smart - they saved themselves a year of pain by not trying to use .NET 3.0 with the limited tools available, and can now move to 3.0/3.5 with Visual Studio 2008 - so they have decent tool support for the technology.

When it comes to CSLA .NET, here's my take on it:

• CSLA .NET 1.5.3 - latest version for .NET 1.x
• CSLA .NET 2.1.4 - effectively obsolete
• CSLA .NET 3.0.3 - latest version for .NET 2.0 and .NET 3.0
• CSLA .NET 3.5.0 - in-progress version supporting .NET 3.5

At this time I do not anticipate being able to make CSLA 3.5 work without .NET 3.5, primarily due to use of new compiler features as well as LINQ and features in .NET 2.0a and 3.0a (aka .NET 2.0 SP1 and 3.0 SP1).

There's been a lot of activity in CSLA .NET, moving toward version 3.5.

Aaron (my colleague at Magenic) has implemented indexed queries over CSLA collections in LINQ to Objects. So when you run a LINQ query against a CSLA collection (BusinessListBase, ReadOnlyListBase) and the where clause uses an indexed property the query will be much faster. You control which of your properties are indexed by using an attribute in the child business class on each property.

Aaron is now working on ensuring that non-projection queries against a CSLA collection result in a live updatable "view" of the original collection. Much like the way SortedBindingList and FilteredBindingList work today. So a non-projection query will not result in a simple, disconnected IEnumerable<T>, but will result in something richer and more natural to use.

In the meantime, I've been tackling items off the wish list. If you look at the list, you'll see quite a bit of green, indicating items that are (or will be) complete in 3.5.

Some highlights include:

• The code to declare a property has been reduced by more than 30% per property, and I've minimized the use of string literal property names for maintainability of code.
• Added a child management concept so parent objects can automatically manage their children so you don't have to override IsValid/IsDirty, cascading events or resetting edit levels when using lazy loading. The result is code that is smaller and more maintainable.
• SmartDate now supports type conversion, making it far easier to get values to/from string, DateTime and the new DateTimeOffset type.
• DataMapper now does much richer type coercion, using IConvertible and value converters if they exist (like they now do for SmartDate). This is just the start of the DataMapper enhancements - watch for more.
• A variety of small, but often important, changes and enhancements around validation rules and broken rules. These changes enable several important scenarios, especially around the consumption of broken rule data.