views:

1977

answers:

14

My application uses 2.0. At some point in the future I may want to start using newer features added in later framework versions. Should I wait until then? Or are there advantages to updating to the latest .NET 3.5 now?

I suppose by the time I am ready for next spring's release 4.0 will be out. Perhaps I should stick with 2.0 for my fall release and save my customers the HD space and install time of another framework version?

Thanks in advance,

-Ed

+8  A: 

In my opinion, you should ship with what your app needs. Otherwise you are making your install longer for no reason and as you noted using your customer's HD space again essentially for no reason.

EBGreen
It isn't just HDD space -- it maximises the chance that your customer has the prerequisites already installed, and reduces the number of changes you have to make to their machines.
Nader Shirazie
A: 

I appreciate the new language features in .NET 3.5 but until you're making use of them I would avoid upgrading to the latest runtime as it is a larger file / install that your users may have to deal with.

Ryan Lanciaux
The "new language features" are not really in .NET 3.5, they're in VS2008. You can still use C#3 with the .NET framework 2.0
Will Dean
For compiler features like LINQ and extension methods, you don't need to target a newer version of the framework. All you need is to include an implementation. For eg, Mono provides an implementation of LINQ to objects.
Nader Shirazie
A: 

The Linq to SQL features, well really pretty much the Linq Extensions in general are well worth the upgrade.

As for your worries about HD space and install time, IMO these are not relevant on most modern systems for the newer frameworks. The newer versions of the frameworks (3.0 and 3.5) are really just "refreshes" of the 2.0 framework. Unless your customers/market is older PC's I think you will get a good tradeoff in functionality and productivity for your dev team as opposed to the negligible risk of losing customers because they can't risk adding another 20Mb on their hard drive (I made up the 20mb number, someone can call BS on that).

A: 

3.5 framework has had it's first Service Pack release, so it's more stable than it was after release, but bear in mind it is far easier to upgrade code from 2.0 to 3.5 than it is to go back to 3.5 if for whatever reason you encounter a show stopper.

The wiki article shows the new features very well.

digiguru
+1  A: 

You should distribute your app with whatever version of .Net is the version you've done the most testing against. If you've been doing all your developing and testing in .Net 2.0, then ship with 2.0.

But you may owe it to your customers to test against 3.5 and ship with that, instead, for the sake of any bugs that have been fixed in the framework since 2.0 was released. The framework is already so large that there probably isn't any benefit to distributing an earlier version, even if it came before WCF, WPF, etc., unless you're paying bandwidth costs to distribute it, or the target device has limited storage space.

C. Lawrence Wenham
+2  A: 

I always use the most up-to-date version of the Framework. This may be a small up-front burden on users, but the app has a much longer life between upgrades. That may or may not be important to you, but consider:

If you had shipped an application in 2005 using .NET 1.1, the framework your app runs on is now out of mainstream support, and may have unpatched security vulnerabilities, or other serious problems which Microsoft may not deal with, and which you cannot compensate for in your own code. Your only alternative in 2008 is to get your users to upgrade their framework version now. And, as we all know, getting users to update things in a timely fashion can be problematic.

Likewise, consider your situation in 2011. If you program for .NET 3.5 now, your app, as-shipped, will be viable longer. If you ship for .NET 2.0 now, you'll be in the position, in a few years' time, of having to convince your users to upgrade their framework (code which has no perceived benefit to them, remember) so that you can properly support this application.

Also, if you plan to implement 3.5-class features (LINQ to SQL next year, for example), it's in your interest to ship for 3.5 now, rather than 2.0, as it will make deployment later less of a problem for you.

DannySmurf
+1  A: 

