Porting existing code from C# 2.0 to C#3.0 and .Net 3.5 (possibly .net 4.0)

Question

Our one and only enterprise application suite has been developed over last 3 years using C# 2.0 on .Net 3.0. We use winforms and WCF heavily. The development tools is VS 2005 Pro / TFS 2005 / Resharper 3.1

As technical lead I obviously understand the benefits in a move to C#3.0 and .Net 3.5. But I want to convince management for a move to C#3.0, .Net 3.5, VS 2008 and TFS 2008. They will obviously be interested in things like productivity, cost, quality etc. Please suggest me some ideas on how best to make my case.

Given that this may not happen till mid next year am I better off to hold till VS 2010 and .Net 4.0 is out.

Answer 1

"If we don't upgrade to newer technologies, it will be more difficult to hire good developers, and those who we already have will be fleeing soon... probably including myself..."

Answer 2

Is there much in .NET 4.0 which will benefit you? C# 4 itself doesn't have many new features... whereas I'd expect you could make good use of the C# 3 features. .NET 4.0 does have some very cool things (in particular Code Contracts and Parallel Extensions) but you should really look at what you would use.

If management is nervous about changing framework version, you could upgrade to VS2008 and use C# 3 but still target .NET 2.0. (Most of the C# 3 features still work when targeting .NET 2.0.) Using LINQBridge you could even still use LINQ to Objects, which is hugely beneficial IMO.

Of course if you can upgrade to .NET 3.5, you'll clearly get more opportunities for LINQ goodness, etc.

Answer 3

You will have to upgrade from C# 2.0 to get LINQ. This technology is very powerful, not only for querying databases, but for development in general.

Upgrading should (at least in theory) be easy. You recompile and pay attention to warnings about obsoleted calls.

Answer 4

1. Whip out the Microsoft expiration schedule on technologies, figure out how long your current solution set will be supported.
2. Look to things like Linq-to-Entities. If you don't currently have an ORM, this is a huge time saver.
3. It's always easier to upgrade version by version than it is to jump several versions. I learned this over time. Step by step upgrades were almost always painless. Upgrades that jumped multiple versions required a signficantly larger amount of extra code and testing.
4. Identify the top 5 features in your "nice to have list". How many of them are only provided by, or provided in a better way, by the new version?
5. Don't push for bleeding edge. There's a cost to being on the very edge of emerging technology. That cost is often very hard to justify from a business standpoint.
6. You have change code anyways. Figure up the cost of the next X feature changes. Try to roll it into a release. "We can do it as part of XYZ release with only NN extra hours, saving MM hours over the next six months".
7. Look around the web for stats on code rollover. Most custom systems are "rewritten" gradually over time as the business process changes. However management tends to view software as a "write once, use forever" endeavor with only some maintenance costs. Make sure they understand that this is them taking control of the upgrade process, and them guiding the future of their tool in a planned fashion, as opposed to just whatever comes out after dozens of minor changes.

Edit: This all assumes that there actually is a cost justification, which you will hopefully answer for yourself while going down this list.

Answer 5

The biggest problems I've ever run into when trying to upgrade an enterprise application and convincing management was because of the deployment cost. When you upgrade to .NET 3.5, all your clients will have to get the 3.5 framework. Depending on your end user audience, this could be a big deal. That was the holding factor for management whenever we tried to pitch it. The language features, framework features, and other benefits/costs really didn't matter much to them. The deployment cost kept ringing in their ears. If you can make the deployment cost minimal (i.e. you might roll the 3.5 framework into the next install or something), then you'll probably be able to show that the productivity benefits far outweight the costs. Otherwise you might find yourself in the situation I found myself in.

Answer 6

I don't think any productivity gained by going from C# 2.0 to C# 3.0 can be easily justified for a particular project. Rather than try to justify moving to the new version of the language, think about why you wouldn't?

1. Does the group want to stay with VS2005 forever, or are they planning on moving to VS2008 some day. If they want to stay at VS2005, consider the fact that that compiler is now on extended support, pretty soon it won't be supported at all, and you won't be able to get even security updates, similar to VC6. Furthermore, the new version of Microsoft's SDL (5.0) requires the use VS2008 or later.

2. If the group is willing to move to VS2008 eventually, then determine if you can work in a mixed mode environment. This can work effectively if you have a large code base, so new components are built with the newer tools.

3. Once the team / project has moved to VS2008, then using C# 3.0 features as opposed to sticking to the C# 2.0 subset shouldn't really be an issue.

4. For VSTS, the best thing to do is to try to use it on a new project.