Friday, December 07, 2007
« CSLA .NET 3.5 status update (Dec 5) | Main | Enjoying the Holiday Season »

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


Friday, December 07, 2007 2:50:45 PM (Central Standard Time, UTC-06:00)
"I know several people and organizations who ignored .NET 3.0, but are now looking to move to .NET 3.5. "

I'll up the ante by saying that we are planning a move from 1.1 to 3.5; skipping right over 2.0 as well. Well, sort of. Curse you MS Marketing and your "versions".

And for those whose memories have faded, yes, doing things in 1.1 is painful. Really painful. Especially in ASP.NET. Not a week goes by where I don't suggest something only to realize after saying it that it's a 2.0 feature.

Garrrr...
Friday, December 07, 2007 3:39:50 PM (Central Standard Time, UTC-06:00)
I would have been even more strict on the naming. Considering that 3.0 and 2.0 use the same runtime version I would have called it .Net 2.0 Option Pack 1 (ala the old NT Option Packs from way back in the day)
Jimmy Zimms
Saturday, December 08, 2007 7:22:50 PM (Central Standard Time, UTC-06:00)
I totally agree.

Microsoft should start once and for all a more intuitive version scheme for the .NET framework.

When we at our company moved our solution from version 1.1 to 2.0 we thought that we made a major step, just to realize that after few months there was a version 3.0 coming, which is to be immediately put in shadow by a beta version of 3.5.

We were all like hey what is wrong with us, are we to slow or do we need to plan a new upgrading strategy, since we want to always be at most one version behind.

.NET has reached version 3.5 in what 5 years?
And in 5 years .NET 1.0 Supports Ends!

Common guys, this is becoming little bit ridiculous, isn't it - or is it just me. :)
Visar Elmazi
Thursday, December 20, 2007 11:14:54 AM (Central Standard Time, UTC-06:00)
Rocky,
I'm currently working on a project that was started using a 2.0x template but is new development so I was considering whether it made sense to move forward on a newer version of the framework. If I was to move to 3.0 do I need to read both the 2.14 online book and the 3.0 online book to get caught up; or can I just skip to 3.0? Also do you know of any codegen templates for 3.0 all the ones I've found are somewhat dated at this point.
Thanks,
Marc
Marc Ziss
Friday, December 21, 2007 10:21:17 AM (Central Standard Time, UTC-06:00)
Moving from CSLA 2.0 to 2.1 takes some effort, because there are a number of potential breaking changes in the way validation rules are used. Those same issues obviously exist if you go from 2.0 to 3.0. The explanations for the changes and how to use the new features of 2.1 are in the "CSLA .NET Version 2.1 Handbook".

Moving from 2.1 to 3.0 is a non-issue with one exception, which I'll discuss in the next paragraph. The last 2.x version is 2.1.4. You can think of 3.0 as being 2.1.5 if you don't use any .NET 3.0 features (WPF, WCF, WF). In other words, 3.0 includes some bug fixes and enhancements over 2.1.4, but without the .NET 3.0 support it wouldn't have been a major release.

The one issue people hit when moving to 3.0 is that CSLA now throws some exceptions when n-level undo edit levels get out of sync. These exceptions help debug issues in UI code that uses n-level undo, and it turns out that almost everyone (including me) has a lot of bugs in their UI code in this area. Usually they are due to accidental misuse of data binding in Windows Forms.

While these exceptions make the move to 3.0 more difficult, they also help you fix a whole set of bugs in the UI, and the results are much more stable and predictable applications - so this is a worthwhile effort, and in my view is a primary reason for upgrading to 3.0.

All the 3.0 enhancements and bug fixes (and the .NET 3.0 support) are explained in the "Using CSLA .NET 3.0" book.

If it were me, I'd go directly from 2.0 to 3.0, but you will probably need both ebooks to understand all the changes.
Monday, December 24, 2007 10:22:49 AM (Central Standard Time, UTC-06:00)
I'm working on a web app so it sounds like the hurdle will be moving up to 2.14; once I get there it sounds like it will cost me nothing to move up to 3.0 so might as well ride the upgrade train all the way to the end of the line. So it looks like I've got some reading to do. Thanks for your help
Marc
Marc Ziss
Comments are closed.