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

This is where your build files are very crucial. Instead of using the preprocessor, I would use MSBuild (look up MSBee for compiling .NET 1.1 code using MSBuild) to create a build file which would specify how to build each platform-specific assembly.

Answer 2

I maintain a project for .NET 2.0, .NET 3.0, .NET 3.5 CF 2.0, CF 3.5, Mono 2.x and Silverlight 2.0 - I do most of this using a combination of project (build) files and #if directives, to minimise/localise the amount of duplicated code.

Mostly I output the same dlls - although I have created some 3.5-specific dlls to cover things like extension methods.

An important job is to make sure you set this up so that you can build/test them all quickly - for example, I have a single "build.bat" that will check that it compiles in all of them (it is really easy to introduce illegal syntax).

For 1.1, I imagine you could use MSBee, but you might need a "csc" - but there are some pretty fundamental changes (such as no generics), so it might be an order of magnitude harder...

Answer 3

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.

Answer 4

This seems like the sort of thing that could get messy pretty quickly. You’re either going to end up maintaining multiple streams of the same codebase targeting different frameworks (in which case you’ll definitely want to consider branches in your SCM) or you’ll be decomposing functionality into classes which perform discrete tasks for different frameworks.

I think it will mostly come down to how you expect the codebase to grow in the future. If you’re expecting limited changes to the superseded versions I’d just go ahead and branch with most of the new functionality going into the latest generation .NET to leverage the new language features. Most of your new features arrived in 3.0 and 3.5 so my preference would be to try and move customers towards them if possible; they get the new language and you get to focus your attention on building to predominantly one framework.