Ok, imagine the following situation:
You are a developer and you want to keep up with the latest technology, so you update Visual Studio 2008 with
Service Pack 1, installing .NET 3.5 Service Pack 1 as part of the update. You then proceed to continue with your ASP.NET application, building a nice neat AJAXy application. Everything works fine on your box, it's awesome, the in-your-cube demos go great, everybody's happy. So you build and deploy your new hotness then sit back and wait for the pats on the back.
The pats never come. Instead, you get reports of exceptions being thrown by the application every request. Something has gone horribly wrong. It's always the same exception:
Could not load type 'System.Web.UI.ScriptReferenceBase' from assembly
'System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35'.
You are stymied. You've never heard of the class; you certainly don't use it in your code. You use
ScriptReference, of course; who doesn't? But what's
ScriptReferenceBase? Going to the documentation for ScriptReferenceBase, you learn that it is the parent class of ScriptReference and
CompositeScriptReference. What? No it isn't! The documentation for ScriptReference clearly indicates that it's parent is
System.Object! What's going on here?
Then you notice the Version Information for ScriptReferenceBase: "Supported in: 3.5 SP1". It's a new class for Service Pack 1. It doesn't exist in .NET 3.5 and the documentation for ScriptReference is clearly stale.
Following a hunch, you double-check your server... yep. Due to red tape, SP1 hasn't been installed on the server. It turns out that when you compiled your code with the SP1 ScriptReference, you built a reference to ScriptReferenceBase and that class just isn't on the server. The solution is simple: install SP1 on the server.
Except you can't upgrade to SP1! Internal circumstances (i.e. no time for regression testing) means no upgrade. So no biggie; you return to Visual Studio 2008 and decide to target .NET 3.5 rather than .NET 3.5 SP1.
Except, surprise! You can't. Visual Studio will target .NET 3.0 and 2.0, but it won't let you differentiate between .NET 3.5 and .NET 3.5 SP1. OUCH.
So what do you do? At this point, your options are limited. The best option is to install SP1 on the server, but sometimes internal pressures won't allow that. Other options include uninstalling SP1 from your box and recompiling -- good luck with that one! -- and finding an unadulterated version of VS 2008 somewhere (a co-worker's box, maybe a virtual machine) and compiling there.
So why am I writing about this hypothetical situation? Because it happened to me, of course! I learned an important lesson. Maybe you can too.