For the moment we're still working with the 2.0 framework and and although 2.0 provides all the necessary we need for the moment, we'll have to move on to 3.5 sooner or later. The other day there was an in house discussion going on whether there is any risk involved in this upgrade, and this risk was not to be taken lightly since all our clients are still using the 2.0 framework. There was a colleague who stated that it would be safer to just recompile all our products against the 3.5 framework en do complete new roll out. This would tackle any compatibility issues. A lot of work indeed and maybe unnecessary, I believe that wen Microsoft grantees that the framework is backward compatible why should we have any doubts about it? Am I right about this?
The biggest thing I noticed was that installing .net 3.5, you get .net 2.0 SP1. Hanselman has a post showing the changes ("red bits").
Personally, I had no problems if that makes you feel better.
It isn't 100%.... most importantly, 3.5 and 3.5SP1 both include service packs to 2.0 and (later) 3.0; these changes aren't all trivial.
As a key one; if you start using types in SP1 even in what you think is 2.0, it will fail on a "proper" 2.0 client. There is an FX cop tool to help avoid this, IIRC. Second, there are (in the service pack) changes to things deep in the core - the number of pool threads, for example (or is it the stack size of pool threads... something in that area) that can bite you if you are unlucky.
Also, there are bug-fixes in the 2.0 code; if you happen (by chance) to be relying on a behaviour that changes in the service pack (SP1/SP2)...
But also don't forget that you have this problem now; if your clients have installed .NET 3.5, then they have taken the 2.0 service pack(s) ;-p
So don't completely dismiss it - but if you take suitable precautions (with testing) and it should be achievable.
Not completely. .NET 3.5 installs a service pack for .NET 2.0 so the risk is non-zero. We have an application that has failed since upgrading to .NET 3.5 - the current row of a binding source in a WinForms app behaves differently in some circumstances we haven't yet fully analyzed.
I don't think a recompile will make any difference (it certainly didn't in the above case), but there is a small risk that the upgrade will cause problems and you will need to do some regression testing.
When we migrated from 2.0 Framework to 3.5 we were able to do it with out any issues. Reason being is the 3.5 framework is essentially an extension to the 2.0 framework, which is why when you go into IIS to set the .NET framework for the website you see .NET 2.0 but not 3.0 / 3.5 (as an example).
Now as for the concern with your clients still using 2.0 framework, what you'll need to make sure happens is that your developers set thier IDE to complie in VS2008 against the 2.0 framework and not 3.5 until your clients have upgrades. This is to ensure that the any 3.5 features such as LINQ are not utilized and compiled into the app and causing errors when your app is deployed.
An important thing to note is that .NET 3.0, 3.5, and 3.5SP1 are not new runtimes. All four "frameworks" run on the .NET 2.0 runtime (CLI, CLR, GC). The .NET 3.0 and 3.5 frameworks are really extensions to the .NET 2.0 framework. Using .NET 3.0 and 3.5 generally incur no issues...however .NET 3.5 SP1 included some updated versions of existing .NET 2.0 classes that either added to or changed method signatures or behavior in a few (very few) cases. The chance that you will run into one of these issues is very very low, but the chance is there none the less:
http://forums.asp.net/t/1305800.aspx http://www.hanselman.com/blog/UpdateOnNETFramework35SP1AndWindowsUpdate.aspx