How to evolve a .NET codebase over versions of .NET

Question

I have a set of .NET components that were developed long ago (1.1). I would like to continue to provide them for 1.1 for any clients that need that version, but also offer versions - in some cases the same code, in some cases with enhancements - for .NET 2 and for .NET 3(.5). In each later case, I might want to take advantages of newer features of the platform for certain components.

I'm looking for guidance as to what the best practice is in this situation.

In the case where I am not looking to make any changes to a component, then I imagine I could still supply it as 1.1 and later libraries/applications could just consume the 1.1 assemblies as is. I suspect there might still be good reasons to provide assemblies built with later versions of .NET - e.g. performance - but my understanding is that I could just supply the 1.1. Is this correct?

In the case where I want to keep the bulk of a component's code working with 1.1, but also add features for later versions of .NET, what's the best approach?

• Separate branches of code
• C# pre-processor
• Supply the functionality in separate (new) classes for the .NET 2+ versions, and use the original via, say, composition
• some other advanced .NET trick I don't yet know about

Also, any advice on what to do with the assembly signing would be greatly appreciated.

Thanks in advance

Answer 1

In my rather harsh opinion, it's way past time to stop supporting .NET 1.1. The only good reason I can think of for still using .NET 1.1 is if you still have to support hardware that .NET 2.0 does not support - and at this late date, I'm not sure we can call that a good reason.

In fact, aside from hardware support, I don't think I've heard of any valid reasons for a machine to not be upgraded to .NET 3.5 SP1. As far as .NET 2.0 applications are concerned, .NET 3.5 SP1 is just .NET 2.0 SP2. You've got to wonder why someone doesn't want to implement a service pack that's been out there almost a year now.

All the rest of .NET 3.0 and .NET 3.5 is just additional assemblies that can have no affect on code that does not use them.

So I'd balance my desire to serve all my customers against the continued cost of supporting .NET 1.1. Maybe you do continue to support it, but charge extra for support, and a lot more for any new features. Same thing, to a lesser extent, with .NET 2.0.

Another wilder thought: are we not enabling the .NET 1.1 companies by continuing to support them as though there were no additional expense in doing so? Are we really doing them any favors by helping them to keep their heads in the sand? Even if they're too busy to see it, it can't be long before some startup begins competing with them and winning a lot of their business away, not because they're a better company, but because they're using WCF and ASP.NET MVC and AJAX and all the cool features that the .NET 1.1 people can only dream about.