running asp.net 3.5 and asp.net 2.0 in same site

Question

We're running ASP.Net 2.0 on our corporate web site, and I'd like to get it up to ASP.Net 3.5 as smoothly as possible. The project/solution architecture in VS 2005 is an ASP.Net 2.0 web project and an .Net 2.0 data access layer project which is used by the site code.

Upon opening the projects in a new VS 2008 solution they seemed to be converted to .Net 3.5 with a minimum of fuss - they built correctly out of the box, deployed successfully, and seem to work just fine, which is exactly as I would expect given that .Net 2.0 and 3.5 share a common runtime. The major difference after the conversion is that the web.config file's referenced dlls are now the 3.5 versions.

What I would like to do is to update the site piecemeal; as I make modifications to a given page send the 3.5 verson of that page over to our webserver and not update the whole site at once. In testing on our dev box this approach seems to be working fine - the site code is interacting with the .Net 3.5 data access layer without difficulty, a handful of pages are running 3.5 page-behind code (by this I mean that they're running assemblies built in VS 2008 - the site is using single-page assemblies for code behind), the 3.5 web.config is in place, and the bulk of the site is running code-behind assemblies built in VS2005. Everything looks great.

Which makes me worried that I'm missing something. Is this architecture workable, or is there a problem lying is wait for m that I haven't considered?

Answer 1

Actually, there is no such thing as ASP.NET 3.5, really. It's just ASP.NET 2.0 with some additional assemblies. If you look at the script maps for an "ASP.NET 3.5" site in IIS, you'll find they point to the exact same file (c:\windows\microsoft.net\framework\v2.0.50727\aspnet_isapi.dll).

The only thing you need to look out for is inheritance of web.config. If a parent virtual directory has a web.config containing .NET 3.5-specific entries, then a child .NET 2.0 application will not be able to read those configuration sections, and will throw an exception.

Note that this is a different story from the .NET 1.1 vs. .NET 2.0 upgrade fiasco. .NET 1.1 uses a different CLR from .NET 2.0, so the script maps would be different. Worse, simply installing .NET 2.0 on the server would update the script maps to point to .NET 2.0! Since .NET 2.0 broke some .NET 1.1 applications, this could cause problems.

In fact, it caused me serious embarrassment when I installed a .NET 2.0 Winforms application on a production server. Boom.

Answer 2

.NET 3.5 is a superset, for the most part, of .NET 2.0. There may be a few gotchas where minor tweaks have been made that will catch people relying on obscure features, but for the most part you should be ok. I've got sites running both .NET 3.5 and .NET 2.0 code on the same web server with no problems.