Home » Blog

LightSpeed 3 and .NET 3.5

Tagged as LightSpeed, Products

In versions 1 and 2 of LightSpeed we consciously chose to keep the core framework compatible with .NET 2.0, adding 3.x features such as LINQ and Dynamic Data only via additional libraries. With the increasing deployment of .NET 3.5 and .NET 3.5 SP1 (or “.NET 3.8″ as we are not allowed to call it), and the data-related features in those releases, we’re having to re-evaluate that baseline for LightSpeed 3.

The reason is that some of the features we’d like to support require us to implement interfaces or attributes against core classes such as Entity or EntityCollection. For example, suppose we decided that we wanted to implement INotifyCollectionChanged on EntityCollection as part of improving WPF support, or to implement INotifyPropertyChanging on Entity in order to facilitate user undo mechanisms. We couldn’t add these features via an add-on library: the interfaces would have to be on the EntityCollection or Entity classes in the core framework. Which means the core framework DLL would incur a dependency on .NET 3.5 SP1.

On the other hand, not everybody’s using .NET 3.5 SP1. Enterprise environments in particular can be slow to adopt new versions of the framework, and requiring the latest version can incur resistance from IT administrators. Mono users enjoy a pretty complete 2.0 feature set and some 3.5 features, but not everything. Obviously people in those environments won’t be able to use features that depend on 3.5 SP1, but we’d like to have a graceful degradation path, so that they can still use the many features of LightSpeed that don’t depend on the latest framework version.

So here’s our current plan. We’re going to bite the bullet and take the 3.5 SP1 dependency in the core. This allows us to move forward with things like WCF support, ADO.NET Data Services, etc. which are troublesome or impossible to do in add-on libraries.

But we’ll also ship a 2.0-compatible version of the LightSpeed DLL. This will be built off the same codebase as the main assembly, but with 3.x-specific dependencies removed so that it can be used in a 2.0 environment. We expect that the compatibility build will be feature-complete relative to the main assembly, except that it won’t be usable with 3.x-only technologies.

Furthermore, where we can ship 3.x features via add-on libraries, we still will. So, for example, LINQ support in LightSpeed 3 will still be provided by an additional assembly, rather than baked into the core. This isn’t technically strictly necessary, but it makes it easier for us to maintain the 2.0 compatibility build — less stuff to #ifdef out!

We think this is the best way to allow LightSpeed to move forward with the new capabilities of the .NET platform while still maximising reach for more conservative deployment environments. We recognise a couple of downsides: potential confusion over having two builds of the LightSpeed DLL, and a lack of granularity (it’s an all or nothing choice of 3.5 SP1, the latest version of the platform, or 2.0, which is pretty long in the tooth).

We’re always keen to hear feedback from users, so please let us know your thoughts on this. What framework versions are you targeting now? Would a 3.5 SP1 dependency be a dealbreaker for you? Do features like ADO.NET Data Services justify jumping all the way to SP1 or should we make 3.0 or 3.5 our primary target? Would a compatibility build be useful for you? Tell what you think in the comments!

Add your comments
Posted by Ivan Towlson on 23 March 2009

6 Responses to “LightSpeed 3 and .NET 3.5”

1. I approve. If you’re going to keep a 2.0 version then you might as well jump all the way up to 3.5 SP1.

   James Newton-King Mar 24th, 2009

2. That is a fine initiative and a sound approach. I second JNK.

   A.H. Johannessen Mar 24th, 2009

3. 3.5 SP1 will be great.
   I would also consider if 4.X provides any other features you want add.

   MiddleTommy Mar 24th, 2009

4. Jump into 3.5 SP1 and don’t look back. ADO.NET Data Services and newer technologies do justify the decision.

   Too many cycles get wasted in trying to hold onto the past and stunt future development.

   David Hayden Mar 24th, 2009

5. We’re all 3.5 sp 1. .Net version upgrades are so easy, I’ve never felt the need to stick with an older version.

   Luke Duff Mar 24th, 2009

6. As others have said, upgrading .NET is less of an issue, even in big corporates. People have the choice of staying with the existing version if they can’t/won’t upgrade.
   If there is an ongoing cost and loss in productivity for you doing it this way I, from a purely selfish point of view, would prefer to get more future features than historical support.

   Alastair Upton Jun 11th, 2009

Leave a Reply