I agree with EBGreen and Chris, but I want to add that you might want to consider testing your application against the newer versions of the framework and allow your application to run against those versions you deem to work well against (this can be done using some configuration trick, but unfortunately, I can't find reference to it). This way, your application could work against the version the client may already have installed.

I suggest this because:

  1. New framework versions may give you a performance boost.
  2. The client may already have another version installed on their computer and it would be a shame to, as you say, waste hard drive space.
  3. You may want to run your application against a newer framework version sometime in the future and if your client already has that version and is running the current version of the application, there won't be an old framework on their computer.

Still, I'm lacking some information you may have, such as the means of distribution, the profiling of clients' machines, etc.

Omer van Kloeten
A: 

I've found version 2.0 to be the easiest version to target and deploy since a lot of people have it installed already, If a sizable portion of your client base use Vista you might consider upgrading to 3.0. Versions above that nearly always require an install which can be a pain for some users.

Edit: The "framework version going out of support" argument holds no water since 3.0 is an extension of 2.0 and 3.5 is an extension of that. By definition 2.0 will be supported as long as 3.5 is. Version 1.1 is the only version that is a completely separate runtime and is no longer supported.

rpetrich
+6  A: 

If you are planning to upgrade to 3.5 SP1, you should consider using the New .NET Framework Client Profile Setup Package.

.NET 3.5 SP1 introduces a new setup package option for developers building .NET client applications called the ".NET Framework Client Profile". This provides a new setup installer that enables a smaller, faster, and simpler installation experience for .NET client applications on machines that do not already have the .NET Framework installed.

The .NET Framework Client Profile setup contains just those assemblies and files in the .NET Framework that are typically used for client application scenarios. For example: it includes Windows Forms, WPF, and WCF. It does not include ASP.NET and those libraries and components used primarily for server scenarios. We expect this setup package to be about 26MB in size, and it can be downloaded and installed much quicker than the full .NET Framework setup package.

The assemblies and APIs in the .NET Framework Client setup package are 100% identical to those in the full .NET Framework setup package (they are literally the same binaries). This means that applications can target both the client profile and full profile of .NET 3.5 SP1 (no recompilation required). All .NET applications that work using the .NET Client Profile setup automatically work with the full .NET Framework.

Gulzar
A: 

One question I'd like to ask is what are the features of .NET 3.5 that you'd like to use? Many of the hyped features are actually C# 3.0 features, not features specific for .NET 3.0/3.5 and since C# 3.0 uses the same CLR as .NET Framework 2.0 you are free to use them in your 2.0 applications too. This only requires VS 2008.

Examples are: - Lambda expressions - Object initializers - Anonymous types - Local variable type inference - Extension methods

I use many of these in my own .NET 2.0 projects without problems.

If there are framework specific features you want (like Linq, WPF, etc), then you'd have to upgrade.

Geir-Tore Lindsve
A: 

I agree that you should with what your App needs, but you should also prepare for what your apps will need in the future.

If you have a few spare cycles, you could migrate a separate branch of your apps in your SCM which is running with the 3.5 Runtime and when you actually need to upgrade, you have a working branch (Assuming that you keep it up-to-date with some bi-weekly merge).

Shadow_x99
A: 

Don't forget that .Net 4.0 will be a little different from previous versions of the framework. .Net 4.0 will be installed side by side (SxS) .Net 3.5 and back. If you upgrade your app to use .Net 4.0 then your long term users (aka previous versions) will end up having to install a whole new version of the framework.

If your considering how much disk space you are going to use up on the client machines with your app and the framework, then don't forget this "hidden" use of extra space. If you upgrade your app now from 2.0 to 3.5 then your app might be able to exist longer with complete functionality without forcing the user to install a 2nd framework that uses up another 20+ MB of space.

Jason
+1  A: 

Remember that "a small burden" to users could mean the difference between acceptance and rejection of your application.

I run IT for a company. Our company standard is not 3.5. You would have to have one really slick application to get me to upgrade everyone to .NET 3.5 just so your app can run. In other words, probably not happening. I'll find another app that doesn't add an additional "small burden" onto our already overloaded IS department.

Somebody else commented about what features are you really going to use. If 1.1 or 2.0 has the real feature set you need stick with it.

A: 

.net 3.5sp1 bootstrapper is too slow especially if you are using asp.net application (compared to windows forms), in a machine which only has .net 2.0, it loads the whole framework and that means you are lookong at about 20-30 mins of download + install time on a moderate internet connection and machine speed.

Samuel