A question that comes up a lot is this: How do I tell my IIS Application or Virtual Directory to use ASP.NET 3.5 rather than ASP.NET 2.0?
Folks often go into the IIS6 or IIS7 manager and setup an AppPool and see a properties dialog like this, and when the pull down the option, they often expect to see .NET 3.0 and .NET 3.5 in the list and it's not there, and they freak out, rightfully so.
Here's an explanation of why this is confusing, and hopefully by the end, it won't be confusing anymore.
This is where marketing and reality part ways. I didn't initially like the naming, because I assumed that each major version of the Framework meant a new CLR, but it's growing on me as I understand it more. I get now why they named them this way. Additional fundamentally new functionality has to be named something.
The meat of .NET is in %windir%\Microsoft.NET\Framework\v2.0.50727. That's where, along with the GAC (Global Assembly Cache) all the libraries and compilers you know and love live. When folks ask "where is .NET" I usually start here.
The addition of .NET 3.0 didn't mean new compilers or a new CLR. Instead, it's three major new libraries: WCF (Windows Communication Foundation née Indigo), WPF (Windows Presentation Foundation née Avalon) and Windows Workflow or WF.
Bottom line: Installing .NET 3.0 doesn't fundamentally change your system in any way you should fear. Your 2.0 apps still run on a system with 3.0 installed. They are 2.0 apps using the 2.0 compilers and 2.0 CLR.
Try this. If you go into Visual Studio and File | New | Project (or Web Site), take note of the drop down in the upper right corner.
Select ".NET Framework 3.0" and make a new "WCF Service" take a look at the web.config. Note that it's pretty conventional, and should look like a typical .NET 2.0 ASP.NET application with a few additional.
Basically, remember Framework version != CLR Version. If you configured an IIS Application to use .NET 2.0, you're talking about the 2.0 CLR. WCF Applications use the .NET 2.0 CLR with the new 3.0 WCF libraries.
You can also use the new 3.5 compilers and the 3.0 libraries, of course as well. Each subsumes the previous as seen in Tim Sneath's fine stacked diagram above.
In your new app's web.config, there's a <system.serviceModel> section that is WCF specific, but otherwise the web.config looks pretty 2.0 typical.
The marketing term ".NET Framework 3.5" refers to a few things. First, LINQ, which is huge, and includes new language compilers for C# and VB. Second, the REST support added to Windows Communication Foundation, as well as, third, the fact that ASP.NET AJAX is included, rather than a separate download as it was before in ASP.NET 2.0.
There's a few other things in .NET 3.5, like SP1 of .NET 2.0 to fix bugs, but one way to get an idea of what's been added in .NET 3.5 is to look in c:\windows\assembly. Here's just the 3.5 versioned assemblies in the GAC (Global Assembly Cache).
Also, looking in %windir%\Microsoft.NET\Framework\v3.5 we can see the new compilers, MSBuild Target files, etc.
So, getting to answering the original question, try this experiment.
Go into Visual Studio and make a .NET 2.0 Web Site. Once it's loaded up, note your web.config. Next, right-click on the project and select Properties. Under Build, select 3.5 Framework.
Now, load up your web.config and notice the changes that just occurred. There's some new handlers that are added to support Ajax and some new ASP.NET Features, but the really important stuff is the <system.codedom> and the newly added assemblies in the assemblies section.
<compilation debug="false"> <assemblies> <add assembly="System.Core, Version=220.127.116.11, Culture=neutral, PublicKeyToken=B77A5C561934E089"/> <add assembly="System.Web.Extensions, Version=18.104.22.168, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/> <add assembly="System.Xml.Linq, Version=22.214.171.124, Culture=neutral, PublicKeyToken=B77A5C561934E089"/> <add assembly="System.Data.DataSetExtensions, Version=126.96.36.199, Culture=neutral, PublicKeyToken=B77A5C561934E089"/> </assemblies> </compilation> <system.codedom> <compilers> <compiler language="c#;cs;csharp" extension=".cs" type="Microsoft.CSharp.CSharpCodeProvider,System, Version=188.8.131.52, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4"> <providerOption name="CompilerVersion" value="v3.5"/> <providerOption name="WarnAsError" value="false"/> </compiler> <compiler language="vb;vbs;visualbasic;vbscript" extension=".vb" type="Microsoft.VisualBasic.VBCodeProvider, System, Version=184.108.40.206, Culture=neutral, PublicKeyToken=b77a5c561934e089" warningLevel="4"> <providerOption name="CompilerVersion" value="v3.5"/> <providerOption name="OptionInfer" value="true"/> <providerOption name="WarnAsError" value="false"/> </compiler> </compilers> </system.codedom>
There's the magic. Well, not really magic, and there's nothing hidden. This where your web site is told what version of the compiler to use, and the new supporting libraries.
This is where you tell ASP.NET to use .NET 3.5, not in IIS. IIS AppPools know about CLR versions, not Framework and compiler versions, those are set by the application.
Now, this is just my opinion, but I like to name my AppPools in IIS like this...
...which looks the way my brain thinks it is even though it's not reality. I keep my 1.1, 2.0 and 3.5 applications all running under the same instance of IIS, but each in their own AppPool. Note again, the there's nothing keeping me from having 3.5 apps under my 2.0 AppPool, I just keep them tidy on my own.
Scott Hanselman is a former professor, former Chief Architect in finance, now speaker, consultant, father, diabetic, and Microsoft employee. I am a failed stand-up comic, a cornrower, and a book author.
...but in my experience most server administrators are completely confused by this.
I think you could write an entire series of blog posts on the topic of how to appropriately divide ASP.NET administration duties.
Amen. This was clearly a major mistake in the marketing of the framework; I wish Microsoft employees would come out and admit the obvious instead of trying to defend such a colossal fubar.
I didn't initially like the naming, because I assumed that each major version of the Framework meant a new CLR, but it's growing on me as I understand it more. I get now why they named them this way. Additional fundamentally new functionality has to be named something.
Disclaimer: The opinions expressed herein are my own personal opinions and do not represent my employer's view in any way.