Will .net 2.0 and 3.5 run side by side?

Question

We're a development shop that still does most of our development in .net 2.0. We're starting to think about using some of the new things in 3.5 (LINQ, etc) and there are some other software packages we're looking at that need WPF and so on.

We'd like to get 3.5 up and running on our test server, but without wrecking any of the 2.0 sites we already have running (and we'd like them to keep running under 2.0). Are there any hidden issues I should know about, or can I just install 3.5 on our Server 2003 machine and be good to go?

(The specific concern being that despite Microsoft claiming the .net 2.0 components are the same in 3.5, that they actually changed something game-breaking.)

Update: Bolstered on by everyone's comments here and other reading, we decided to bite the bullet and install 3.5 on the server "just to see what happens."

On running the install program, we discovered (to our not inconsiderable surprise) that .net 3.5 had been installed back in August - and none of us had known about it.

Which, really, is about as seamless an upgrade as you can ask for.

Thanks, everybody!

Answer 1

3.5 is an extension if 2.0. There is no 3.5 without 2.0. Its actually a different dll (Core.dll). This isn't like the move from 1.1 to 2.0; if your older sites don't reference the new dll, then those sites do not get altered whatsoever.

Answer 2

2.0 will play nicely with 3.5. .NET 3.5 is really just some extra classes added on top on 2.0, so everything is compatible. I moved a bunch of projects from 2.0 to 3.5, and everything migrated very smoothly, with just a recompile.

Answer 3

Just to add, the .NET versions are meant to work together, not just the 2.0/3.0/3.5 thing. You can also run 1.1 along side and it will be just fine.

Answer 4

No you cannot. It is likely to work, but 3.5 replaces certain 2.0 parts, so you need to regression test.

[edit]Don't vote down if you don't like the answer.

I specifically asked this question at TechEd. Keeping the same API doesn't mean the implementation behaves the same. At the time, the speaker response was: performance improvements (no details).

To repeat myself, as it doesn't seem to register: the API is the same, the implementation is different (as you can see in the Hanselman link in the comments). Micah, you don't seem to know where you're talking about.

Answer 5

I've done this on two very large systems in the past couple years and had absolutely no problems in either case. 3.5 runs on top of the 2.0 runtime.

3.0 should really have been 2.1, and 3.5 should have been 2.5. If that helps any. 3.0 and 3.5 are really just functionality extensions to 2.0, and don't include their own runtime. The service pack releases to 2.0 are where changes to 2.0 are found.

Answer 6

Yes, but with a caveat.

Be careful about installing 3.5 SP1, because it also installs 2.0 SP2, which adds some extra functions. This would be fine, except for visual studio will use IntelliSense and everything will compile fine and work great on the developer machine, but completely fail with an obscure error on computers with "just" 2.0.

An example of this is the method ManualResetEvent.WaitOne. SP1 added the overload WaitOne(int), whereas without it, you need to call WaitOne(int, false).

Answer 7

Besides all answers provided, and as you must have your job at stake, you should try it first in a test server before deploying in a production server.

In my experience we had no problem upgrading to .NET 3.5 on our Web Servers.