I recently branched the CSLA .NET codebase in the svn repository (www.lhotka.net/cslacvs for a web view).

Version 3.0.3, which is the maintenance branch for the current 3.0.2 version, is on a branch now. This is a VS 2005 solution (though ProjectTracker does include some VS 2008 projects for .NET 3.0 concepts).

Active development is still on the trunk, and is for version 3.5. I'll be switching that version to a VS 2008 solution in the near future.

Switching to VS 2008 is a big deal. I realize that many people will be using VS 2005 for a long time to come, and so I don't do this lightly.

However, CSLA .NET 3.5 will include features around LINQ and other .NET 3.5 concepts. As such, I must use VS 2008 to do that work, because that is the tool for .NET 3.5 (and really for .NET 3.0).

If possible, I'll continue to use the compiler directive approach to allow building Csla.dll for .NET 2.0, 3.0 and 3.5. Whether this is realistic or not depends on the level at which LINQ ends up integrating into the framework. If LINQ gets too deep, the complexity introduced by the compiler directive approach may become higher than I'm willing to deal with, at which point I'll drop that idea. But for now, my goal is to continue to allow backward targeting of the framework.

Fortunately VS 2008 itself also supports backward targeting, so it is possible to use VS 2008 to build assemblies for .NET 2.0, 3.0 or 3.5. This may help mitigate some of the pain of having the Csla project switch to 2008, because you can still use 2008 to build for a .NET 2.0 deployment environment.