CSLA .NET version 3.5 is for Visual Studio 2008 and .NET 3.5 only.

If you are using .NET 3.0 or .NET 2.0 then CSLA .NET version 3.0.x is for you. Version 3.0.4 is a maintenance release incorporating some important bug fixes, especially around data binding.

Version 3.0.4 will release concurrently with version 3.5, and I have put a refresh of the 3.0.4 code online for download at www.lhotka.net/cslanet/download.aspx.

This release is quite stable, and you should consider using it if the bug fixes apply to you. See the change log for details.

CSLA .NET version 3.5 Beta 2 is now available for download from www.lhotka.net/cslanet/download.aspx.

Please read the change log prior to installing/using this release. If you are coming from version 3.0 or lower there are a few potential breaking changes. If you are coming from 3.5 Beta 1 there is one potential breaking change.

There are numerous bug fixes and feature tweaks from Beta 1 to Beta 2. These are thanks to the great feedback and help I've recieved from numerous people on the CSLA forum (http://forums.lhotka.net/) - thank you all for your help!!!

I am excited to release Beta 2, because we're narrowing in on a final release of version 3.5 and any changes now will be bug fixes or stabilization. Any testing you can do on this new release is appreciated and will help ensure high quality in the final release.

Hear ye, hear ye!  MIX08 to debut the first ever MIX UX Track which is 3 days of solid content dedicated to creatives / designers.  Lou Carbone, David Armano, Dan Roam, Kim Lenox and others will speak.  In conjunction with Adaptive Path, the User Experience track is just one of the many great reasons for all types of designers and creative professionals to attend MIX this year.  http://visitmix.com/2008/mixux.aspx

The deadline for this year’s CSS contest, RESTYLE, has been extended.  Folks can still restyle the MIX08 Homepage and win a pass to MIX08, 3 nights at the Venetian, $$ and more, more, more! http://visitmix.com/2008/restyle/

Have you been listening to The Signal?  Each week a new episode debuts featuring a speaker or MIX crew member talking about some of the upcoming coolness happening at MIX08.  Listen to their interviews with Molly Holzschlag, Kip Kniskern, Jonathan Snook and others as we countdown to Vegas.  http://visitmix.com/blogs/TheSignal/

Perhaps you remembered last year’s MIX, in which we featured Flotzam, a WPF screensaver mash-up that showed MIX07 feeds from Facebook, Flickr, Twitter and blogs. Well, we are doing it again this year with a twist: we are running a contest and will feature community created skins of the application on the big screen and on the screensavers of the computers available to attendees at the show.  The best skin will win an XBOX 360.  Entering the contest is easy: everything you need to know can be found here http://www.visitmix.com/blogs/News/403/ including links to screencasts and instructions that show how easy it is to do the restyle.  

Just to let everyone know, there's a CSLA .NET training class coming up in Atlanta Feb 18-20. The class is organized by Dunn Training, who has been delivering this quality training for over a year now, with great feedback from attendees!

Click here for details.

I reader recently sent me an email asking why the PTWebService project in the CSLA .NET ProjectTracker reference app has support for using the data portal to talk to an application server. His understanding was that web services were end points, and that they should just talk to the database directly. Here's my answer:

A web service is just like any regular web application. The only meaningful difference is that it exposes XML instead of HTML.

Web applications often need to talk to application servers. While you are correct – it is ideal to build web apps in a 2-tier model, there are valid reasons (mostly around security) why organizations choose to build them using a 3-tier model.

The most common scenario (probably used by 40% of all organizations) is to put a second firewall between the web server and any internal servers. The web server is then never allowed to talk to the database directly (for security reasons), and instead is required to talk through that second firewall to an app server, which talks to the database.

The data portal in CSLA .NET helps address this issue, by allowing a web application to talk to an app server using several possible technologies. Since different organizations allow different technologies to penetrate that second firewall this flexibility is important.

Additionally, the data portal exists for other scenarios, like Windows Forms or WPF applications. It would be impractical for me to create different versions of CSLA for different types of application interface. In fact that would defeat the whole point of the framework – which is to provide a consistent and unified environment for building business layers that support all valid interface types (Windows, Web, WPF, Workflow, web service, WCF service, console, etc).

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