When should new .NET projects be designed for .NET 4 Framework

Question

I am preparing to start on a new short-term contract (1-2 months) that involves replacing an Access application by moving it to ASP.NET and SQL Server.

I am only responsible for the ASP part and connecting it to the database.

The only requirement is that whatever technologies I use be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.

So, I could do this in Rails or ASP.NET, but, when should the development be aiming for .NET 4 Framework, as there are many changes coming out that may be advantageous to use.

Or, even though it may be useful, when is it better to just ignore new features and stay on an older version of .NET?

I am assuming that hardware isn't the limitation, as many computers won't be able to run .NET 4 Framework, but that would be an issue for a hosting company, as they can find a hosting company to support whichever framework the application is designed for. If Rails makes the most sense, as their hope is to have the application written quickly, but have it reliable, then again, the hosting company would need to support it, or they use a different one.

This company hasn't used a hosting company, they need to find one, so there isn't a relationship that could be an issue.

UPDATE: Part of my concern is that initially the application will not require javascript, but phase 2 will be to make it more interactive, as some clients won't be allowed to have javascript on their computers. In order to limit how much javascript must be known by a developer there are frameworks that will adapt to browsers and situations fairly well, which is why I am also thinking about RoR and the fact that there appears to be changes coming out in .NET 4 that may help with this.

Answer 1

As a general rule of thumb, I wait one year before building sites in a new framework unless the client specifically asks for the newest technology. This has worked out very well for me. The advantages are:

• The technology is much more stable (hotfixes, service packs, etc.)
• Common complaints about missing functionality are usually resolved
• Hosting companies, support communities and corporate IT departments have had time to get used to the technology, find out more about it, play around with it and have it mature within their organization

Unless there is specific need for new functionality introduced by .Net 4, there is no point in subjecting your clients to the immediate problems with an initial release, or making it more difficult for them to find hosting. You should either investigate all of this up-front, or use .Net 3.5 in the meantime.

Answer 2

Generally speaking it's going to be easier finding hosting for a Rails app. If you want to run .net 4.0 you're probably going to have to run a VPS or dedicated machine. However if you're bailing after the application is finished and assuming your client is in Knoxville, they're going to have a tougher time finding a Rails developer to maintain the application.

I think the bigger question is your role. They're looking to you to solve this problem for them. Are you productive in both technologies? How about getting a Windows server up and running? A Linux server? How's your SQL Server vs MySql? I'd guess that you're probably stronger on one stack vs the other - for a contract that short I wouldn't want to be doing a lot of experimental development.

Answer 3

The only requirement is that whatever technologies I use that it be relatively well-known in the area, so that if they need to have someone else work on it, it isn't specialized knowledge.

I would have thought that requirement was enough not to develop this project on .NET 4.0 - it takes time for a new framework version to filter down into the market, and it will be a while yet before there are a lot of developers around with .NET 4.0 experience.

Also, you would be essentially developing on top of a BETA product - while I'm sure most of the features will remain unbroken from BETA -> RTM, there is always a risk that something will break or not work like it did in BETA, so why risk this on a commercial project?

I wouldn't target .NET 4.0 yet on a commercial project unless there was a specific reason for doing so, and even then you would have to have buy-in from the client, ie "I can do this much more quickly and with less effort if we use the current beta version X rather than established, stable version Y" - good luck with that.

I worked on a commercial project that used the CTP version of LINQ to SQL - then when we went to VS2008 / 3.5, suddenly everything changed and we had to make a lot of changes just to get LINQ to SQL working again.

Stick with 3.5 - it's easier for hosting and getting developers.

Answer 4

i wait until the OS that everyone will be using has it.

Just last month i took a dependancy on GDI+, which first shipped with Windows XP.

Answer 5

Just a couple of thoughts, I wouldn't even think about creating an application for production use in .NET 4/ASP.NET 4 until:

1. There is a release candidate. It's not the first time I've seen features in beta's not make it to RC/RTM.
2. Microsoft have permitted development and deployment of production applications by way of a 'Go Live' license.

There are some hosters out in the market such as OrcsWeb who are participating in public beta testing, but they aren't intended for production use.

I'd run with the .NET 3.5/ASP.NET 2.0 or MVC bits for now. Better safe than sorry.