ASP.NET Framework effects of moving from 2.0 to 3.5?

Question

I've started using Visual Studio 2008 and it keeps asking me to upgrade my 2.0 website project to 3.5 every time it opens.

What effectively happens when I "upgrade" a website project from 2.0 to 3.5 in Visual Studio? Does it update my web.config? How exactly does it change my project/website/code?

Is there a potential for any 2.0 methods/settings to BREAK upon upgrade to 3.5?

Are there any gotchas involved?

(Thanks in advance for any guidance)

update: most comprehensive (yet concise) answer will be accepted.

Answer 1

It updates your web.config to use a few newer dlls. I have yet to experience any breaking changes.

Answer 2

As I understand it, .NET 3.5 is .NET 2.0 with some additional libraries, for new features like LINQ. Therefore, you should be able to upgrade seamlessly.

Answer 3

Is there a potential for any 2.0 methods/settings to BREAK upon upgrade to 3.5?

There's always potential for breakage but I suggest you back everything up and give it a go sooner rather than later. If you keep putting it off, you'll find it's a lot more painful when you have several versions of framework API changes to make up for.

Answer 4

If you upgrade the project type, it simply updates the .csproj/.vbproj files to work with the new version. You can set the targeted code base inside project settings to retain functionality on older framework versions.

Answer 5

If, in the upgrade wizard, you choose not to target your code to 3.5, nothing of your application will change. The main difference is that it will "visual-studify" your Solution and project files so that they potentially can't be opened by an older IDE.

Answer 6

All the changes will be in the web.config file. It grows HUGE with new settings for .NET 3.5 assemblies, AJAX handlers, and IIS7 configuration settings. But there are tons of documentations on the internet that describe the differences.

Answer 7

I have upgraded several projects this way and have had no breaking changes. As an experiment, I did this on a project that the rest of my team was using on VS2005 and also experienced no issues, though I made sure not to check in my solution file (which we keep locally as a matter of policy anyway).

The results have been transparent to all, with the added bonus of being able to target different .Net versions.

Answer 8

(As mentioned elsewhere across the other answers, plus some extras:)

• Converting a VS 2005 solution to VS 2008 will mean that you'll need to maintain duplicates, or others must also be using Visual Studio 2008 (while the project file format (which from your question you're not using anyway) is in theory unchanged between 2005 and 2008, the solution files are not compatible...)

• Converting the website to 3.5 mostly affects the web.config. Some references are added to a few default 3.5 assemblies, such as System.Core.dll. And it will add the IIS 7 sections (which is all ignored if the site is published to an IIS6 box).

• Generally don't see new compile time errors from the upgrade (and if you do, wouldn't expect many). Both the C# and VB teams have put effort into ensuring backwards compatibility on all the new LINQ keywords... so you can have a local named "var" in a method named "where" in a class named "from" and everything compiles just fine... (an improvement for anyone who had symbols named "operator" in a VB 2003 codebase when upgrading to 2005 :-)

• Obviously, once you've switched, you'll need .NET 3.5 on any server you deploy to. Unlike .NET 1.1 vs .NET 2.0 though, there are no CLR version / AppPool issues to worry about, it all runs in .NET 2.0. Read on below...

If you are worried about run-time regression for any existing .NET 2.0 code, there's good news and bad news.

The good news: regression is virtually unheard of.

The bad (or other good) news: If you've installed .NET 3.5 on a server running 2.0 sites, you've already tested for regressions :)

As mentioned above, .NET 3.5 is really just the .NET 2.0 CLR with some extra assemblies and new compiler functionality.

And when you install .NET 3.5, it also installs a service pack for .NET 2.0 and 3.0. So any breaking change would already be affecting .NET 2.0 websites, without any explicit upgrade step.

Scott Hanselman posted a good explanation of the difference between CLR version and .NET Runtime version here a while back.

One final comment - you should be aware that when using VS 2008 to target .NET 2.0, you are actually compiling against the updated .NET 2.0. So if you use one of the (very few, and rarely used) methods quietly added to the updated version of .NET 2.0, such as GCSettings.LatencyMode, when you deploy to a machine that has the original .NET 2.0 RTM, it will fail to run. Read about it in more detail here, and Scott also posted a full list of API changes here)

While actually encountering an issue like this is pretty unlikely, in some ways (even excluding the benefits of the new 3.5 features) you're better off on 3.5 :-)